Category Archives: CS@Worcester Blog

Sprint 3 Retrospective

For the last sprint, the main objective, from a frontend perspective, was adding some final touches to the code and making documentation for next years group. My biggest objective however for this sprint was to get semantic versioning to work. Semantic versioning, in simple terms, allows us to make version tags for any ne code that is pushed to the main repository. For example, if I pushed something new to the main branch that is a new feature, it will tag this as let’s say “v2-0-1” and it will make a container as well with this tag. This is helpful to us because if we ever need to go back to an old version of the code, it will be easy using the tag container in our docker-compose file. This for a few days was giving me issues until I found what the cause was. The main issue was our docker compose version. Throughout the sprints we have been using version 3.8 but for semantic versioning to work I need to add a docker compose apk to the ci and change the version to 3.3. This allowed the versioning to work and tag.

For this sprint I though everyone worked well together and got a lot done on both the frontend and the backend. Like the other sprint we did a divide and conquer style of completing the issues the were left for us to finish in this sprint. Everyone had a final hard task to do in both the frontend and the backend which gave us more hands-on knowledge that we all can take to our future workplaces.  The only thing that I think didn’t work well for this sprint was people doing task but not assigning themselves the issues. We had an issue where two people were working on the same issue which caused confusion between the two. A compromise was eventually found, and the issue was complete but in the future people should not be doing this as it could lead to a bug or error In the code from different algorithm styles.    

As a team, besides what I talked about above, I found that there is not much we can improve on as a team. I found that this sprint went very well and am proud of the work the was complete during this time. Also, this being our last sprint we will not meet again to be able to improve together. As an individual like last sprints, I had some issues with commits again. For semantic version I had roughly 30 commits trying to test the pipeline and find the errors. I could not find a way to test the ci locally, so I swamped the commit log with tests. In the future I need to either find a way to test ci locally to make changes before clogging the system or I need to e better about error tracing so there is only like 5 commits compared to 30.


Update guest data to new datapoints:

Updated port numbers in code:

Updated README:

Semantic versioning: and many more commits in repo for testing

Fix v-show bug:

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Retrospective #2

Coming to the second sprint with a lot of achievement from the first one, I put in an objective of having both the back and front of the project working steadily. To be specific, my goal for the backend was to have the testing and the message broker work with the current code that every time they pull up a test, a data entry will be automatically created if there is no previous stored data, and the message broker to send notification once users modify a data entry. For the frontend, the goal was to make the returning form for returning users and integrate with the backend under container technology.

What have we achieved?

Repeat from last retrospective, my team has good developers who are able to complete all the issues listed in a short period of time, so we almost have every issue in review state after a week and a half. I created the testing directory to test each endpoint with the default case and it will create a temporary student data whose id is 1234567 if there was no data initially. The message broker was implemented properly to send a message into the queue every time the update endpoint is called. Our frontend has its application run on the nginx server by binding from docker-compose and partially integrate with the backend application also thanks to Docker.

Things to improve

The major problem with the backend application currently is its execution since it requires two terminals to execute asynchronously, the first one is to pull up the MongoDB database and the RabbitMQ server, then the second command will be used to run the node application, without Docker. However, the testing was created specifically for Docker to execute because the Mocha Chai framework requires all of its functions to be programmed inside the `test` directory and this directory is actually “invisible” in the terminal environment, so its .json and docker files have to be written in another directory when I wanted to put it on Docker (node execution does not require this step). Therefore, executing the backend container with nodes prevented the application from having testing features.

Besides, the registered image that the frontend has been using also needs to change to an older branch because the current pipeline builds an incomplete image due to the new code from RabbitMQ. Fixing this problem will be an epic coming to the next sprint, the point is to have Docker to bring up the application as a whole where the cycle of execution will be MongoDB and RabbitMQ -> Backend Server -> Testing in one docker execution which will make it easier to manage and to build the pipeline.


As a Scrum Master, I did not fully complete my responsibility this sprint since I could not make the team communication to be better, I was too concentrating on the backend repository that I just only had some brief conversation with the frontend team, which is not enough to keep me update to support what they need. In the next sprint, my goal is not clear yet but I would want to try to have more talking with the frontend guys.

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

Retrospective #3

Final sprint before I lose my maintainer status to the repository, this sprint objective is to clean up our workspace, fix some minor issues which have been around since last sprints, and left the next semester a decent documentation so they will not be confused like us at their first step with this repository.

To begin with this sprint, I started with an issue that I was not able to solve from last sprint, which is registering the backend application with GitLab CI. This issue was a bit painful because after we plugged in RabbitMQ, we had to modify the execution cycle. To be specific, the RabbitMQ server must be up for some seconds before the backend application and I thought that I should figure out a way to use the pipeline to build that RabbitMQ container before the backend.

