Author Archives: toomeymatt1515

Sprint 3 Retrospective

Photo by Tim Gouw on

For the final stretch of our allotted development time working with the InventorySystem component for the Thea’s Pantry project, we focused largely on getting all the frameworks (frontend, backend, database) into a functional state for the next team taking over on the project. I focused much of my time on getting our frontend components pushed to the container registry for the project on Gitlab:,

Originally I had wanted to implement automatic uploading to the container registry using a Gitlab-CI file, but encountered numerous issues related to the file-structure of our frontend projects, Gitlab’s continuous integration system not being able to find certain files, and problems during the build stage throughout the deployment process. As a result of this I eventually decided on using Docker-Compose to push the components to the container registry. While this won’t be able to execute automatically in the same way as a CI file, It was more important to have working containers pushed to the registry for the next team to be able to work with.

Throughout sprint #3, we were able to finish off some of the outstanding issues which were leftover from previous sprints, we finalized parts of the backend framework and implemented partial functionality, finished setting up all three frontend frameworks for future polish and development , and were able to implement a basic database for storing inventory-weight, as well as some further polish/refinement of the API

Additionally, one team member worked on the Identity Access Management system used for the project, Keycloak, and was able to create working frontend and backend environments for using the system to verify users/determine whether someone has appropriate permissions to access certain pages/fields: Everyone seemed to accomplish a lot this sprint, and I think that we were able to leave the InventorySystem at a good starting point for the next group of people who end up working on it.

If I could have done anything different, I would likely have spent more time on trying to get the CI-file working as intended, as automatic integration/deployment of the project would be more convenient for developers than having to manually push to the container registry each time changes are made. Also, I think that the Vue components for each of the frontends I worked on could have been polished some more (add features such as slideshows, responsive page design, stylized buttons/appearance) but those would very much have been low-priority issues to be focusing on.

Each of the three sprints had different focuses, with the first sprint being focused on learning the tools we were working with, and the second sprint being centered around building the foundational aspects of the project as a framework for future functionality and development.

This third sprint felt like finishing off all of the frameworks, some polish, and getting everything ready to be worked on further. I think that we accomplished a lot as a team over the course of around three months; this was a great learning experience which felt essentially like working in a professional development context. I look forward to the next opportunity I have to work in a similar environment, and wish my teammates well in their future endeavors.

From the blog CS@Worcester – CodeRoad by toomeymatt1515 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.

Confront Your Ignorance: Filling in the Gaps

Photo by Ann H on

Software development often involves a large variety of interconnected tools, patterns, standards and ideas which must be understood at a functional level to be able successfully apply them to the project at hand. Sometimes the sheer number of things which require your understanding can feel overwhelming, and going into a project without knowing absolutely everything you might need to know often leads to stress regarding the gaps in knowledge versus what is required.

