Category Archives: Blog

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.

CS-448 Introduction

Photo by Taryn Elliott on

This course is the capstone (final) Software Development course I will be taking to complete my Computer Science major at Worcester State University. We will be working with the LibreFoodPantry project ( to develop software for use in managing food pantries.

This project is free and open source (FOSS) which seems like a good way to ensure that anyone who is interested could modify and improve aspects of the software without running into legal issues. Developing software as free and open source opens up more possibilities for creativity and improvement over time since there are less barriers to entry for working on the project.

I am excited to begin contributing to the LibreFoodPantry Project over the course of the semester, and look forward to gaining experience working on a larger-scale project with a team, as much of my development experience comes from smaller scale development that I have done largely on my own.

Learning to work as part of a larger group will no doubt prove to be valuable experience in terms of preparation for creating software in a workplace environment, as software development often tends to be a group effort.

LibreFoodPantry’s website:

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

REST API Design Practices

What is REST API? - Seobility Wiki

For many assignments in a recent class, I had the opportunity to use and learn about REST (Representational State Transfer) API in relation to simple web applications. In working with REST, I was unsure about some of the syntax and conventions used with the API, namely the difference between different response types (JSON vs String response for instance).

I looked into finding some more information on good practices for REST API projects, and according to a helpful blog post I found on Stack Overflow (, REST APIs should generally both request and send responses with JSON (JavaScript Object Notation). I had a number of issues with sending and receiving data which was not in this format (needed to send/receive strings in POST methods within an endpoint). This was causing problems such as information not being sent and received properly (name field of an item not being sent or received in the right places) as well as issues with the functioning of the web application itself (endpoints belonging to unrelated services would cease to function properly if the requests and responses were not JSON.

Furthermore, according to the author, JavaScript has baked-in methods to handle interacting with JSON entities, which makes it easier to use overall especially if there are other JavaScript based technologies being used within the structure of the project, so it makes sense to use JSON within requests/responses. So in future projects involving REST, I will attempt to primarily use JSON objects for responses and requests to ensure compatibility and easy access through JavaScript.

Another point which was discussed was the importance of using nouns in naming conventions, rather than verbs (specifically nouns which are highly representative of the destination or object being affected) when naming endpoint paths. IE: instead of POST: /orderPizza/, use POST /order/ when trying to create a new order. This makes sense, as the HTTP methods typically describe the action or verb being enacted on an object, so you needn’t describe that within the endpoint path.

Finally, I want to discuss the topic of HTTP status codes; the author of this article describes the meaning of many common error codes and why you might return them as a response. This was especially helpful for me as I had been using these codes within a REST project, but had no idea what the majority of them actually meant. According to the article, a code of 400 indicates a client-side validation error, 401 represents an authorization or permissions error, and 404 represents an inability to find a particular resource. Out of all of these errors, 404 is definitely the most common from my experience. I have frequently seen this while using the internet whenever a page would couldn’t be found on a website/web application, it was pretty neat to learn more about.

What is a 404 Page? - Learn to code in 30 Days
Example of a common 404 not found error page

Overall, after reading this article I feel more informed about the way REST API services work, and will be more prepared for the next project I work which makes use of the framework.

Post Referenced:

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

Software Architectural Patterns and Their Uses

Image for post

When working with larger projects, a unified system or pattern can be useful in keeping things organized and cohesive over time. Design patterns can be applied to general problems in software development, such as creating many similar objects with slight differences from a factory class which handles object creation within the program, or using decorators in a program to add specific attributes or behaviors on a per-object basis. But while these design patterns are helpful for solving singular problems, they often lack the scope necessary to layout and plan the entirety of a project or large program or application.

Architectural Patterns

I found an article written on the blogging platform Medium which briefly explained the concept of Architectural patterns, which refer to higher-level guidelines and decisions made regarding a piece of software as a whole, rather than one specific problem within the code. This was confusing at first, but as the article provided brief explanations (and examples) of various architectural patterns, I was able to grasp the concept more conclusively. Now I will go into detail regarding two patterns I found likely to be useful and the kinds of programs they would be most applicable to.

The Layered Pattern uses a system of layers to group together similar functionality for ease of access and organization. Layers can set access rules for other layers (layer C has access to layers A and B, layer C only has access to layer B). For example, imagine a solitaire program, one layer controls drawing and taking input for interface components (windows, buttons, score etc) while another layer could contain the logical rules of the game solitaire, mechanics and random distribution of the cards (things the user would never need to access directly). For applications where there are a lot of similar behaviors which could be easily grouped into layers, the layered pattern makes a lot of sense.

Additionally, the Multi-tier pattern also concerns layers, in this case, entire systems (complete features, ie: user-input for input related features, display for display features) are grouped into tiers. A tier is a grouping of elements within the program which are interrelated, and seem most often used in web-related capacities or in online applications with various segments to consider (web browser, web, front-end and back-end could be potential tiers). Since each component or feature can only be part of one tier, individual tier choices will need to be carefully considered. Another major drawback is the amount of setup that goes into the process of implementation, since each of the tiers needs to exist as a grouping before the components can be assigned. I think this pattern would be most useful for large projects spanning multiple languages and technologies in the real world (web-applications for example, with front-end, back-end, browser components).

While I only highlighted two of the patterns discussed in this blog post, I think that layered and multi-tier patterns will be most useful for small-medium (layered) and large projects (multi-tier) in general.

Site referenced:

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

YAGNI Design Principle & Redundancy

Photo by Nataliya Vaitkevich on

Oftentimes, when programming in an object-oriented language, I have the issue of unintended redundancies. I write things to be too verbose; long variable names (studentClassId, carManufacturerName), with unnecessary complications, methods and variables that could easily be removed from my code without losing anything. My reasoning in these cases is always ‘this will make my code easier to read’, or ‘specificity is always a good thing’, but more often than not, this results in messy code with complicated loops and if-statements, where a simpler approach would be much easier to work with in the long run. Over time, larger projects can get to be a huge issue, the more convoluted the code becomes, the harder it is to look at and understand after a few days.

A good example of this problem would be to imagine a simple program which simulates various cars. Instead of having a central car class which handles the definition of a car, (wheels, doors, engine etc), I might have a car class which has instances of wheel, door, and engine classes, which have their own instances of ‘wheelTireType’ (which can be one of three types of wheels), and also similarly needless complication for the doors and engine.

While being specific can be a good practice some of the time, I tend to take it overboard sometimes and end up making classes like ‘carDoorType’ when I could have just as easily had an integer ‘numberOfDoors’ variable and gotten the same effect without introducing an extra, functionally useless class.

When reading an excerpt from Google’s testing blog, I found the principle of YAGNI (“You Aren’t Gonna Need It”) to be of interest. The idea is that you should keep an eye out for unnecessary code and remove it/refactor your code without the unneeded parts. The blog post gives a good list of “code smells” associated with the YAGNI design principle, including code which never executes (“Just in case” code), code which is only executed by tests, and is never used in the actual running of the program, and variables which are redundant.

Out of all of these issues, I definitely struggle the most with redundancy, and recognize that it is something I need to work on overall. Many times while writing Java code, I have created methods and classes simply out of the belief that I “may” need them later on and that this saves me time spent creating these classes later. While this makes sense at the time, coming back to the code later I just end up with a lot of unused classes which end up getting deleted anyway, negating any time savings.

I suspect that going back to some old projects and attempting to refactor them with the YAGNI design principle in mind would be a good way to practice. While it seems rather self-explanatory at first, I think that approaching projects with the intent of preventing redundancy will produce considerable improvements in any future designs going forward.

Site Referenced:

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

Uses, Drawbacks, and Additions to JavaScript in 2020

Photo by cottonbro on

In web development, the development of web applications (software accessed through a web browser) and even game development, JavaScript is used to add interactivity and function to what would otherwise be static webpages, and to create software which runs entirely within users’ web browsers. And while JavaScript is undoubtedly useful in the contexts of web and software development, there are some aspects of the language which I feel are somewhat lacking compared to other programming languages.

For one, compared to its namesake Java, JavaScript is somewhat lacking in terms of its ability to create objects. While objects are a part of JavaScript, creating classes is very nonspecific compared to Java. For example, say I want to create an apple class in Java and in JavaScript, for Java, I would need to create a separate class file:

public class Apple {
   String color;
   public Apple()
       color = "red";
       System.out.println("I am a " + color + " apple!");

Whereas with JavaScript, it would look something like this:

class Apple {
  constructor() {
   this.color = "red";
   console.log("I am a " + color + " apple!");

While not being strongly typed does have advantages (flexibility of variables, ability to write code which returns a different type depending on context/necessity) I prefer the strong typing of languages such as Java and C#. Strong typing helps to make code more readable, without specifying the type of a variable before using it (ie: var fruit = “apple”;), it can be unclear what a variable is intended for at first glance (especially if there are many similar variables storing similar values). With strong typing, you are always clear on what type of data is meant to be stored inside of a particular variable, (int studentID is clearly only meant to store integer values, while String studentName is only meant to store String values).

JavaScript continues to grow and develop as a language, and new features are constantly being implemented. When reading about some of these new features being added to JavaScript this year, I found a blog post discussing some of the more interesting features which were implemented in 2020. The post served as a good introduction, and offered clear information about each of the new additions discussed.

Private & Static Fields

Something which was absent from JavaScript was the ability to use access modifiers for fields. This year, the ability to use private, or static fields was added to JavaScript; private fields will allow for greater security and the ability to ‘wall off’ access to certain fields, while static fields will allow for the creation of ‘class-scope’ attributes.


Another complaint which I have had about JavaScript is the fact that JavaScript only has one number type. While the introduction of the BigInt type does not solve this issue, it does allow for larger numbers to be represented in JavaScript. It functions similarly to the Java ‘Long’ datatype, in that it can store very long number values.

While JavaScript is still missing some features which I enjoy from other languages, these recent additions make it more versatile than ever, and JavaScript continues to be the de-facto language for developing anything interactive on the internet.

Site Referenced:

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