The Importance of the Fundamentals of Design Patterns

For this blog, I am choosing one from Uncle Bob’s website, the Clean Coder Blog. Almost all of Uncle Bob’s blog are set up like a conversation. Uncle Bob writes questions that the readers might ask, and also answer them for the readers. It is really fun to read his blogs, it is usually short, and might answer some of your questions and give you more insight on the topic that he is writes about.

In his blog called “A Little About Patterns”, Uncle Bob talked a little bit about Design Patterns. In this blog, there were a lot of questions about why we still use Design Patterns that were made from the 90’s. It was mainly about the Design Patterns by the GOF(Gang of Four) book that was made popular in 1995. In the blog, Uncle Bob asked if the “person” could name a design pattern. He then pointed out the book GOF. The person then replied ” But isn’t that kind of old now and outdated?”. Uncle Bob then responded with “Indeed there are many newer books on the topic, and some are quite good; but none are quite so impactful and insightful as the original.”

Throughout the blog, Uncle Bob was just proving that, even though the GOF book was written 20 years ago, it still stands as the best book. He noted that “The Design Patterns book is one of the most important books, if not THE most important book, written about software within the last 20 years. In fact, the fundamentals of software have changed very little in the last four decades.” This just tells us that, even though it might seem like these designs are old, they are still the fundamental of Design Patterns.

Uncle Bob then said that most of the idea of the newer frameworks are old. That they are just Design Patterns. Then he gave this “person” the meaning of a design pattern. “A Design Pattern is a named canonical form for a combination of software structures and procedures that have proven to be useful over the years.”

The blog introduces a couple of newer Design Patterns like Model-View-Controller(MVC) which is a software architectural pattern for implementing user interfaces on computers, and how you can just say this is dependency injection and everybody will understand it in a way.

I chose this blog because it talked about design patterns and how the fundamentals which we are learning in class even if they were written from 20 years ago, are still the very core of Design Patterns. I think that to learn the proper way of using Design Patterns, we should learn about its fundamentals first.


The Importance Of Clean Architecture

In Episode 68 of the CodingBlocks podcast,  they talked about the latest book, Clean Architecture by Robert Martin (colloquially known as Uncle Bob).  In the podcast, they explained the benefits of a clean architecture and why it matters. They said that the benefits of a clean architecture is that it can minimize efforts when it comes to adding features to the program.  Their functionality is maximized and changes are easy. It can reduce the number of people needed to write the software and adding features. They also added that there is no difference in design and architecture when it comes to a program. That the architecture should be incorporated into the design as well.  Throughout the podcast, they keep using the analogy of the Turtle and the Hare. They quoted that in the book, Uncle Bob added that “the only way to go fast, is to go well”. I think that this is a really good quote. Often we are bounded by the due date or time. In the podcast,

Also, in the podcast, they also said that “coding is easy, but managing our code when new features are added is the real challenge”. They said that maintaining cleanliness is better than cleaning it after the problems are piled up. Michael also talked about how sometimes, they say that the developers are not working. Which isn’t really the case. The problem lies in the architecture of the product since it does not support the changes that the product manager or client wants. They also talked about how sometimes company X comes to the market first but company Y is more successful because they were able to add more features faster than company X.

They also tackled the problem of rewriting the code, which most of us think would be the solution to the architectural problems. They said that rewriting is not the answer. Most of the time, we would rewrite the program to fix the problem. You will feel good about yourself when rewriting it since you are doing it really fast. But still not thinking about how to solve the architectural problem of your program. They said that the quality of your products should be taken seriously. Since developers are constrained by time most of the time, they forget the risk that are involved by being “fast”. Sometimes unit tests are not done and the code is not reusable anymore.

I chose to listen to this podcast because I wanted to learn more about Software Architecture and what are the benefits of having a good architecture versus just having a code that works. I  actually questioned Dr. Wurst about this, having done his first assignment for us. I asked him why we needed a better architecture even if the amount of classes in the program looks like a cluster. After listening to this podcast, it finally makes sense to me now. A product that have a better architecture is easier to change or add programs. In the long run, a better structured program is better and would be easier to manage than a program that is done “fast but not well”.

UML Diagrams


In this blog, Mohamed Elgendy talked about why do we use model and some of the different kinds of diagrams used in UML.  Mohamed started off by explaining what UML is. He said that “UML is a set of standardized (Unified) diagrams, just like construction has front elevation, electrical diagram, floor plan, etc., UML offers different views of the same system.”. Which basically means that  UML is just a blueprint. In software development, we use this blueprint to better communicate with other people rather than software developers  in a way that they could understand.

