Author Archives: Jared Moore

Use the Source

Programming involves applying the right pattern to a wide variety of scenarios. A way to learn how to apply those patterns is to analyze how other people have done them. One of the best ways to do this is by reviewing the publicly written code by someone who has published open-source code. Reading and understanding the craft a master has created, it will spawn ideas within you as to how to improve your own programming patterns and creations.  

I find it interesting that it gets easier to read someone else’s code the more that you read it and that the faster you can comprehend code is an indication of your level of mastery. I also found it to be an interesting recommendation to use git to track the history of code over time to view how it is improved. Doing this will help you identify the type of errors that passed inspection but eventually needed to be fixed or modified. In the future, you will be able to apply the patterns you observed to the code you write yourself.

I often program using TypeScript and open-source npm packages. Oftentimes with smaller node packages, they lack full documentation of the entire codebase. When this happens, I use my IDE’s source inspection tool to look at the function within the node package to understand how the package classes and functions work. There are also times when there is a node package written in JavaScript that does not come with predefined TypeScript type definitions.

To use these node packages with type safety, I write my own type definitions by inspecting the source code for the open-source package I am using. To some degree, I have already been reading the source, but not with the sole purpose of reading and learning the patterns of the software’s author. In the future, I will spend more time appreciating that I am looking at someone else’s craft that they fine-tuned to the best of their ability. Making sure to learn and take away as much as I can from their programming. I do not disagree with anything in this pattern, as viewing the source is something that I have already made a habit of doing.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

The course of our sprint was good, we completed large sections on the frontend and backend from the last sprint to get the necessary functionality to integrate the front end and backend together. We achieved our sprint goals by all agreeing on what was most important to focus on in the sprint, which helped us on completing our ultimate sprint objective. We structured our issues in such a way that they were less dependent on each other for completion. This strategy maximized the number of issues that could be completed without having to wait for someone to submit their issue first.

Keeping in mind the lessons from our previous sprints, we continued to work in small branches dedicated to one issue at a time. There was minimal code divergence because of our fast branch, merge, branch strategy. It was tempting to keep developing in the same branch, but with the small size of our project, the structure of our project changed very quickly. Merging large branches together often resulted in breaking code in the past. By our third sprint, we had developed a great workflow and collaborated seamlessly. Two large braking changes we made this sprint were updating the port numbers for the backend and frontend as well as updating the fields within the guest info record.

With our workflow and communication, our team updated internal ports, mapped them to docker images, and reflected the changes in docker-compose files for code in multiple repositions. All while maintaining integration of the frontend and backend code. We also had to remove and add new fields for the guest record. This required modifying the OpenAPI Schema, handling the changes in the backend, and modifying the form on the frontend. By doing small branches in coordination with our team members, these major changes were made without issue. If this was our first sprint, things would have been more difficult. I see the ease at which we made these major updates as evidence of how much we have developed over the semester.

Overall, there were no significant indefinable changes we should make as a team. As always, we should aim to communicate with each other to the best of our ability. In my opinion, we did this well and left little room for a need to improve. Although our in-team communication was excellent, one area that still needs improvement is our communication between teams. We improved on this compared to the last sprint by working with other teams using the credit card scanner, sharing CSS styling, and meeting with the Kubernetes team to discuss integration. However, we wanted to implement keycloak this sprint, but we did not accomplish that task. The reason for this was both due to running out of time and failing to have enough dialogue with the IAM team to learn how their system would integrate with our system. If we had the fourth sprint, I am sure we would be able to learn from our experience and succeed at implementing these features in the future.

Overall, I improved significantly between sprint one and sprint three. I could still improve the amount of communication I have from team to team and take it upon myself to reach out more. I did do this during sprint three more than I had in the previous sprints, but improvement could be made in the number of times I reached out.

Issues Completed During Sprint 3

∙ Create a second connector class for sending data to RabbitMQ to make changing RabbitMQ for another message broker-client simple without updating its use through the code. []

∙ Fix the issue where adding a new guest via API request on the backend throws server error and does not add new gues to the database or RabbitMQ []

∙ Create an environmental variable for delaying the start of the NodeJS server to wait for the RabbitMQ instance to be ready for connection []

∙ Remove and add new fields for the guest record within the OpenAPI for the GuestInfoSystem as well as modify the backend to handle these changes []

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

