Author Archives: michaelchaau

White Belt Pattern

For my first Apprenticeship pattern, I chose to write about “The White Belt”. In this pattern, you’ve created a good understanding of the first language you’ve learned, and others have recognized and have often called you for help when they have problems. Even though this is great, you feel that you’re have a little difficulty trying to learn new materials and find that things are slowing down and you’re not learning as quick as before and fear you have hit a peak of your personal development.

When I first read about this pattern, I did in fact felt like I hit a plateau in obtaining new skills and in self learning. I could relate to the description of the white belt very much. I really loved how they quoted Yoda from Star Wars with “You must unlearn what you have learned”, regarding approaching new situations. Another quote that I liked while reading about this pattern is “In order to climb, you must leave the sure footing, letting go of what you already do well and possibly slipping downward into a ravine. If you never let go of what you already do well, you may continue to make steady progress, but you’ll never get off the plateau” by Jerry Weinberg. Both quotes are quite similar and suggest that in order to learn and make a steady progress, you must leave your comfort zone and tackle the problem with a different method. This helped me come to the realization that I’m constantly trying to incorporate another programming language that I was comfortable with the new language I’m trying to learn. Which results in me having a hard time learning new things for both languages. After I took a step back to analyze what was going on, I went back and tackle each language in a separate way. I then was able to learn and get past the plateau I was on.

There isn’t anything I would disagree with what was said for this pattern. Everything that was said was great and would really help others who have also hit a plateau. The story of Dave was a quick and simple way of relating the quotes I said earlier and applying them. Overall reading about this pattern has helped me come to the realization that there are some problems that should be handled differently, for instance when learning a new problem or a technique of how to do something.

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

Reaction to Apprenticeship Patterns

My initial reaction after reading Apprenticeship Patterns by David H. Hoover and Adewale Oshineye, was very eye opening for me. It made me rethink about my future and goals and what I want to be able to achieve. The story of Dave which displayed his experience was very helpful. Apprenticeship Pattern is a book I would definitely recommend to people who are getting into software development. It’s a book that gets your mind ready to go on a journey from an apprenticeship to journeyman status. While reading the introductions from Chapter 2 thru 6, it really inspired and motivated me to do my own learning other than what I am currently doing in my university. I would agree with the reading however, I do believe some people may disagree depending on their mindset and goals. In the book it takes about how some people become the “better than average developer”. This isn’t what I want to achieve, instead I would like to someday develop an application that is useful or that can help communities and to be able to do that, I need a mindset of a master. A master is a step above a journey man who completed their apprenticeship. The mindset of a master is to constantly get better at their craft and they’re always learning new things.  The chapter that I believe that is most relevant to me right now would be in chapter three. In the intro of chapter three, we follow Dave who decides to branch out and connect with other developers through a website. After this he met a few hackers that inspired him because were experts in their craft but were still learning new things at a fast rate. This made him realized he just barely scratched the surface of being a great software developer. After a few interactions and observations, he captured the learning process and threw himself into anything he can get his hands on. This last part is what I can really relate to right now. I am trying to learn as much as I can before the end of my semester and to work on a few projects that will help be harness my skills together.

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

Familiarizing Myself With Thea’s Pantry

After visiting Theas Pantry’s gitlab, I was about to learn more about what I will be working on this semester and I can say, I am very excited. I will be on the team that will be working with the GuestInfoSystem. In the documentation repository, technology is what drew my attention. In this file, it lists what types of tools and frameworks we will be using for this project. Since I plan on being a full-stack developer, working with these technologies will help me further my knowledge with working with them. Not only that but working on this project will allow me to experience how it will be working with a team on a real project. It’s a preview of what I will be doing when I eventually start working at a company after graduation.

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

Familiarizing Myself With LibreFoodPantry

After visiting the website, LibreFoodPantry.org, I was really impressed by how clean the webpage looked. It really gives a brief idea on what this project is all about. On the main page it shows items such as the mission, values, status, and a few other things about the project. One thing that stood out to me was the User Story Map. I did not expect to see a layout of things that may be incorporated into the project. Seeing this as a student who will be working on this project allows me to better understand what I may be working on. The User Story Map shows features that may be added to the project based on interviews with clients. However, the story map doesn’t guarantee that everything on it will be incorporated, its more to help select what features to have and implement.

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

What is GRASP?

GRASP is short for General Responsibility Assignment Software Patterns. GRASP is a design pattern in object-oriented software development. It’s a tool for software developers that provides a way to solve organizational problems. Also, it offers a common way when talking about abstract concepts. This design pattern sets responsibilities for objects and classes in object-oriented program design

     In GRASP (General Responsibility Assignment Software Patterns) when working with object-oriented programming, it classifies problems and the solutions together into a pattern. Thus making them well defined where they can be applied in other similar instances. Grasp has nine different patterns for classes and objects that helps make it clear to show the responsibilities. The nine patterns are:

– Controller: Assigns the responsibility of dealing with system events.
– Creator: Most common in object-oriented system, which class is responsible for creating objects.
– High Cohesion: Evaluative pattern that attempts to keep objects focused, manageable and understandable.
– Indirection: Pattern that supports low coupling and reuses potential between two elements.
– Information Expert: The most basic principle – if we do not have the data we need, we would not be able to meet the requirement and assign responsibility.
– Low Coupling: A measure of how strong one element is connected to, has knowledge of, or relies on another element.
– Polymorphism: Responsible for defining the variation of behaviors based on the type is assigned to.
– Protected Variations: A pattern that protects elements from the variations on other elements by wrapping the focus with an interface and using polymorphism to create various implementations.
– Pure Fabrication: A class that does not represent a concept in the problem domain.

     I chose to write about GRASP (General Responsibility Assignment Software Patterns) because it is a part of our curriculum which we will be learning in this class. Since I have written about DRY (Don’t Repeat Yourself) and YAGNI (You Ain’t Gonna Need It), it made sense to continue researching about patterns and learning more about it. As I have mentioned many times before, I plan on becoming a full-stacked developer. Learning about these different types of patterns and what each of them do will help me as a developer become more knowledgeable and more efficient when it comes to coding. 

A good blog I found when researching this topic that I suggest to read and learn more about GRASP is:
http://www.kamilgrzybek.com/design/grasp-explained/.
This Blog is very useful and has many examples of the nine patterns I mentioned.

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

What is YAGNI?

     Just like my post from last week, YAGNI is another acronym in computer science. It’s an acronym for “You Aren’t Gonna Need It”. Which translate to only having features added when they are required. It’s another type of principle that is heavily followed in computer science. This is a large part of development since it trims away any excess and inefficient part of the program.

     The YAGNI principle tells you to mainly focus on current tasks. This however does not mean you cannot work on future steps but if it’s something that doesn’t need to be done currently, then you shouldn’t spend time doing it now since you can be working on something that will be more valuable now. A real-world example that I found can be that a client orders a kayak but is given a yacht. They both float on the water, but the yacht is like a luxury house on the water, where as the kayak is a simple vessel used to travel on water. In this case the yacht isn’t necessary as the client only wanted to travel or even just float on the water. This is considered “over-engineering”. This is a term that can be define as making something more complex instead of simplifying things

     There are many advantages to YAGNI. First, you will be saving time which also means you are saving money. Without having complex code, it makes it easier for others to understand the code. Without all the unnecessary coding, the code itself is better quality and allows developers to focus more on what the code is about instead of having to figure out what everything does. Following the YAGNI principle allows developers to not waste time on creating extraneous elements that may not be necessary or slow the development process.

     The reason why I chose to write about the YAGNI principle is because it is a part of our curriculum. Since I am planning to become a developer, I need to learn the different principles when it comes to programming. Learning about the YAGNI principle will help me become a better programmer as I will know to only work on the current tasks and not try to implement more complex code that will not be used until a later date or when it is necessary.

Here are some blogs I recommend to those who want to learn more about the YAGNI principle.
https://codibly.com/news-insights/yagni-how-to-do-things-when-you-actually-need-them-to-be-done/
https://whatis.techtarget.com/definition/You-arent-gonna-need-it

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

What is DRY?

First of all, what does DRY stand for? It is a term “don’t repeat yourself”. In the software engineering world, this is a principle of reducing repetition in the code, referring to a single source-or “snippet” -of reusable code whenever you need it.

An example of this could be an app that your programed that throws a ball for your dog once an hour throughout the day. Instead of writing the entire code out for finding the ball, picking up the ball, and throwing the ball every hour, you can write the code once and give it a name such as toss.ball. This will then allow you to just type toss.ball each time to call it. This saves a lot of time writing the code.

Not only are we saving time when first writing out the code, but it also means that there will be less human error as well. From the example, if we were to write out the code entirely 24 times (1 for each hour), you would be bound to make some sort of error at least once. Another reason how this is also effective is that if you wanted to change the object being thrown for example a stick, all you would have to do is change the term ball once, instead of doing it 24 times.

In terms of real life, we can see this being used when we let websites save our information such as logins, password, or any other type of information we would have to type in each time. The same goes for music. If we are using sites such as Spotify, most of us create playlists so we don’t have to constantly look for the song we want to listen to.

I chose to write about this topic because it is part of our curriculum. We will be learning about this principle along with others as it is an important part of coding. I will post a link that will take you to a blog I read. https://zapier.com/blog/dont-repeat-yourself/ I really enjoyed going taking the time to go through this blog because it taught me and showed the importance of reducing time when it comes to coding. I also recommend this blog to anyone who plans to become a software engineer because it goes into depth about DRY and uses many examples to help you understand how it works. It amazes me how a simple principle could do so much such as saving time, less human errors, and overall having a simple code.

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

What Is Unified Model Language (UML)?

Unified Model Language is the standardized modeling language that consists of integrated set of diagrams, that were developed to help system and software developers. This allowed them to specify, visualize, construct, and document software systems which also works well for business modeling and non-software systems. The UML consists of some of the best engineering practices that have been proven successful in large and complex systems. When becoming a developer, it is important to learn UML because it is a very important part of developing object-oriented software and the software development process. The way UML are expressed is mostly through graphical notations to show the design of software projects. UML is very useful for project teams because it helps them communicate, explore potential design and validate the architectural design of the software.

