Category Archives: CS@Worcester Blog

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

Hello blog, how are you guys doing (I feel fine)? I got a book from my professors in the Syllabus. I read it; it is good.

Even I can recommend some of my friends who are not computer science majors to these books for knowledge to develop some

level of studying and more.

What did you find interesting, helpful, and thought-provoking about the reading?

I found it interesting and valuable that the first two chapters, 1 & 2, stated that it is crucial to have a “growth mindset” and

realize that learning demands perseverance, trial, and error. It was even needing to find mentors to assist in directing the learning

process while working on a personal or side project to put newly acquired information to use.

Also, near the end of the introduction, the second chapter points out the final four patterns that encourage continuous learning:

Exposing and confronting ignorance.
Taking on an audacious task.
Retreating into competence.
Ascending to the next level.

Has the reading caused you to change your opinion, the way you think about the topic, or how you work?

The task does change my perspective toward the CS or related-working strategically differently from not knowing wanting to do for

experience while approaching learning with an open mind Chapter 2. Then chapter 3, moving in to help, provide information for

getting experience by doing side projects and reading materials.

Even the same or new technique helps with collaboration and exceptional software developers for new learning experience journeys.

Do you disagree with something in the reading? And why? * Which chapters seem most relevant to you?

I have a minor disagreement with one of the chapters, chapter 4. The introduction of chapter 4 mentions,

“Avoid mediocrity and self-satisfaction.” I like it when you deserve some self-satisfaction from how long you work to accomplish

something, but I understand that there is more to learn in to-do and achieve even more than current works/projects.

Also, the chapters that I like with the introduction are 4 for “Goal is to be better than yesterday, not just better than average.” &

5 for “Self-discovery patterns such as Reflect as You Work, Recording and Sharing, Create Feedback Loops,

and Learn How You Fail are also important.”

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

Hello blog, how are you guys doing (I feel fine)? I got a book from my professors in the Syllabus. I read it; it is good.

Even I can recommend some of my friends who are not computer science majors to these books for knowledge to develop some

level of studying and more.

What did you find interesting, helpful, and thought-provoking about the reading?

I found it interesting and valuable that the first two chapters, 1 & 2, stated that it is crucial to have a “growth mindset” and

realize that learning demands perseverance, trial, and error. It was even needing to find mentors to assist in directing the learning

process while working on a personal or side project to put newly acquired information to use.

Also, near the end of the introduction, the second chapter points out the final four patterns that encourage continuous learning:

Exposing and confronting ignorance.
Taking on an audacious task.
Retreating into competence.
Ascending to the next level.

Has the reading caused you to change your opinion, the way you think about the topic, or how you work?

The task does change my perspective toward the CS or related-working strategically differently from not knowing wanting to do for

experience while approaching learning with an open mind Chapter 2. Then chapter 3, moving in to help, provide information for

getting experience by doing side projects and reading materials.

Even the same or new technique helps with collaboration and exceptional software developers for new learning experience journeys.

Do you disagree with something in the reading? And why? * Which chapters seem most relevant to you?

I have a minor disagreement with one of the chapters, chapter 4. The introduction of chapter 4 mentions,

“Avoid mediocrity and self-satisfaction.” I like it when you deserve some self-satisfaction from how long you work to accomplish

something, but I understand that there is more to learn in to-do and achieve even more than current works/projects.

Also, the chapters that I like with the introduction are 4 for “Goal is to be better than yesterday, not just better than average.” &

5 for “Self-discovery patterns such as Reflect as You Work, Recording and Sharing, Create Feedback Loops,

and Learn How You Fail are also important.”

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

Hello blog, how are you guys doing (I feel fine)? I got a book from my professors in the Syllabus. I read it; it is good.

Even I can recommend some of my friends who are not computer science majors to these books for knowledge to develop some

level of studying and more.

What did you find interesting, helpful, and thought-provoking about the reading?

I found it interesting and valuable that the first two chapters, 1 & 2, stated that it is crucial to have a “growth mindset” and

realize that learning demands perseverance, trial, and error. It was even needing to find mentors to assist in directing the learning

process while working on a personal or side project to put newly acquired information to use.

Also, near the end of the introduction, the second chapter points out the final four patterns that encourage continuous learning:

Exposing and confronting ignorance.
Taking on an audacious task.
Retreating into competence.
Ascending to the next level.

Has the reading caused you to change your opinion, the way you think about the topic, or how you work?

The task does change my perspective toward the CS or related-working strategically differently from not knowing wanting to do for

experience while approaching learning with an open mind Chapter 2. Then chapter 3, moving in to help, provide information for

getting experience by doing side projects and reading materials.

Even the same or new technique helps with collaboration and exceptional software developers for new learning experience journeys.

Do you disagree with something in the reading? And why? * Which chapters seem most relevant to you?

I have a minor disagreement with one of the chapters, chapter 4. The introduction of chapter 4 mentions,

“Avoid mediocrity and self-satisfaction.” I like it when you deserve some self-satisfaction from how long you work to accomplish

something, but I understand that there is more to learn in to-do and achieve even more than current works/projects.

Also, the chapters that I like with the introduction are 4 for “Goal is to be better than yesterday, not just better than average.” &

5 for “Self-discovery patterns such as Reflect as You Work, Recording and Sharing, Create Feedback Loops,

and Learn How You Fail are also important.”

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

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.

Commits:

Update guest data to new datapoints: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/5de3e0c143b3cabb9a517839257be9a3adec33d4

Updated port numbers in code: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/94d4e5e98e17f1f37e3ec87dc5f307b69d1cc762

Updated README: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/8edbb8c6b24592bea5da04418032c49f03469638

Semantic versioning: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/82ce990f6d689810a6bab6ad7e31f89ab8614a28 and many more commits in repo for testing

Fix v-show bug: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/b3cdca325396169af224897768dd80d1d069e2b8

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.

Conclusion

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.