Find Mentors

Programming alone can be difficult with unclear paths to take with lots of uncertainty about which approach will be the best. Without someone who can give you guidance, it makes it difficult to move forward alone. It is necessary to find a mentor who will be there to guide you in times of uncertainty. The mentor you find does not need to be someone who knows all, but someone who has more knowledge and experience than you in a particular programming area. Finding a mentor requires a lot of searching because they may be hard to find, especially finding someone who is willing to spend the time to help. However, when you find one, they will provide a world of experience.

I found it interesting the author himself found a mentor after a few years of already being a programmer. It shows that it is never too late to find someone who knows more than you and to ask for help. This practice relates back to a previous pattern about exposing your ignorance. You must be willing to do this in order to get the proper guidance.

This pattern focuses on the theme of approaching programming as a craft where you must start as an apprentice. This reminds me of my grandfather who was a carpenter. When he was young, he started small jobs without much knowledge. He learned from the other men on the job who were eager to teach him what they knew. Eventually, he learned as much as they did and in his later years went on to share his knowledge with those who were younger just learning their craft.

After reading this far into the book, I have reshaped the way I view the development landscape. I feel that it requires the perspective of apprenticeship and the need for finding others to help you develop your craft. I think it is possible that at the same time you are being mentored, you can also be mentoring someone else. There are no areas in this pattern where I disagree with the author. I find that his recommendations and personal experience are well thought out and are great advice.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

The Long Road

You should plan for the long run and not focus on short-term goals. The further out you plan for yourself the better you will be prepared for unexpected challenges. If you want to program for a very long time, then you’ll be more skilled than people who are newly coming into the field and this will benefit you. It is important that being a master at the craft is the goal and not wealth or another position. It is important to stay motivated to program and not be distracted by nonessential things.

I find it interesting that it’s possible to get distracted over time while you’re at your job. I think it makes sense that over time you lose focus of the goal. It’s easy to be tempted by money to find a different job and stop programming. I think it was a good reminder to stay focused on your passion for becoming a master of the craft. Mastering the Long Road means balancing your work life and goals to meet a long-term desire for programming.

This pattern will help me focus on keeping my motivation for programming. It’s important to have an outlook of what you want in the future rather than just focusing day-to-day. Focusing on becoming a master at programming will also make money. But if you just focus on making money then you might not become a master. Someone motivated by money is not going to have the desire to learn to program. I personally have encountered this with friends who have software engineering jobs. They dislike their job and are only there for the money. They’re always looking for different opportunities and never spend time learning to program, they spend time trying to figure out how to get a different job.

I do not have any disagreement about what is discussed in this pattern. I think it is essential to stay motivated on the task of learning programming and not be distracted by other less important motivations. I think it is possible to have the motivation to become a project manager or a CIO while also maintaining your passion for programming. However, I think this pattern is correct in that the ultimate motivation should be about programming and nothing else.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

Craft over Art

It is important to create things beyond that what is expected. You should go above and beyond the specifications of the application and create something that will wow the product owner.

I think it’s interesting to look at software development as craftsmanship and what you create as art. I do think that programming is a form of art because you have to use your creativity to make anything that you produce. Being artistic is a good way to look at creating an application, especially one with a user interface because it is what people will be looking at whenever they interact with the software. You want something to look beautiful and appealing just like a piece of artwork. In my opinion, someone would be more likely to use attractive-looking software than one that is unappealing to the eyes. It’s also important to make something that’s easy to navigate because that enhances the user experience.

I typically try to go above and beyond in the project that I’m working on. It is good for personal growth and reflects well on my portfolio. It is nice to be able to show a future client past work and be proud of the artistic design element of what I created. I prefer working on the backend, but I do enjoy creating a nice UI that users enjoy interacting with.

I think it is important to put extra time and effort into the products that you are creating for your clients. However, I think it’s important to not get lost in the details of creating something more than they asked for. Sometimes it’s possible to add features and create things that the client might not want and then you are forced to remove them. There are other times where you might put in extra work, and you were taking time away from yourself for other projects that need attention. Even though it’s good to have just to have the learning experience, I think it’s also important to make sure that projects for clients, that you put in extra effort into, should get some form of acknowledgment.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Our sprint went well we wanted to finalize major features on the front end and the back end in order to have the necessary fully functioning for its operation. Our group collaborated on creating sprint objectives that we all agreed were important to focus on in the sprint. We ordered our work items in order from most to least important, which was helpful in focusing on getting the most relevant work done first. This helped later tasks because the issues below were dependent upon other issues being finished first.