UML has many uses and one of them is the uses of diagrams. The diagrams are divided into three categories. The three categories are Structure Diagrams, Behavior Diagrams, and Interaction Diagrams. Structure Diagrams is a category that includes Class, Object, Component, Composite, Package, and Deployment Diagrams. Another category is the Behavior Diagrams include the Use Case Diagram, Activity Diagram, and State Machine Diagram. The last category is the Interaction Diagram which is derived from the general category of Behavior but also includes the Sequence, Communication, Timing, and Interaction Overview Diagram. Other things that are useful with UML is that it has tools to analyze existing source code and reverse-engineer it into a set of UML diagrams. There are also tools that allow the UML models to be executed. Another interesting tool I found is that you can generate a program language code from UML, that is mostly bug-free. There’s also several tools that can generate Test and Verification Suites from UML models.

I chose to write about the topic of Unified Model Language (UML) because it is part of our curriculum. It is one of the first topics we touched in our CS343 class. Also, I believe it is very important to understand how UML works as a developer. This allows teams to work together and understand what needs to be done and the connections that are being made. While researching this topic I found a few sites that elaborates on what UML is and I recommend anyone who’s thinking of becoming a developer to look at the links I provided down below.

Links:
https://www.uml.org/what-is-uml.htm
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml/

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

What is an API?

From my other posts, I mentioned APIs quite a few times. But what exactly are they? API’s also known as Application Programming Interface, is a software that allows different applications to connect to each other. Some examples that we see all the time could be when you’re sending a message on a social media platform, using a program, or just checking things on your phone. Doing any of these activities, you’re using an API.

An API works to communication data to different applications. When one is using an application, the application would connect to the internet and send data over to a server. Once the data is retrieved from the server, it then gets interpreted and will perform the necessary actions to send the data back to the application. From here the application will take the data it received and interpret and present the data requested in a way it is readable. This is what an API do. Not only does APIs act like a way for different applications to send and retrieve data, but it also acts like a layer of security. When using any type of application, your phone’s data is never fully exposed to a server its retrieving data from, same goes for the server. This is because instead of sharing every bit of information, only small packets of information are being shared or what is ‘necessary’.

A more in depth example I found while researching this topic is to imagine you’re sitting at a t able in a restaurant with a menu to order from. In the restaurant, the kitchen is a part of the system that will make your order. However how the kitchen is missing the details for what you ordered. In order to receive the order, they must communicate with the server. This is the API. The server communicates to the kitchen with your order in order to make it for you. This is basically what an API does. It connects two applications, so they can connect with each other and deliver the data.

The reason why I chose to write about API is because we will be learning it in class. Not only that but from my previous posts, I have talked about my interest in becoming a full stacked developer. This means I will have to proficient knowledge in both front and backend development. API is used in both. APIs are important to know because it will help me when I decided to create my own application as well, so it is very crucial I know how API’s work.

A post I would recommend to read about API is:
https://www.mulesoft.com/resources/api/what-is-an-api.
Not only does it describe what APIs do, but gives examples and has other links that teaches you more about APIs.

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

What is Backend Development?

Backend development is the server side of a website. This is everything that the users of the webpage do not see. Backend is mainly focused on databases, APIs, and Servers. In order to help the website, communicate the data being used, programmers who are backend develops write code in order to store data from the webpage into databases. The code written can be read, updated and deleted from the database.

An example of this is when you create an account on amazon. When you click ‘Create Account’ is takes all the information you just submitted, processes that data and stores it into a database. Amazon now have the details you shared into their database. However, you didn’t see it happen because it happened behind the scenes. This is what happens in the backend of the webpage. This is just the beginning of the backend.

Since we mentioned backend developers, lets go into depth on what they do. Backend developers are responsible for building the structure of a software application. Unlike frontend developers who mostly uses only three tools such as HTML, CSS, and JavaScript. Backend developers uses various tools such server-side languages, databases, and servers. Some server-side languages could be Java, Ruby, NodeJS, and .NET. These languages are what most backend developers use to create codes that help the backend of the website work. Databases and servers that are used could be MYSQL, Oracle and SQL server. Databases and servers are where the data from the websites get stored, such as addresses, emails, and any other kind of useful information for the customer or what the website may have. To become a decent backend developer, the skills you must have knowledge of programming languages, and how to use databases, servers, and APIs.

The reason why I chose to write about backend development is because I have an interest in it. I eventually want to become a full stack developer and that means I will have to know both front end and back development. As technology gets more advance, there will be more need for individuals who process such skills. Not only that but I plan take my skills further and someday develop my own websites and other useful applications.

A blog I found that I would recommend is: https://www.interviewbit.com/blog/backend-developer-skills/. This website contains a lot of useful information on backend development for those who are interested in where they should start and understand what it takes on becoming a backend developer.

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.