Category Archives: Blog

Why Encapsulation Matters


In this article, they don’t show us examples of encapsulation but instead explain to us the importance of it and why we do it as software engineers. Initially, they start off with how encapsulation helps us hide the complexity of our code. The beauty of hiding our code is not having to understand all the details in order to be able to use it, we just need to understand a broader abstract concept and how it works and how we interact with it. They also explain to us what happens when are not able to achieve the proper levels of encapsulation in our design. That article continues as to why we need accessor and mutator methods in Java.


The reason why I chose this article was because in class we have done a lot coding in regards to encapsulation and I thought that this would help me fully grasp the purpose and meaning of encapsulation. Encapsulation is the very essence of API’s and how they work and being able to understand this is very important since we may be creating API’s in the future.

What I’ve Learned:

Encapsulation is more than just defining accessor and mutator methods for a class. It is a broader concept of programming, not necessarily object-oriented programming, that consists in minimizing the interdependence between modules and it’s typically implemented through information hiding. Our software designs the visible parts of our modules/classes constitute their public interface, and this is exposed to the outside world, the rest of it should be hidden to the naked eye. With encapsulation us as humans deal with complexity by defining abstractions with public interfaces so that we are able to interact with them and all of the code that lies beneath it is unnecessary in order for use it. It is like an iceberg, only a small portion of it is visible on the surface, but most of its true size is hidden underwater where we cannot see it. Changes can we made in directional systems because internal implementation is encapsulated and because of that, changes can we safely done without affecting it’ public interface. By minimizing the impact of changes and independence of modules, we can achieve proper levels of encapsulation in our software that can handle change without breaking its users. Information hiding is important because it decouples modules that compromise a system and it allows for them to be tested, optimized, used, understood, and modified in isolation. This allows for other modules to be developed in parallel and eases the burden of maintenance without the fear of affecting other modules. Encapsulation is a desirable attribute that allows for the evolution of APIs and as long as we respect public interfaces of our abstractions, we are free to change whatever has been encapsulated. Failing to define proper abstraction with proper levels of encapsulation will end up causing difficulties when change happens. There is no way to change the public interface of an abstraction without breaking its users. Encapsulation is one of the tools we use that help us create good abstractions, but no level of encapsulation is going to make bad abstraction work.


From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen 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:
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: 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.

Why is HTML Important

HTML which is also known as ‘Hypertext Markup Language’ is a programming language used to describe information you may find on a web page. When used with CSS and JavaScript, these three makes up the essential foundation of any website found worldwide. A website may be broken down into three components. First, we have the page’s appearance which is made with CSS. CSS is also known as ‘Cascading Style Sheets’ is used to design the appearance of a webpage. This allows you to set things from the size and font of texts shown, to the color of the page, and so on.  Then we have the functionality of the page using JavaScript. JavaScript is a language used to program the page. For example, if you were to click on “shopping cart” on amazon, this would navigate you to a page that were to show you what’s in your cart that you want to buy.  Lastly, we have what some call the ‘bones’ of the webpage. This is where HTML is used.
CSS is known as ‘Cascading Style Sheets’ is used to design the appearance of a webpage.
When designing a webpage, many contains important information that may recede in headings, paragraphs, or many other types of data. HTML is used to specify what kind of information goes into these types of things on a webpage. This type of work is mainly used by Front-end developers. These developers use HTML language to code different things that relates to the overall structure of the page.
HTML is something every website uses no matter what browser you use. From social media web pages like Facebook and Google, to web players like YouTube or Spotify. If you were to look at the coding behind done for these pages, you would see that they all use HTML. That’s why HTML is important.
To become a front-end or full-stack web developer, HTML is a good place to start off with. Combine HTML with CSS and JavaScript will provide you all the necessary to create an interactive webpage.

A blog I would like to share is This blog has a lot of useful information about HTML and if you’re looking into become a front-end developer or a full-stacked developer I highly encourage it!
I chose to write about HTML because I am highly interested in learning full-stacked development. I think it will be very useful in the type of career I will choose once I graduate from Worcester State University. Another reason why I chose to research and write about it, is because it is on our syllabus, we will be learning about front-end development, so I thought it was appropriate to talk about HTML.

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.

Using an Agile as approach to scope software projects


This article starts off by explaining what software scoping is and that doing it well will help establish requirements and expectations between the customer and user, reduce friction during the development process, and help outline budget and timescales. Agile is well suited to support processes because it encourages you to establish high-level requirements first, and finer details later. The article continues by going into certain topics such as how to facilitate engagement, the drawbacks of a highly detailed initial scope, adapting to change, and preventing project creep. Scoping software projects the Agile way means developers can concentrate more of their time creating fantastic code, and business stakeholders have peace of mind that their organization is taking full advantage of the latest digital opportunities.