Learning lessons from the last sprint, we managed our code much more efficiently this time around. We created a small branch for each time we were going to make a change to the CodeBase. Each one of these branches only changed a small portion of the code or added a small feature. Once we finish this change, we will immediately submit a merge request and have it incorporated into the code as soon as possible. This minimized the amount of divergence from other branches while people were working on their code. We had large stagnant branches that diverged from the other ones in the last sprint, and merging them became incredibly difficult. This time, we did small branches in merge consistently, which kept everyone’s codebase on track. We also set up testing, which still needs further tests, but this allows us to ensure that our changes are not going to break essential features when merged into the main branch.

We had one issue that some issues were dependent on other issues to be completed first. When one individual took longer than expected on an issue that required to be finished first before others could work on theirs, it left some students unable to work on essential features. In the future, it would make sense to re-distribute those tasks to individuals who were not being challenged or add another person to the issue to get it completed more quickly.

As a team, we did a good job at roughly keeping each other member aware of the current task we were working on. In the future, I think we could improve the detail of exactly what we are working on, which would help other team members adjust the priority of which issues they should be tackling. Overall, we did have a good improvement from the first sprint in communication. In this sprint, we also worked well at updating the sprint board and tasks as we finished and moved them onto the next stage.

For the final sprint, our team should work on creating broad goals that we want to achieve and turning those into smaller tasks that individuals can work on. At the end of the next sprint, our goal is to have a working front end and backend that can be deployed within a single docker container, and this will be broken down into smaller sub-tasks that each person can focus on achieving.

As I said for the teams’ comments, I should precisely make it what I am working on more well-known. This will improve the team’s performance because students will be able to choose their tasks better accordingly. I will enhance this during our standup meetings by going into more detail about my current tasks. I did improve over the last sprint and made sure to update the issues board so that two people do not work on the same issue simultaneously.

Issues Completed During Sprint 2

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

Breakable Toys

There are many critical systems that have no room for failures, such as banking software or a hospital’s patient management system. It is difficult to experiment with new features or try a new approach when a piece of software is heavily relied upon. In order to experiment with new things, you need to have a test environment where you can try out features. If these features turn out to be harmful or cause problems down the line, they will not affect the current user version of the software. Creating a playground environment allows you to not worry about breaking changes or failures cousin headaches for program users and other developers. Software that is a breakable toy means it is that something can be played with, broken, and replaced without impacting anyone else. It is a way to learn, test new workflows, and ideas.

It is hard to clone and play around with code when there is a complex system that requires a database, client, server, and other resources for its operation. Because of the work and resources to create a clone of an existing system, I would not have created a second replica of the system in the past. However, this pattern makes a strong enough argument for me to put in the effort to make a breakable system for testing. I thought it was interesting a breakable toy can also be a personal project where you are the only one who uses it. I thought of this almost like a programmer’s diary where you program your ideas in private and you are the only one who sees them.

I currently program with a pattern similar to breakable toys but on a smaller scale. When I want to add a new feature into a codebase, I make a testing branch where I can execute that idea. In my ‘toy’ branches, I do not have any intention of merging the code into the main branch, I only use it to play around with an idea to see how it might be executed. I do not disagree with any aspect of this pattern, although it is good to also be comfortable working in an environment where you have to be careful about the programming you do could have a major effect.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

The Deep End

Chapter Two’s is themed around growing your knowledge. The pattern “Confront Your Ignorance” follows this theme and focuses on working with projects that are outside of your expertise. When you feel as if each project you are working on is like the previous one, it means you are applying your existing knowledge. There is truly little chance to grow as a developer when you work strictly within the areas you are knowledgeable about. The ideal scenario is one where you are working outside of your area of expertise to maximize the amount of new experience you engage with.

In the future, I will be more willing to work on projects where I dive into a topic that I do not fully understand. I also feel that the action for this pattern, to map your projects in a timeline, is a useful way to track your personal development over time. A timeline is a terrific way to see if your learning has stagnated and it is time to jump into something new. This method is also a great way to see where you want to take your professional career and give you an opportunity to map into the future.

