Category Archives: Blog

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.

Mocking: Benefits & Drawbacks

Photo by Blue Bird on

When working on a piece of software or project, often I will encounter a point where some particular piece of the program cannot be tested properly due to one or more components or features not being completed yet. Rather than waiting until all these things are completed, and potentially rushing them to completion in order to do testing, mocking allows me to bypass the issue and use a “mock” version of the missing dependency or component needed for testing.

This is a convenient way to get around having to develop the entire program all at once before being able to test anything, which could arguably lead to more errors or issues over time since you then aren’t able to test as you implement features, but rather only after they have all been implemented. This aspect alone makes mocking seem like an overtly beneficial concept. But there are some drawbacks to consider with mocking, some of which I will discuss below.

When researching the concept of mocking, I found this article: ( to raise some good points in regards to both the upsides and downsides of the practice. The author of this blog post brings up three major downsides to mocking, those being that a.) mocking can violate the DRY principle ( ‘Don’t Repeat Yourself’, b.) mocking can complicate refactoring or reorganizing code, c.) mocking can add to the complication of your code in general.

In regards to the first issue, repetition, I think that in some cases that this can be justified, and while mocking does represent some duplication in that it is taking a preexisting piece of the program and creating a placeholder for it, this seems unlikely to have the same negative effects that say, having three different train classes which only differ in the value of their color attribute.

The second and third points regarding refactoring and complication of the program seem like legitimate pitfalls to watch out for. When restructuring, the various mocks present could no longer be applicable based on changes in the location of various dependencies and test-cases in relation to them. Mocking does introduce an additional layer of complexity which would not otherwise be present, definitely a fair concern to consider.

Overall, I would say that most of the issues associated with mocking which are described by the author can be mitigated or completely avoided provided that they are considered during development. Mocking still seems in general to be a benefit in relation to testing during development rather than after it has been feature-completed.

Articles Referenced:

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

Testing With JUnit 5

Photo by Markus Spiske on

Recently I was introduced to JUnit 5 as a testing framework for Java programs, mainly for the purposes of one of the courses I am taking currently. While I have in the past used methods such as print statements (to test for expected outputs and debug) or using the built-in IDE debugging functions (breakpoints mainly), this was often time-consuming and not easy to scale. When trying to test for a number of different conditions or desired results from a section of the program, I would often end up writing conditional logic just for testing purposes which would end up getting deleted later on in the finished program.

JUnit seems like a relatively logical progression from this process, instead of writing numerous checks and conditional statements into the working code of the program, test classes can be used to rapidly test many different conditions or input/outputs at once. This allows for me to keep the main code of the program neater and to avoid the time consuming process of having to continually write tests or print out values in order to test that everything is functioning properly. JUnit overall is a more efficient way to go about the process.

In the past, I had used an older version of JUnit (JUnit 4) to test an older project from a number of years ago. I found this blog post from Java Magazine ( was able to highlight many of the major changes and differences between JUnit versions 4 and 5 clearly. Generally, JUnit 5 differs the most in it’s organization into various modules, while older versions of the framework would include all features irregardless of which ones might actually be needed at the time.

Additionally, more recent Java features such as lambda functions (absolutely useful within the context of running tests) make this version of JUnit more powerful than earlier editions.

I would consider JUnit 5 to be one of the better options at present for testing and debugging Java programs and will likely continue to utilize this framework until it inevitably sees a version 6 release.

Article Referenced:

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