Category Archives: CS-448

The Deep End

Hello and welcome back to another week of my blog. This week, I looked through chapter 2 of the book Apprenticeship Patterns by Dave Hoover named “Emptying The Cup” and took interest in the apprenticeship pattern called “The Deep End.” This pattern is about pushing yourself out of your comfort zone and taking on challenging tasks that are outside of your current skill set. The best way to learn is by doing, and that taking on tasks that are beyond your current abilities can help you grow and develop new skills. The pattern advises that when you are in the “deep end,” it’s important to ask questions and seek help from more experienced colleagues. It’s also important to break down your tasks into smaller, more manageable pieces and to focus on making small incremental progress over time. The benefits of taking on tasks in the “deep end” include accelerated learning, increased confidence, and the opportunity to demonstrate your abilities and potential to your colleagues and mentors.

As a computer science apprentice, it can be scary to go into the “deep end” since you may think you would be a totally lost person working with experienced people. But I have experienced the deep end myself many times in my everyday hobby, video games. This seems to happen the most especially in competitive video games, when you play with people who are more skilled than you, you start to pick up on the many small helpful habits highly skilled players tend to do. The skilled players don’t need to think about the small habits because they have already mastered them and do them out of muscle memory. The same can be said for computer science apprentices. For a scenario, think about working on a difficult project with more experienced people in the field. You may look like a small fry with not that much experience compared to the others, but this is actually a fantastic opportunity to observe your team members and pay attention to small things and habits like their thought process for example. As you focus on the small habits, you also start to copy those habits and incorporate them into your work as well. This would also be a great opportunity to ask questions if you are confused about anything. I will for sure start diving into the deep end if I find any opportunities to since it will strengthen my skills as a computer science major.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

The Deep End

Hello and welcome back to another week of my blog. This week, I looked through chapter 2 of the book Apprenticeship Patterns by Dave Hoover named “Emptying The Cup” and took interest in the apprenticeship pattern called “The Deep End.” This pattern is about pushing yourself out of your comfort zone and taking on challenging tasks that are outside of your current skill set. The best way to learn is by doing, and that taking on tasks that are beyond your current abilities can help you grow and develop new skills. The pattern advises that when you are in the “deep end,” it’s important to ask questions and seek help from more experienced colleagues. It’s also important to break down your tasks into smaller, more manageable pieces and to focus on making small incremental progress over time. The benefits of taking on tasks in the “deep end” include accelerated learning, increased confidence, and the opportunity to demonstrate your abilities and potential to your colleagues and mentors.

As a computer science apprentice, it can be scary to go into the “deep end” since you may think you would be a totally lost person working with experienced people. But I have experienced the deep end myself many times in my everyday hobby, video games. This seems to happen the most especially in competitive video games, when you play with people who are more skilled than you, you start to pick up on the many small helpful habits highly skilled players tend to do. The skilled players don’t need to think about the small habits because they have already mastered them and do them out of muscle memory. The same can be said for computer science apprentices. For a scenario, think about working on a difficult project with more experienced people in the field. You may look like a small fry with not that much experience compared to the others, but this is actually a fantastic opportunity to observe your team members and pay attention to small things and habits like their thought process for example. As you focus on the small habits, you also start to copy those habits and incorporate them into your work as well. This would also be a great opportunity to ask questions if you are confused about anything. I will for sure start diving into the deep end if I find any opportunities to since it will strengthen my skills as a computer science major.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

The Deep End

Hello and welcome back to another week of my blog. This week, I looked through chapter 2 of the book Apprenticeship Patterns by Dave Hoover named “Emptying The Cup” and took interest in the apprenticeship pattern called “The Deep End.” This pattern is about pushing yourself out of your comfort zone and taking on challenging tasks that are outside of your current skill set. The best way to learn is by doing, and that taking on tasks that are beyond your current abilities can help you grow and develop new skills. The pattern advises that when you are in the “deep end,” it’s important to ask questions and seek help from more experienced colleagues. It’s also important to break down your tasks into smaller, more manageable pieces and to focus on making small incremental progress over time. The benefits of taking on tasks in the “deep end” include accelerated learning, increased confidence, and the opportunity to demonstrate your abilities and potential to your colleagues and mentors.

As a computer science apprentice, it can be scary to go into the “deep end” since you may think you would be a totally lost person working with experienced people. But I have experienced the deep end myself many times in my everyday hobby, video games. This seems to happen the most especially in competitive video games, when you play with people who are more skilled than you, you start to pick up on the many small helpful habits highly skilled players tend to do. The skilled players don’t need to think about the small habits because they have already mastered them and do them out of muscle memory. The same can be said for computer science apprentices. For a scenario, think about working on a difficult project with more experienced people in the field. You may look like a small fry with not that much experience compared to the others, but this is actually a fantastic opportunity to observe your team members and pay attention to small things and habits like their thought process for example. As you focus on the small habits, you also start to copy those habits and incorporate them into your work as well. This would also be a great opportunity to ask questions if you are confused about anything. I will for sure start diving into the deep end if I find any opportunities to since it will strengthen my skills as a computer science major.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