I found it interesting how large of a risk the author suggests taking regarding a project outside of your knowledge. It is suggested to work on projects where the possibility of failure to complete them is high. In a private setting, I would gladly challenge myself by deep-diving into a project that I do not feel confident I can complete. In a professional setting, I personally am a bit too risk-averse to immediately want to take on a task where the chance of failure is greater than my chance of success. However, I appreciate that it is a gamble where if I do succeed it will boost my portfolio and whether I succeed or fail I will walk away with more knowledge than I started with. I believe it is human nature to be frightened of failure. This pattern is a great reminder that the journey that led to failure was along the way a great learning experience and the following attempt will be a success based on what you had learned.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

The apprenticeship pattern Expose Your Ignorance is about the importance of feeling comfortable with showing your ignorance. Asking questions is how you learn and shows that you are good at understanding. The difference between an expert and a craftsman is someone who broadens their range of knowledge rather than only sticking to digging deeper into a single domain. The action the author recommends is to write down your

The quote included in this pattern from David H. Hoover was thought-provoking. “I actually had grown attached to feeling ignorant on a daily basis; it let me know I was in the right place. I was growing.” The quote reminded me of the Daoist view of yin-yang where on one side there is chaos and on the other side, there is order. To grow as an individual, you need to be in the middle of the two. As Hoover’s quote says, feeling ignorant means that you’re exposing yourself to new material and are learning. If you never feel challenged, then you are not doing anything new and therefore not gaining new experiences. If you are uncomfortable with feeling the unknown, then it means you are uncomfortable exposing yourself to new things.

This pattern made me realize it is not only okay to be in the presence of the unknown but that it is also necessary for personal development. Personally, I do not act as if I know everything or that my solution is always the best option. I make what I know heard but leave plenty of room for others’ opinions. There are times when what I recommended is ignored and then later those recommendations are then incorporated into the project. It is better for that to happen naturally than for me to force my ideas into the project without the full acceptance of the other people involved. I do not disagree with anything in this pattern, I agree with the author fully on his opinion.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

The outcome of the sprint was excellent. We wanted to get a working frontend and a working backend, and we had to familiarize ourselves with the code from last semester. The state of the project did not have a fully functioning frontend, and the backend was not working at all. The goal of this sprint was to clean up the existing code and make the current features work as they should. The nature of this sprint was to set up the GuestInfoSystem front end and back end, and we did well on that. We added several features, but a majority of it was refactoring existing code.

One of the workflows we struggled with was managing branches while we programmed. Because there were three people on the front end and three people on the backend, multiple people worked on the same area of code. The workflow that emerged, especially on the backend, was creating many branches from other branches. The effect of this was that we had a diverging codebase that was difficult to merge and maintain coherence. For example, a branch created from the main branch was to add JSDoc. Then we needed to update an API path, and a branch was created from JSDoc. An individual continued to work on the JSDoc branch while someone else worked on a new branch from this one. Creating a new branches from an existing branchx continued a few times, and updates to the code were scattered. New code was mixed with old code in each different branch.

To not have this issue reoccur, we will be changing our workflow for managing branches. What we will do for the next sprint is make a single branch for each issue and merge it into the main branch following it has been reviewed. If a significant feature needs adding, we will create a branch for this, and multiple people can work on it at once. If there are multiple active branches, we will ensure that one branch does not modify the area of code in another branch. By working on small features and performing common merging, we will make sure code is not lost and each member is working on the most up-to-date code at all times. It was difficult to do this during our initial sprint due to the amount of code that needed to be rewritten to get the backend working. In the next sprint, we will follow this improved workflow.

A change that I will make in the next sprint is to improve the issue creation process. The issues that I made for this sprint were overly broad, and the weight did not fully capture the issue’s headline. For example, ‘Add JSDoc’ has a weight of three, but it sounds like something that could be done in one class period. This issue actually required defining the type for each variable used in the backend, defining function input and output types, and creating object types for each object in the backend. This process involves studying the code, assessing the proper type for each instance, typing each file, and ensuring the types selected do not throw errors between files. What I could have done to improve my issues by creating smaller issues for each of these steps. Each one of these issues could have been done in the same JSDoc branch, but each small issue clearly defines what is being worked on. Following the closure of JSDoc related issues, the branch could be merged into main.

Issues Completed During Sprint 1

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.