I actually found out the solution for both the pipeline and the integration when we had a conversation with the Kubernetes team where they told us to have each image in a distinctive container. After that, I attempted a different approach, instead of trying to inject the RabbitMQ to the backend during pipeline, I would only build a standalone server and release it, then, the RabbitMQ container will be defined once again in frontend testing and integration consisting of necessary environment variables which will trigger the backend server properly once it is executed.

However, the server’s execution consistency is still roughed as sometimes RabbitMQ is not detected. Besides, it happens on some computers while others don’t. Specifically, it only runs on a strong computer. Therefore, we changed the assumed time to have RabbitMQ start with an environment variable so we are free to modify the runtime based on hardware.

Last but not least, I created two environments for the backend repository, one for development, one for production. The small difference but undoubtedly critical is the binding and `nodemon` execution. Binding the container to local is not visible without `nodemon` since it will restart the server for every change we made. However, the default `nodemon index.js` is not working properly on Windows operating system after bind while MacOS works like a charm. I Looked around for several days without rushing and I just found out that `nodemon -L index.js` will make it work regardless of the operating system, where `-L` is the legacy flag.

To conclude, I am proud of my team overall because at our in-person retrospective meeting of this sprint, by showing our work, the Professor said that it is almost ready to be released. Back when we began in January, we had a not working server and a vanilla JavaScript frontend, the objective initially was to fix the server and somehow pull the Vue-CLI up as soon as possible; now we have a functional page where guests can register with their information and submit to the database. I learned a lot from this experience, both technical and soft skills, and I am feeling grateful for being given a chance to work in this meaningful project.

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

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.

The Long Road Pattern

For this week’s apprenticeship pattern, I did a reading on “The Long Road”. The Long Road pattern is about your future. In this pattern it talks about trying to imagine yourself 10 years, 20 years, or even 40 years from now. They want you to think about that and possibly write down a summary of your profession. By doing this, it will enable you to think how you would want your professional path to be like and allows you to plan how things could go. The problem in this pattern is that you want to become an expert in what you want to do however, things may get in the way like that such as promotions and just always picking the highest paying job and by doing this, it takes away the goal you had originally which is to do something that you enjoy doing but instead doing jobs that in reality sucks.

My initial reaction to this, is that it is an interesting pattern to read about. It is interesting because I never thought to look past 5 years into the future and just thinking about the future and where I want to be in general. Obviously, everyone wants to make six figures, but the main goal is to make that much by doing something you love or enjoy doing. After reading this pattern I did take a moment to think about where I would like to be down the road and it made me realize what I really wanted to do with my future. Of course things happen, and the future isn’t exactly set, but it gives me a good idea of what I need to do and what I have to do to accomplish it.

The pattern has changed the way I view my profession because I never thought about needing to take a step back and think about the distance future of where I would like to be. Do I still want to be programming all my life or would I like to do something different by the age of 40? It was an eye opener to me because it really allowed me to set goals that I want to achieve by a certain age. Sure, programming is fun and all but there’s much more to life than sitting around a desk and creating programs and such. I want to create memories that will last a lifetime and explore the world.  If I can find a career that would enable me to do that then that would be the ideal job.

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.

The Long Road

For this week’s additional blog post, I have decided to look at the apprenticeship pattern “The Long Road”. In this chapter you, are aspiring to become a master software developer. However, your aspiration conflicts with what people expect from you. Conventional wisdom tells you to take the highest-paying job and the first promotion you can get your hands on, to stop programming and get onto more important work rather than slowly building up your skills. In this chapter it is advised that you should focus on the long-term. Value learning and long-term growth opportunities over salary and traditional notions of leadership. No one is so far ahead that you can’t match their skill level given the decades you will have to hone your craft. No business or technical domain is closed to you. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“This pattern is not for people aspiring to become CIOs or project managers, or filthy rich. Along the way, it is not unlikely that you will take on roles of power and responsibility or find yourself quite wealthy. However, these roles and benefits are not the main motivation of the successful apprentice—they are merely by-products of a lifelong journey. And rather than counting the days to retirement, the craftsman will willingly and joyfully work into her final decades. We don’t want to give the impression that everyone must follow a single road (see Draw Your Own Map) or that this is the right road for every software developer (see A Different Road). Some people leave development permanently and become executives, testers, salespeople, or project managers”. (Dave H. Hoover & Adewale Oshineye).

This chapter was an interesting one to read. I liked how it talked about how this is a unique profession, and you will be doing it for some time if the passion is there. I also liked how it talked about how you shouldn’t jump ship right away if there is an opportunity away from software development. I don’t think that this chapter will stick with me out in the real world, however. I feel as though this chapter is geared towards people with a mind set of already leaving this profession.

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Retreat Into Competence