The reason I chose this article is because I know that in software development, we must learn how to create applications in an efficient and straight forward manner. I know that it is difficult to measure the amount of effort it may take to accomplish a task as well as unexpected challenges that might occur. The importance of a well-run team allows for applications to be developed to the best of its abilities.

What I Learned:

I learned that Agile principles help instill a certain level of discipline early on to support the development of software. The agile methodology focuses on a highly detailed initial scop but that doesn’t mean it’s always the best. In doing something so highly detailed, you consume valuable time, create unnecessary delays, there may be a lack of budget clarity, and may be complicated by organizations that don’t know what they need. A lot of the time you don’t know what is going to happen so a team need to be equipped to tackle those issues and agile is built for it. Agile helps absorb negative impact of change by incorporating it at the scoping stage and throughout the rest of the project. Project creep is also something that occurs and that is when the work requirements begin to inflate after a project has begun. With the agile approach, it helps diminish project creep by not being distracted beyond the immediate horizon, like-for-like workload swapping, and contingency tolerance. Not being distracted allows for a developer’s understanding of future stages in a project to remain loosely defined as long as it is practical even with changes to the cope. Like-for-like workload swapping is the last minute desire to abandon requirement X while simultaneously prioritizing the creation of a new requirement Y. A contingency tolerance is when Agile tricks have been exhausted, there is essentially an emergency fund of time that can be dipped into so that the project timelines stay on track.


From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.


Welcome to my blog, here you will be able to follow my journey about the things I learn and the projects I will be working on. As an aspiring software engineer, this blog will be able to show employers and others not only what I am capable of but the also how much fun I have coding the things that I want.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Dig Deeper: Depth not Breadth

Photo by Laura Stanley on

Learning things is difficult much of the time, and when being pressured to learn something (or even multiple things at a time) for some impending deadline or project responsibility, it can feel like there just isn’t enough time to warrant building a truly deep understanding during that period. The more items on the todo-list, the less time then is able to be spent on each item, leaving a very shallow understanding which is simply good enough to satisfy the given problem or context exactly.

The idea of learning in a shallow sense versus learning deeply is discussed in chapter 6 of Apprenticeship Patterns. Dig Deeper refers to the idea of making an effort to learn about tools, languages, or other areas of study to more than just the necessary degree to complete the current project. The authors argue that to always remain focused on finding a solution, rather than learning about why that solution works can make the overall understanding of the subject relatively shallow. Focusing solely on “your part” of the project can leave you lacking in comprehension regarding everything else, and so it is beneficial to look into relevant context, supporting ideas which build the foundations of the solution to the problem, and the documentation associated with the solution. The idea is to focus on depth of understanding, rather than breadth of topics covered.

In practice this seems difficult to implement one-hundred percent of the time, as time constraints will likely impede any efforts to understand everything in a way which is absolutely comprehensive. But for important ideas, subjects which will likely form integral, foundational aspects of a program or project, it makes sense to learn as much as possible about them so that if something goes wrong, you will have the knowledge to fix it. Choosing which topics to use this sort of approach for is a judgement call which should most likely rely heavily on context (as with most of the patterns discussed in this book).

While I wouldn’t necessarily want to use this approach all the time, I can definitely see the benefit of learning about the context and deeper ideas associated with topics such as new programming languages, database management, or frameworks like the .NET framework, which is associated with Windows-based development. Topics which are especially interesting in this regard (in my opinion) are game development and GUI frameworks, where there are often a large array of interconnecting components, panels, windows and tools associated. Learning the tools becomes almost like learning another language within the language itself.

Book referenced:

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.

The Long Road of Progress

Photo by Anastasiya Vragova on

The long-term development of a career and set of skills is something not often focused on when discussing professional fields, rather the immediate benefits of that career (money, prestige, the conceptual notions of ‘success’) are more often discussed than not. While succeeding and generating an income are both important aspects of a career, the process of acquiring new skills and knowledge over the span of that career is just as important, if not moreso.