In the blog, Mohamed explained different type and use of each diagrams and which team members are responsible for creating the diagram.

Class Diagram describes the structure of a system by showing the system’s classes, their attributes and the relationships among these classes. It display what interacts but not what happens when they interact.  The Class Diagrams are created by the Architects or the Technical Leads.

Component Diagram  are composed of one or more classes or interfaces. It is used to depict how various components of a system show dependencies. The Component Diagrams are used during the technical design and is also created by the Architect or the Technical Leads.

Deploying Diagram shows the physical relationship among the software and the hardware components in the system. In many cases, the component and deployment diagrams are combined in a single diagram. This is also created by the Architect or the Technical Leads.

Package Diagram shows the group of classes called “package”. Similar classes are grouped together if they do the same thing. Sometimes developers choose to display individual classes inside the package for better clarification. The Package Diagrams are created by the Architect or the Deployment Specialists.

Statechart Diagram describes the behavior of a system where  it shows the possible states  an object can be. It is typically drawn for objects that typically have a lot of dynamic behavior.  Statechart Diagrams are created by the Architect.

Object Diagram depicts a complete or partial view of the system at a specific time. Object Diagrams are created by the Developer.

Sequence  Diagram displays the sequence of events between entities of the system to show the dynamic view of the system. It is executed line by line showing the time ordering of messages.

Activity Diagrams describe the sequencing of actions and system’s logic. The starting point of this diagram is indicated by a large black dot and uses arrows to point to the order of actions.  Activity Diagram is typically used for objects are more complex that you would like to present clearly.

I selected this particular blog since we are using UML in Software Construction, Development, and Architecture class. I was actually a bit confused about how we used the diagrams in class. I was thinking that diagrams are just one program like we did in class, but diagrams are actually made to connect with other diagrams to explain how they interact with each other. In this blog, Mohamed added which team members are responsible for each diagrams. After reading this blog it is clear to me now that there are different responsibilities and types of people in a team. I thought that a team would be composed of all software developers, but in reality, some modeling diagrams are done by other professionals.



Mobile App Development

Jonathan Stark on Mobile App Development podcast

This podcast talks about the process of developing a mobile application and the different aspects to consider before creating one. Jonathan Stark talked about the general things needed to develop an app. Jonathan was saying that deploying a mobile app requires so much more than what people think. When you deploy an app in the app store, whether is google play or itunes. Your app would be reviewed by the store on whether your app is reliable, perform as it should, and free of offensive materials. Apps are reviewed based on technical, content and design of the app. He also said that sometimes it can hinder investors since even though you have a very nice app, but it didn’t pass the review, it is worth nothing. Jonathan also talked about using Progressive Web Applications (PWA) versus the Native Apps. He talked about the advantage of using PWA and coming from a web developer background, how it is better than the native apps that most are developing. Jonathan said that PWA is faster, more secure, reliable and most importantly it is like a one size fits all. Developers would not need to develop multiple apps across multiple platforms anymore. While in the Native apps, you have different apps for different OS, whether it is iOS or Android. He also talked about React Native. React Native is a real mobile app it is not a “mobile web app”. In React Native you can create apps the traditional way, just like using Objective-C and Java. Jonathan also talked in this podcast about the importance of design while building an app. Since phones don’t come in one size, you have to consider how your app would work in different phones. Sometimes you might have to move the interfaces from your app across different phones. There are many more things to list here about mobile app development that they talked about in this podcast.

I chose the topic of Mobile App Development since everybody, I feel like uses a smart phone nowadays and that we are basically using applications every time we open our phones.

From this podcast, I learned different things to be considered while making an application. That even the smallest thing like, what if you are trying to click on the menu but your finger covers the options while doing it. Things like these that I never considered before was just as important as coding the actual app.

Data Science

This podcast is about the field of Data Science but also talked about team building.  I chose this podcast because I saw that she(Angela Bassa) was the Director of Data Science at iRobot and because I am using iRobot’s Create on my robotics class. There was a part in the podcast that I thought was funny but is important when it comes to team building. Angela said that “you cannot have a team full of  unicorns(programming gods basically)”. That was a pretty bold statement. She said that it will take time to get a team full of unicorns and a lot of resources. Then she referenced the “super chickens” who were a group of only the best chicken, but what ends up happening is they killed each other.  I learned that balance is important in everything that we do.

Data Science with Angela Bassa