The Deep End

Hello and welcome back to another week of my blog. This week, I looked through chapter 2 of the book Apprenticeship Patterns by Dave Hoover named “Emptying The Cup” and took interest in the apprenticeship pattern called “The Deep End.” This pattern is about pushing yourself out of your comfort zone and taking on challenging tasks that are outside of your current skill set. The best way to learn is by doing, and that taking on tasks that are beyond your current abilities can help you grow and develop new skills. The pattern advises that when you are in the “deep end,” it’s important to ask questions and seek help from more experienced colleagues. It’s also important to break down your tasks into smaller, more manageable pieces and to focus on making small incremental progress over time. The benefits of taking on tasks in the “deep end” include accelerated learning, increased confidence, and the opportunity to demonstrate your abilities and potential to your colleagues and mentors.

As a computer science apprentice, it can be scary to go into the “deep end” since you may think you would be a totally lost person working with experienced people. But I have experienced the deep end myself many times in my everyday hobby, video games. This seems to happen the most especially in competitive video games, when you play with people who are more skilled than you, you start to pick up on the many small helpful habits highly skilled players tend to do. The skilled players don’t need to think about the small habits because they have already mastered them and do them out of muscle memory. The same can be said for computer science apprentices. For a scenario, think about working on a difficult project with more experienced people in the field. You may look like a small fry with not that much experience compared to the others, but this is actually a fantastic opportunity to observe your team members and pay attention to small things and habits like their thought process for example. As you focus on the small habits, you also start to copy those habits and incorporate them into your work as well. This would also be a great opportunity to ask questions if you are confused about anything. I will for sure start diving into the deep end if I find any opportunities to since it will strengthen my skills as a computer science major.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Confronting Your Ignorance

This apprenticeship method is closely related to Expose Your Ignorance, but instead of just simply identifying what you don’t know, you learn those topics. Reading this method expanded my thinking about how to go about learning within a team environment. The article describes that there is a detrimental difference between incorporating your learning in a positive way and a negative way. The negative way can appear in a few different ways, mainly an individual doing all of their learning in private, not sharing their experience with other individuals who also are learning the craft, and the risk of creating niche products and tools that only you are able to use and understand. This could lead to frustration and other issues within your team, and drive the team towards a “fend for yourself” mentality. It can also lead to individuals stagnating in their learning, causing them to not really care when a problem occurs within the code that is someone else’s issue, since they did all their learning in private.

Exposing your ignorance can also appear in positive ways as well, which is the ideal goal. After identifying what areas of knowledge that you didn’t know, one positive method would be to seek out other individuals that also want to learn, and learn together. Applying this to my life, I am luckily in that situation with my team on the Libre Food Pantry project. We all are working on the same issues together, so we are also learning together when we solve the issue. We are all learning chai together and how the docker containers interact with the rest of the project. And when one individual is working on an issue by themselves, they explain how they got to where they are in the code and let everyone see the inner workings of the code. By doing this, the team will all be caught up on how to work on a particular issue, and there won’t be any frustration when a team member is not available for the day.

When I begin my new job, I will already have taken in my list of topics that I want to learn about. The next step would be to seek out other individuals who are also wanting to learn the same topics that I do, and discover them together. Working on “breakable toys” as a team will give everyone the opportunity to use them without hassle. Also seeking out mentors and senior leaders who have experience in whatever topic we are striving to learn will help, as they can show us what they have learned, what mistakes to avoid, and how to effectively apply the knowledge to a team environment. It is important to always keep your team in the loop whenever you are learning a new topic, and to keep learning and seeking out new things to learn.

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

Expose Your Ignorance

This blog posts discusses the issue of individuals at their work place dealing with the expectation that they are an expert in their area of work. In regards to software, this is a difficult issue to tackle, as new innovations and technologies are pushed towards software developers rapidly. It can be hard to catch up to all of the new ways of doing tasks and creating code, new IDEs that the company is enforcing software engineers to use.

Personally, I relate to this topic. Growing up, I was always the “tech guy” in my family, helping my parents and everyone else at family events. This gave me a false sense of confidence when I started college, and I realized how little I knew in the world of software. With this little knowledge though, I still felt I had to maintain my sense of “expertise” when I was with my friends and family. When I was in class however, I was in awe of how much the knowledge of software I did not know. This idea can also apply to the workplace. I would assume that when I do start my new job, I will be with other recently graduated software engineers, and everyone will want to make their mark. Who would want to work with the new grad who didn’t know how to work in a certain language? This way of thinking is created by the idea that in the corporate world, its everyone for themselves.

