Software Design and Architecture

In this blog, I will discuss the book Ready Player One by Ernest Cline. We read this book during this course and I must say I really enjoyed reading it, so far its one of my favorite science fiction book. The book is about a dystopian future where society has abandoned reality and instead decided to live most of their lives inside a virtual reality simulation where everything is more “grandiose”. The story follows Wade Watts in his journey to find Hallidays (the creator of the game who past away) easter eggs, the person that finds all the easter eggs will inherit his vast fortune. I think there are many similarities with the virtual world in the book (OASIS) and the virtual world we currently have in our lives (social media, video games, mobile apps and other IT technologies). Because in the end, they are all outlets to escape our realities in some way. Our world is not dystopian like the one in the book, but we are living in an age where we want everything quick and easy. Tha

In this blog, I will discuss the article titled "Microservices" written by James Lewis and Martin Fowler in March of 2014. I found the article to be interesting and shed some light to things I didn’t know about microservices. Microservices are a type of architecture that structures applications as a bundle of different services. What's good about them is that they allow for continuous and efficient deployment of applications into complex systems. So their implementation is often vital when working on a problem that requires a large subset of tools and resources in order to work, meaning that this system is complex and big in size. What microservices accomplish is that it allows companies and different application services to widen their stack of technology and enable the continuous delivery and deployment of technologies into their systems. Companies tend to apply microservices when their systems grow largely and become more complex. This allows the system to becom

In this blog, I will discuss and review the videos called "4+1 View Into Software Architecture" and "Six Blind Men", as well as the article titled "The Elephant and the Blind Programmers" by Grady Booch written in 2010. Often times when developing, we don’t take into consideration the interactions users will have into our system and in doing so, we degrade the experience of what we build. The interaction can vary from user to user. That's what we see in the video where the blind men interact with the elephant. Their interpretation of what that elephant is like varies because of their different perspectives and because they chose different parts of the elephant to make that judgement. And that's all good, because having a different interpretation doesn’t mean they are wrong. Because the combination of their interpretation defines what they experienced very well. In the end they gave a very clear description, although abstract, of an elephant.

In this blog, I will discuss a section from the book "Ace the Programming Interview: 160 Questions and Answers for Success" by Edward Guinness published by Wiley in 2013. The section I will discuss in this blog is called "Understanding the SOLID Principles". So first of all what does SOLID stand for? It stands for: S ingle Responsibility Principle O pen/Closed Principle L iskov Substitution Principle I nterface Segregation Principle D ependency Inversion Principle Lets try to briefly understand what each of this mean. Single Responsibility Principle: Like the article says, a class should only have one responsibility and there never should be more than one reason for the class to change. One good way of applying this principle is asking yourself whether the logic you are coding into your class should live there or not. Open/Closed Principle: This principle states that software entities should be open for extension but closed for modi

In this blog, I will discuss the podcast titled "Software Craftsmanship" by Robert Martin produced by Software Engineering Radio in the year 2009. There are a lot of interesting topics touched in this podcast. We could summarize the topic of this talk, into the art of being a master of coding. The crafting is code is intangibly related to the learning of many other disciplines. We learn from the masters, or at least we try to learn to what is immediately in our surroundings. But sometimes it is not enough to only learn from our immediate sources of knowledge (school, teachers, etc), sometimes we must reach beyond and seek learning from other sources. This is true in the programming world, specially in the era of internet when we can learn from hundreds of different sources. As a students who is soon going to graduate I’ve thought of what my life is going to be like after college. Maybe I’ll pick a 9 to 5 job, but what am I going to do in my free time? Maybe rest? Wa

In this blog, I will discuss the article titled "Is Design Dead?" by Martin Fowler (the same author from the last blog) in May 2004. Design is one of those things programmers (or at least hard core programmers) tend to shy away from. We usually like to jump right into the action not taking into consideration the design, not really thinking of the repercussions of not having a good design. We usually just think that things will fall into its right place, and sometimes we se downside of not implementing design later in the project. The article primarily shows this point showcasing Extreme Programming as one of the responsible programming methods for not taking priority to design. Extreme Programming’s approach to design is evolutionary, not planned design. Meaning that the design comes about just as the creation of the system is implemented. Many people can see this as good or bad. You save some time by creating the design around the current implementation, rather than p