The pattern discussed in chapter 2 of Apprenticeship Patterns, (link: discusses the idea of confronting your ignorance, by which the authors mean that you should seek out and eliminate any holes or gaps in your knowledge, rather than allowing the “ignorance” to be a detriment to yourself. More specifically, the pattern describes the process of picking one skill, language or technology to focus on at a time, and working to better your understanding of that one idea. Rather than trying to focus on everything at once, you focus on learning one skill at a time, generating a more “precise” understanding of it than if it were being lumped together with other subjects.

This idea makes a lot of sense, intuitively you might think it would be second nature to begin learning a new topic by focusing only on that topic instead of trying to do everything all at the same time, but often that is exactly what ends up happening. Whenever there is a larger “stack” of tools to learn, I sometimes find myself actively trying to absorb everything all at once, because I feel that maybe slowing down and taking each single tool or topic on by itself might slow things down too much. This hesitance not to “multitask” when learning new ideas makes it harder to really focus on any one thing when trying to become familiar with a large number of tools and ideas in a short timeframe.

Overall the major ideas of Confront Your Ignorance are simple, and easy to implement , the big drawback being the time it will likely take to focus exclusively on one topic can often take time away from other activities. Like most patterns discussed in Apprenticeship Patterns, finding an effective balance between this pattern and others is important and likely dependent on context most of the time.

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.

Sprint 2 Retrospective

Photo by Kaique Rocha on

During our second sprint for the InventorySystem project, we focused primarily on getting basic “skeleton” systems in-place. By this I mean that we tried to get simpler versions of each of our components working so that they could be used as a baseline for future development. The frontend, backend, database and IAM (Identity & Access Management) systems were focused on primarily throughout this period of work.

I would say that we likely had a proper amount of work planned for development, during this sprint our team was actually bigger, so it was a great help to have more people around to work on development tasks. Because of the larger team, we were able to split-off and each focus on a specific area of the project more effectively.

Two people focused on the frontend (one person worked on one of three necessary frontends each) since there was the project requires multiple front-end interfaces to function. One person focused on the IAM system specifically, and one person focused on the backend system initially. As the sprint progressed, everyone generally was able to complete the majority of necessary tasks, and the project went from having lots of documentation with little working code/examples to having a collection of basic interfaces and systems.

One difficulty I faced specifically was in trying to decide on the appearance & layout of the frontend I worked on during the sprint. Because the preexisting site for the food pantry exists only as a page on the main WSU website, I didn’t have much to go off-of for design besides the general color choices and logo design provided by the university. Something which I found helpful was to organize a meeting with the other teams working on the project, and to ask some questions regarding their process and design choices for their own front-ends. Additionally I was able to get some good advice and feedback from others on my own team based on the development of their frontend components for the project.

I think that having more team members definitely helped our team to be more productive, the process of “splitting-up” tasks worked a lot better this time around because of it. Previously the idea of each person “specializing” seemed harder to achieve, as despite the benefits of distributing the work, there were less people overall, and focusing on one thing meant that other areas would lose out on development focus. Now having a bigger team we were able to use this to our advantage and distribute work more effectively throughout the sprint.

In terms of communication, we used GitLab throughout this sprint to coordinate our efforts, and it seemed like everyone was more used to the process of creating issues and communicating concerns/ideas regarding those issues throughout development. Here: is one of the issues I worked on, and generally I tried to include things like screenshots of the work I was doing, links to the repository for any code or examples I had worked on, and descriptions included in the comments regarding the process and anything I might have concerns about. Other team members used Gitlab similarly, posting links to relevant resources which could be helpful to others, linking to their work/posting screenshots and describing any difficulties or issues they ran into. Overall I think it has been an excellent tool for organizing our work for the project, as a place to discuss problems related to it, and as a major source of reference.

Conclusively, I think that this sprint went well, and we were able to get some good progress in over the course of ~5 weeks or so. The increase in the size of our team, being used to the process of using Gitlab for coordination, and overall focus on creating “useable” mock-up and skeleton framework code seemed to allow for increased productivity during the sprint.

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

Building A Reading List

Photo by Skylar Kang on

There is more information available today than ever before, largely thanks to the advent of the internet and the ease with which that information can now be accessed as a result. Because of this increase in available information, the choices can often seem daunting when attempting to choose any source in particular. Especially when searching out books to look into regarding a specific topic, the sheer variety and number of options on even very niche topics makes it hard to make a decision on any one of them to study from.

Concerning the problem I just described, the pattern discussed in section 6 of of Apprenticeship Patterns, Reading List, outlines a useful technique for organizing the seemingly endless collection of books and reading which accumulates when studying a topic. The general idea is to keep a literal reading list, with all of the books (or other sources) you plan to read, reference, or look into recorded for the future. While the text seems to approach this from the context of physical books, I see no reason why this wouldn’t apply to any sort of reference, manual, or other self-educational materials in practice.

Additionally, the authors of Apprenticeship Patterns recommend maintaining the list as a priority queue, in that more important books or references will be studied first, before continuing down the list in order of importance. This seems like a good idea as it makes it easier to prioritize learning things in a more efficient order; subjects or topics which are less important would naturally proceed to rank lower and lower on the list and might eventually be removed if they stay towards the bottom for too long.

This process of removing dead-ends and passed topics of interest would keep the reading list relevant in the long term and help to maintain cohesion (it seems likely that irrelevant topics or sources would naturally begin to rank lower on the list, organically moving them out of the list over time).

Very probably in the near future, I will begin my own reading list, keeping track of prospective sources of information and reference which I feel will be interesting or useful to study. Considering the relative ease of implementing this pattern (keep a list), I would say that it is an easy way to optimize learning or research regarding any topic, but in the context of software development it seems even more relevant still. As there are oftentimes many disparate syntax manuals, tutorials, and textbooks to learn from which could benefit from the concrete organization afforded by a reading list.

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.

Your First Language: How it Affects Everything Else

The Your First Language pattern, discussed in chapter 2 of Apprenticeship Patterns, concerns the idea of someone picking their first programming language, how they should choose it, what they should do with it once they become proficient, and how it might affect future efforts to learn other languages. I thought that this aspect in particular was very relevant to my own experiences. I first started learning to program in Java, and as a result I find that I tend to look at things in relation to how they might work in Java rather than from the perspective of whatever language I might be working in.

Regarding the text, Apprenticeship Patterns discusses the idea in terms of how it might play into someone’s career over time. If you learn one language first, and put a majority of your development time into that language, then it makes sense that this would impact your views and understanding of other languages. Various techniques are offered in terms of actually learning the language, including building of toy programs (similar to those discussed in the breakable toys pattern), learning through testing frameworks (implementing test cases and using them to understand how the language works), or finding mentors who are already experienced in the language to provide guidance and advice.

In terms of how this is relevant to myself, I certainly feel that starting with an object oriented language has made me more predisposed to prefer this style of programming over others. This can at times make me feel out-of-depth when working with other styles of programming language (functional, scripting, procedural) as object oriented programming is the most familiar to me. The authors of Apprenticeship Patterns recommend trying to learn as many different style of programming language as possible to avoid getting “stuck” in one language.

Going outside of the “comfort zone” so to speak, is a good way to broaden your range of experience relative to any topic in a general sense. In terms of using this approach myself, I would likely first start by taking a smaller step away from more familiar Java-similar languages (python, ruby etc) before moving on to something completely dissimilar to Java (F#, Lua, R etc). This would help broaden my area of knowledge and allow for a greater range of potential solutions when developing software.

Text referenced:

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