When I start my new job, I will try to keep the mentality that I can always learn more when I am working on a project. The reading describes a method of writing five things that you don’t know, and keeping them in the open at your workstation so other coworkers can see it, and to always refresh the list. Working on the Libre Food Pantry project, I already have most of my list assembled for that project. The list includes: chai syntax, inner workings of docker containers, and the CI pipeline. This list will obviously change when I transition to a new work environment and new projects, but the idea will stay the same. Keep refreshing the list of new things that you want to know more of, and keep it out in the open and “expose” your ignorance. Its ok to not know everything in a certain field, that what experience does. It helps you develop your skills and become a better developer.

Another solution is to just simply ask questions. The more direct the question, the quicker you’ll find yourself becoming the person that answers those questions. As stated before, it’s difficult to ask questions, especially when you are brand new in a project. You are expected to be able to handle yourself and not rely on anyone else, and if you do rely on anyone else you are just a hinderance to the project.

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

Sprint 2 Retrospective

One issue our team was having during this sprint was that getting or deleting a guest, after creating the guest, was returning a 404 not found response. We were having a difficult time identifying the cause of this reversion of good behavior, so I learned how to use the git bisect subcommand to find the commit, found the change within the commit that caused the bug, and reverted that change. It ended up being that we could not refer specifically to the /guests endpoint token within the OpenAPI server URL value without other changes.

Evidence: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/89

Continued existence in frontend (we just need to make sure the right API YAML file is being used in all the repos now): https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/57

Chai has very nice syntax, which together with chai-http lets you call should on an object, such as object.should.have.status(200), or to call chai.expect(object) when the object might or might not exist. I wrote some simple unit tests, such as verifying that the version string has a range in [5,8] — ('0.0.0' - '99.99.99') — for getting the API version. As with other tests, being able to call them quickly with cd src && npm run test while the server is running on localhost is a useful holdover until we get the CI pipeline working.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/70/diffs?commit_id=69a9d2299335066166b6379bbdb83bd4d5594bde

I did some pre-sprint-3 cleanup by removing the Chai (not Chai-HTTP) example testGuest.js file.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/90

I cleaned up our set of unit tests, for the create guest endpoint, which I think is now the first to be in a really good state concerning test coverage not including the get API endpoint. This includes a cleanup step at the end (so tests can be run repeatedly without rebuilding the server), several HTTP requests: both valid and invalid, examining many of the properties of the returned responses. One trick I learned was to assign a const object to store guest data and then repeatedly copy it with the spread ... operator. Otherwise JavaScript would copy by reference and disrespect the const-ness of the object: it would otherwise mutate a const! What a lovely language feature.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/72/diffs?commit_id=9e3ee6ee2b4202c5971445ead7fc8a10fc727992

Overall, I think I did decently. I helped Kelvin a little with some of his issues. He individually, and our team as a whole, did a great job this sprint. We began and completed work on multiple epics. We ended in a state where now, 1 week from the end of sprint 3, we think we can finish up everything that we wanted and agreed to get to in our sprint 3 planning meeting.

One challenge I faced that I couldn’t resolve was an unfortunate technical difficulty. Despite multiple restarts, re-cloning the repos, and checking my installed program versions, my computer stopped being able to run the server. I eventually gave up after a few hours of trial and error, and moved to a different computer, but I suspect the problem was in an incompatibility involving the rolling-release software update model used by Arch Linux. I’ve now had 2 confirmed and 2 other suspected significant issues that might have been avoided by using LTS software.

Our team could probably improve our communication. It’s hard to find time after Thursday and before Tuesday to plan or collaborate on changes. Early this semester I supported working asynchronously, but in retrospect having an hour or two per week of planned collaboration probably would have led to more productivity and confidence without an unreasonable cost.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

Retrospective Blog #2

Our team hit the ground running in the second sprint to deliver a much better result than the first sprint in the end. I ended up working on three issues, with two being completed in the end, and the last one being saved for the next sprint. The links to all three issues can be found below. The first issue was an issue that had been unresolved in the last sprint. What happened was that I had finished the issue, but there was a problem with the commit. I received help from Scott on fixing the commit problem, and the issue was resolved. The second issue was another one that came from the first sprint. I had many troubles with updating the pipeline in the first sprint, and I really needed help with it in the second one. Sam jumped in and did an amazing job getting it to work, and we could not have completed it without him. The third issue I had started in this sprint was creating the test.sh file in the command folder. It took a lot of trial and error, but I just was not able to finish it completely, and I am looking forward to finishing it up in the next sprint. This blog will go over my retrospective thoughts now that the second sprint is over.