For this week’s blog post, I have decided to look at the apprenticeship pattern “retreat into competence”. The idea of this chapter is that you, a software developer, are beginning to realize how little you know, or that you have taken on a new challenge that is not working well in your favor, or your having problems with both. Due to you realizing how little you know you begin to get overwhelmed with your ignorance. The solution to this is to pull back and launch yourself like a stone from a catapult. You need to retreat or take some time away from your task to re collect yourself so you can come back to the task stronger than before. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“An apprenticeship is a roller-coaster ride. You will experience the thrill of learning new technologies, leveraging your knowledge and creativity to deliver value to your customers. But you will also experience the heart-in-your-throat terror of perceiving just how little you know compared to the craftsmen and experts you meet along the way. It can be overwhelming, particularly when a deadline is looming or when you’re dealing with production issues.” (Dave H. Hoover & Adewle Oshineye).

This pattern is most relevant to people who have stretched themselves to far thin to be able to concentrate on the task in front of them anymore. However, by pulling back you do have the chance to launch more forward than you have been able to before. Note however this pattern does come with risks as if you forget to launch back forward or don’t have the desire to there can be repercussions. I liked this chapter as I am a person who can get stretched thin very quickly and am not able to bring myself to walk away for a bit to recollect myself. I liked that this chapter talked about both the pros and the cons of using the pattern. This will be something that will stick with me while I’m in the field because I am prone to being stretched thin and will sit there and still try to figure out the problem for hours. By walking away for a bit, I will be able to launch forward.   

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Third Sprint Retrospective

Reflection on what worked well and didn’t work well

After meeting for the Sprint Retrospective with my team as a whole, I can say that the project is progressing well. The flow of group work has improved more since everyone works together much more effectively. The front-end and back-end development teams have made significant progress towards the project. The backend is pretty much complete at this point and the frontend is pretty much there besides a few minor things. We don’t have any major programming problems coming off of our last sprint, just a few potential bug fixes and cleaning up to do. Finally, after looking back at what we did, we made it easier to run the servers, since in the last spring we had to run things one at a time, however now it will run all at once, making it more efficient. During this spring we also cleaned up a lot of the coding and did some minor bug fixes. The backend is pretty much completed now besides testing. We just didn’t have enough time for it, it would have been something we would have done if we had another sprint left in the semester.

Reflection on what changes could be made to improve as a team

The team worked great. We still have everyone on their original development team. The ones at the back end remain at the back end and those who worked on the frontend stayed on the frontend team. Both teams for this spring, started to run out of things to do since everything was either completed or almost completed at this point, or there wouldn’t be enough time to work on a new issue. From the way the meeting went, everyone was able to communicate all the problems they had with each other, and no one was afraid to ask if they needed help. For our last sprint, I would say that there was such an improvement comparing to the beginning of the semester. Everyone was comfortable with talking out loud, helping one another, and overall, just great teamwork.

Reflection on what changes could be made to improve as an individual

From my point of view, the sprint was very good. Since we were running out of things to work on the backend, there wasn’t much to do. I worked on changing the port numbers for the backend to be between 10350 to 10399. Help change the datatype for household members. As well as combining docker-compose for the backend. I worked with colleagues Jared and Vien on these issues and other issues that we had on the backend since there wasn’t much left to do for the backend. Same as the Sprint, we were able to continue to learn more from each other. In this final sprint, I would like to say that overall, I became a better programmer/ developer, and this was a great experience to be able to work on large project in a scrum environment. I was able to become more confident in my skills and also became better with communicating with team members.

Combine docker-compose Backend

Update Household Members Datatype

Update Backend Ports

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.

Share What You Learn

To avoid frustration, I try to keep myself motivated by thinking about the feeling when I complete my task. Along with the feeling of completion, sharing information among people is some sort of motivation that I want to show off every time I learn something useful.

In my view, I am not a beginner applying this method introduced in Dave Hoover’s book since I am not feeling strange when I explain to my mates what I have learnt, instead, I actually like doing it because it is not only a way to help my mates understand the part that I have been working on but also a great opportunity to test my understanding over subject and enhance my memorization onto it.

I started feeling the benefits of sharing information with other people since high school. Back then, I mostly helped my friends when they didn’t understand some math problems in class, and every time I do it, I remember that issue much longer, and I feel more comfortable with the technique used to solve that problem. The more I “teach” them, the better my “teaching” skill and my sense of learning improves as well. As they started counting on me in these difficult tasks, I would perceive the sense of motivation to push my learning into the higher level.

We are afraid of having a conversation about a topic that we do not really comprehend. In both math and code, exchanging information, in my opinion, is an infamous problem since I have encountered lots of people who suffer from it. Coding and mathematics have a similar concept (it is like a feeling, but I cannot think of a more specific word to describe it) that once you understand the flow, solving their problems is utterly attractive. Therefore, besides the benefit of improving my apprehension, I also want to help my friends be able to comfortably debate when it comes to specialized topics.

As we grow, we have less confidence to ask other people, searching for problems online is therefore becoming a more popular approach. Hence, publishing blog posts to share my learning will be my next path to maintain my motivation and improve my understanding. Stay tuned!!

From the blog CS@Worcester – Vien's Blog by Vien Hua 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.