In chapter 3 of Apprenticeship Patterns, (link:, Walking the Long Road discusses the idea of focusing on the journey (learning) rather than the destination (money/success). While the authors acknowledge that these things can often come together with the acquisition of knowledge, the main idea is that learning itself should be (or should become) a rewarding process over the course of a career in software development/programming. Rather than focusing on the “goal” when trying to improve, the goal rather should be trying to improve indefinitely.

This idea of constantly learning and focusing on the process of improvement rather than a high-paying position is appealing to me, as it focuses more on the creative and constructive possibilities of programming rather than on simply turning a skill into profit outright. While income is a necessity and a benefit overall, oftentimes many of the best paying jobs seem to be “manager” type positions where you might spend more time delegating tasks to others than working on those things yourself. The benefit of having higher income is unfortunately offset by the downside of being unable to accumulate practical experience in the process.

I would estimate then that the best positions relative to constant improvement would be ones where creative solutions are possible, or maybe even encouraged. Open-ended problems often seem to involve improvisation or learning new skills by necessity, and in many cases software development does seem to involve this kind of thinking. I would imagine that active development jobs are best when operating with these goals of self-development, since they so often involve open-ended problems which require learning new concepts.

While I do think that focusing on knowledge for the sake of it is a good way to approach things in relation to career development, finding a balance of learning and exercising known or learned skills is important as well. This pattern focuses on the long-term journey, but I think the shorter term “refinement” of maybe more familiar ideas is similarly important. A healthy balance between these two areas is likely best in practice.

Text Referenced: Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.

Benefits of Recording What You Learn

Photo by Ann Nekr on

Oftentimes when doing something repeatedly, whether that be some sort of skill or action which needs to be learned over time, it can become sort of “mindless” as you gain familiarity with the subject. So even as you become familiar with the idea or concept, you no longer think about doing it even as you practice or utilize it more and more often. Because of this, some ideas can feel like they are more “drilled” than actually understood and comprehended, losing the sort of comprehensive fundamental knowledge that would come from a more complete understanding. If you just learn something to use as part of a larger project or system, then it can be very easy to develop an incomplete perception of the concept, and this is an area where I found the pattern “Record What You Learn” to be relevant.

Discussed in chapter 5 of Apprenticeship Patterns,, the concept of “Record What You Learn” is concerned with the idea of writing down or ideas, techniques and technologies/skills which you might use throughout the course of projects or development periods. Relative to software development, sometimes an application can be made up of many smaller pieces or technologies (ie: a web-application consisting of Vue.js, Express.js, REST-API, MongoDB, running in Docker) which you might need to become familiar and competent with during development quickly. However, needing to learn about many different technologies at once can leave gaps in your overall understanding, and you might end up needing to reference manuals or guides often.

The benefit of writing these things down becomes apparent when you can look back to your own notes or documentation and reference them in the future, and as opposed to simply looking into the documentation written by the maintainers or developers of the tool in question, your own personal notes will likely contain useful context and explanation which could be lacking from standard syntax guides or official websites. Maybe you find a way to save time working in C++, when you write that time-saving measure down it becomes far easier to repeat in the future.

If you constantly reference your own notes it helps to reinforce those ideas more than referencing something written by an external source because you are rereading your own thoughts and ideas relative to the concept. I have recorded notes for things I have been learning in the past (HTML/CSS and web-development, Java, C#) and I think that it makes a difference to have your own notes with added context. The connection to your thought process and ideas helps the concepts sink-in, and writing them down makes you think about them more than you might otherwise.

Book Referenced:

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.

Code Review: Benefits of a Second Look

Photo by Pew Nguyen on

After a piece of software, whether that be the project as a whole or simply one component as part of a system has been completed, it makes sense to give the final product a sort of “look-over” to make sure that everything is working as intended and meets any required specifications. This is something which generally seems to be good practice to follow anyway in my opinion, since it could be easy to overlook something during the development process. It can be easy to become hyper-focused on one thing or another when working on larger projects with multiple components, which could lead to the potential to forget or leave-out some minor (or major) requirements, introduce bugs or flaws, or otherwise implement things in a way which is inefficient or ineffective.

This is where the more formally defined process of “Code Review” is beneficial. While looking into the process, I found this helpful writeup from Atlassian: ( which goes into great detail regarding the practice. Overall, the process involves looking for any clearly visible bugs or issues with the code, as well as considering logic errors and concerns. The finished code/components is compared to the requirements of the project, and any test-cases or testing methodologies used are evaluated (how complete is the test coverage, should any new tests be added?). Additionally the code is compared to preexisting code (referred to as “style guidelines” in the post by Atlassian) which exists within the same space or project to promote consistency and cohesiveness.

Compared to the process I described earlier, the formal definition of Code Review provided by Atlassian hits many of the same key areas. The finished piece or product is examined in relation to any requirements, testing/test cases are examined to determine coverage and whether any additional tests are necessary, and bugs, errors, or logical flaws are sought out and fixed where they have occurred. I would say that the last point regarding “style guidelines” is less important, especially in solo-development environments where you might not be working in a team. Regardless it still seems like a good thing to keep in mind when working in larger group applications. Code review is a helpful and largely effective way to take a second look after the main development process is complete and make sure that the final product is what it was intended to be.

Article Referenced:

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.