Many things worked really well throughout this sprint. One thing that was huge was how much we had learned from the first sprint. In the first sprint we started off slow as we were still inexperienced, but this time we just flew through the beginning, and hit a roll. This can be seen in the nearly 10 point weight difference at the end of each sprint. Another thing that worked well was how cohesive we worked as a group. Now that we had more experience working together, I felt that we talked with each other more, and worked together to finish issues more as well.

There were also some things that did not work well throughout the sprint. One thing that comes to mind is how even though we are better, our weight scaling is still a little off. An example of this is with the pipeline issue where we put it as a weight of two, and it ended up being a weight of five or six. Something else that comes to mind that did not work well is our understanding of new information. It has taken us way longer than we thought to understand Chai, and we are still entering the final sprint trying to fully figure it out.

When thinking about what we can do to improve our group, a couple of ideas come to mind. One thing is that we can try to fix our issue with weights. We could try to improve this by giving some issues more weight than we think it needs so that we can account for actually learning what to do. A lot of times we have overestimated our knowledge, and it led to us taking longer on sprints than the listed weight. Another thing we can try to improve is our communication with outside groups. I feel like we think that we can only communicate with each other, but we can also reach out to our friends in other groups for help as well, and I think we have not taken advantage of that as much as we should.

I think that I can improve in many ways from this sprint. One way is by getting more familiar with Git itself, and prevent small mistakes, like with the first linked issue, from happening again. This will allow for us to not waste time on issues that do not require it, and get our work done faster. Another way I can improve is by reaching out to the GuestInfoSystem team for help with creating the test.sh file as they have done a ton of work with that in sprint two, and have got it up and running on their system. This will help us in getting that issue resolved for the last sprint. This sprint felt like night and day compared to the last one, and our group will only improve more with this experience.

Issue Links

  1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/issues/8
  2. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/98
  3. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/48

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

Sprint Retrospective 2

For this sprint we decided to split up the work a little differently, as a group we agreed that we should switch what projects we were working on to get a better holistic understanding of the inventory system. This somehow led me to wanting to work on creating the entire inventory integration project here.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryintegration

which completes this issue

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/79

I learned a lot during this sprint about the intricacies of each file and how they work with each other to create a working project and, at large, a system. I remember early on wanting to work on the frontend for the purpose of being able to work with visual design and UI but from working on the integration project I learned the skeleton and bare bones nature of what we are working on, even considered vaporware. Piecing this project together allowed me to realize what kind of work is required to have things up and running so I then realized I might have to hold off on wanting to work on that aspect of the front end, at least for now. What made it even more challenging was that I had to figure out how having multiple frontends changed creating the project as it was a bit different from other guest info and reporting. Even though I was able to use most of what other groups had, it required some time that was spent looking into the contents of the docker compose file.

Before I worked on creating the integration project I updated to the modern java script within the check out guest front end project, this issue was pretty straight forward and only required finding the right lines to change. Thinking that I was going to be working with the design and presentation I was mildly disappointed. I actually think that this issue and the integration project issue could have switched weight as making sure the integration project worked ended up taking much more time and research. The only thing that I think we can improve on is properly assigning weights to issues.

I think what is good is that a group member and I traded the scrum master position for the sprint, he did good and kept the team working well even through some struggles. It led me to wonder a little more about how other groups or even in the industry how people approach the scrum master position, even wonder how well a team functioned based on the certain characteristics of the scrum master. During this sprint we played around a little more with the projects that we were working on and even the structure of the class, which ultimately made working through the struggles that much more enjoyable.

This last sprint was a whirlwind of emotions and struggles for a variety of different reasons. While reflecting for some reason it appears to me that I felt the need to do individual work during this sprint, which probably isn’t the most productive idea while working with a team. There is a lot that can be taken from this;  I have a strong tendency to often go out and explore myself, that I should be a bit more cognizant of my own impulses, and that there’s always a good time for some play. I think I could’ve changed what I was doing so that I could help my group members with what they happen to be struggling with at the time, and that was something that was taken into the next sprint. Overall, this was a very enlightening and insightful sprint that helped me understand the work that it takes to develop software.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Hello and welcome back to my blog. 

This is the second and last sprint retrospective blog post for my computer science class CS-448. For this sprint, our group needed to continue working on the epics created by the professor. The tasks included updating JavaScript code to modern JavaScript, converting all Docker images to multi-architecture images, and writing tests for the backend of the InventorySystem. I worked on these issues in the CheckInventoryFrontend and in the Inventory Backend. 


To update the JavaScript to modern JavaScript, I had to replace “var” with “let” and use “const” whenever possible. This required me to research how JavaScript’s “var,” “let,” and “const” work.

  • Issue #1: Update JavaScript to modern JavaScript

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/12

For this issue, I checked every JavaScript file and added “use strict” to the beginning of them as well as checking if there were any “var” variables.


Continue reading →

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.