Category Archives: CS-448

Exploring LibreFoodPantry and Thea’s Pantry

 In this post, I want to highlight the Code of Conduct section of the LibreFoodPantry community page. This part of the site outlines a pledge that ensures everyone in the community can participate in a respectful and inclusive environment. What stood out to me is the focus on empathy, kindness, and respect for differing opinions. This is especially important in any community-driven project, as it creates a welcoming atmosphere where individuals feel safe sharing ideas and collaborating. I chose to write about this because it’s easy to overlook how important it is to have an outlined set of guidelines that protect participants. The specific examples of acceptable and unacceptable behavior provided are especially helpful, as they create clarity around what is expected. I thought it seemed very similar to the working agreements we created in our first class, and I understand their importance now.

For Thea’s Pantry, I was really excited to see that they use semantic versioning for their software updates. It was very cool to see a concept we covered in class show up in the real world. I’ve seen semantic versioning used at my job, where we track all of our releases, but that is something I expect from a formal company.. Seeing this system used in a project like Thea’s Pantry really reinforced how valuable these best practices are in professional, open-source development.

It’s a great reminder that the concepts we study in class have tangible applications in real-world projects, and it’s exciting to see them put into action.


From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Exploring LibreFoodPantry and Thea’s Pantry

 In this post, I want to highlight the Code of Conduct section of the LibreFoodPantry community page. This part of the site outlines a pledge that ensures everyone in the community can participate in a respectful and inclusive environment. What stood out to me is the focus on empathy, kindness, and respect for differing opinions. This is especially important in any community-driven project, as it creates a welcoming atmosphere where individuals feel safe sharing ideas and collaborating. I chose to write about this because it’s easy to overlook how important it is to have an outlined set of guidelines that protect participants. The specific examples of acceptable and unacceptable behavior provided are especially helpful, as they create clarity around what is expected. I thought it seemed very similar to the working agreements we created in our first class, and I understand their importance now.

For Thea’s Pantry, I was really excited to see that they use semantic versioning for their software updates. It was very cool to see a concept we covered in class show up in the real world. I’ve seen semantic versioning used at my job, where we track all of our releases, but that is something I expect from a formal company.. Seeing this system used in a project like Thea’s Pantry really reinforced how valuable these best practices are in professional, open-source development.

It’s a great reminder that the concepts we study in class have tangible applications in real-world projects, and it’s exciting to see them put into action.


From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Set-up Task #5

LibreFoodPantry

I found it interesting how thorough the Code of Conduct was. The lists of encouraged and unacceptable behavior as well as the tiered consequences for violating the Code of Conduct made me think that there have been lots of instances of poor behavior in this community in the past. I may be completely wrong about this, but if not, it really makes me think about how or why people would join or be invited to this community dedicated to a good cause only to spread hate and negativity. 

Thea’s Pantry

Despite working with Thea’s Pantry for quite a while now, I have not put much research into it at all. I knew it was a place for students and people to get help with food insecurities but I didn’t really know where it was or how it worked for those people. The User Stories give me a great sense of how the pantry works as a guest and some insight into how staff manage it. I liked the listed step-by-step process for the various interactions that make the pantry what it is. I find that following instructions is much nicer than figuring things out on my own so having these stories of how the pantry is intended to work makes me feel comfortable should I ever be in one of the scenarios.

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

CS 448-01 Team 3 Sprint 3 Retrospective (5/7)

Following the very close end to our 3rd and last sprint, I feel like we really put in the effort to finish AddInventoryFrontend. As a team, we completed all of the issues that we were assigned as a team and meet up together for many in-person meetings in order to finally finish up some loose-ends.

One of the biggest things that we finished from last sprint was that we were to got AddInventoryFrontend working. Last sprint was very difficult because the code that we were working on was messy and we had to change a few different approaches to the Frontend since our original approach to create a wireframe which would eventually become the UI did not come together. For this sprint, we had updated our code to be able to finally string together the Frontend with the Backend, like changing around our directory, adding in key files to run the Frontend, and then test through trial and error our Frontend. We used our current wireframe in order to build our Frontend to what we ended up with.

For AddInventoryFrontend, I had worked on updating the Documentation of AddInventoryFrontend since I wanted to be able to contribute more in this sprint. When I looked at the documentation in its original state, I was dumbfounded to find that there were almost nothing there to begin with. It must have looked liked a template since it specified that the linter being used was called test.sh instead of lint.sh. Because everyone on my team was doing so much work on the Frontend and its functionality, I wanted to be able to contribute more as a member of the team, so I decided to modify the documentation so that it would reflect the changes that we made as as a team.

Unfortunately, we were unable to completely fix some issue that we had with our Frontend before the end of the sprint. Our Frontend works great and loads properly now that we have fixed it. If we had another sprint left before the end of the semester, we would have worked on optimizing our Frontend so that the button could work so that you can add and remove units of food from the inventory, and also keep track of how much food is in the inventory through a viewable parameter that would check in the database for the inventory amount. With that being said, any issues that we had with AddInventoryFrontend will have to be resolved next year.

As a member of our team, I definitely could work on trying to practicing some code so that I would be able to make changes that they made with the Frontend. The Frontend was not impossible for me to read since I have played around with HTML before, but I was still trying to figure out all the formatting for our Frontend so I took a good look at our code. I could tell that at the very least that we did our best with creating the Frontend with the little time that we had following our previous sprint, but I would like to not forget about the things we did as a team to create our Frontend. I think that I better understand how AddInventoryFrontend works because I did run the environment on my own. For our presentation, I really hope that we can talk more about how we got our Frontend to work rather than just listing out the issues that we did in our sprint.

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

CS 448-01 Team 3: Sprint 2 Retrospective (4/4)

With the second sprint, we had so much trouble with our sprint until near the end of the sprint. To elaborate on what went wrong, I would like to start out with what we were planning from the very start, as this will be very important for what we will be doing for the next sprint.

While our last sprint, we split between meeting remotely and meeting in-person, we finally decided that it would be better for us to meet in-person. We also came up with a wireframe that we decided to use as our template to create our framework for AddInventoryFrontend (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/blob/main/Developer/Wireframes.md). Since we already had AddInventoryBackend working as intended with the proper testing IDs being used as a way to test our code for the Backend, we only just needed to create AddInventoryFrontend so that we can try to put a frame over all the work that was done with the Backend from last year. At the very least, we knew exactly how we wanted to build our front-end.

On the contrary to how we finally have a plan for our Frontend, I was having lots of trouble with trying to build the Frontend. Since I had lots of trouble with some of the issues that we did, I instead decided to focus on redoing some of the issues we had from last sprint (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/36). At the very least, I could at least contribute a little bit to our sprint, knowing the tasks that we were unable to completely finish.

What we as a team learned from sprint 2 was that we learned about using Vue, a Javascript framework that we would use to help build our Frontend. While we were not able to get the entire page running, we added a functionality to be able to add a button to our Frontend, just as we intended when we were following our wireframe example from earlier. Once we had explored our options to how we would build our Frontend, we decided to use a new wireframe that my teammate would create for our team to follow along with.

The things I could do improve on as an individual is that I need to speak out more with my team about the issues that may have, let it be related to work or anything other. I had trouble with this sprint because I was not great with programming with HTML and Javascript, and I felt like that was really hindering my performance as a team member. I did my best with trying to get help with working on the sprint, and when that was not working out well for me, I consulted my search engines instead. As someone who was much better with AddInventoryBackend, working with the Frontend was not my strength as shown in this sprint. I was confused with what wireframe we were using for the sprint until the end of the sprint when we had a semi-functioning Frontend that we were going to tweak in our next sprint. For the next sprint, I am hoping that I can get to do anything that is not too technical like directly running the Frontend, and I hope that then next sprint will be where our team will be able to get a working Frontend by the end of next sprint.

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

CS 448-01 Team 3: Sprint 1 Retrospective (2/22)

This beginning of the sprint was a very weird sprint, but me and my team managed to make it through without much trouble.

Seeing how the directory for AddInventoryBackend works, it was easy enough to move the files from their VSCode locations to the directory paths that GitPod uses to be able to use the important files. For this sprint in general, we just needed to move the Linters to the correct directories and then try to run them as best as possible. For the Linters that did not work, we either replaced them with other Linters that were accessible through GitPod, or we just removed them. Since we only needed specific Linters to use for our project, our team were able to confirm that we had a sufficient amount of Linters needed thanks in part to consulting our product owner. Also since I used GitLab, creating issues and labeling them were not too difficult either as we were familiar with managing our issue boards, especially since we learned about workflows in a previous class about Software Process Management.

What did not work well was that I was having a very hard time with trying to use GitLab and GitPod, because I had never directly worked on issues before, making it more difficult for me to fully understand how to utilize my environment until near the end of the sprint. I had made myself a note for the next sprint to remember what I have done for this sprint and what else I had to do for next sprint, because I am very mistake-prone when working on a new IDE. GitPod’s changes are new and more convenient, but as someone who has used other IDEs such as Visual Studio Code and Eclipse to name a few, this was a completely new environment that was very unfamiliar to me. While I did make a few notable mistakes like not understanding how to create merge requests or which tags to use, my team guided me to learn how to be able to make those changes by myself after lots of practice.

As a team, we were really prioritizing meeting up together as necessary as possible. We considered using Discord as a means of having our virtual calls since that is where we were going to communicate and do our stand-ups anyways. However, we found that meeting up in-person was much better for us as working on a sprint by call is not consistent with us since joining a Discord call is too inconvenient and takes up too much time. Like I said before, managing GitLab was not too difficult since we all have experience with Scrum from our previous class. I think the best part about our team is that we are very open to helping each other whenever we were stuck on any issues relating to tasks like with the Linters.

For my individual work in the sprint I had done a couple issues to start out with the sprint. I moved the shell script commands from the /Commands bin to /Bin since that is how we were going to organize our shell-scripts like our lint.sh script (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/32). Another task I did was very similar to the first one, except I am instead moving the Docker files to specific directories in GitPod (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/33). The Linter task that I did was to add AlexJS to GitPod so then we can utilize a new Linter to help with checking our code for our project (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/gitlab-profile/-/issues/83). I did all of those tasks before I would verify to make sure that our entire repository was in the correct state (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/35). Overall, I think that I am doing good so far individually with the sprints. The one thing I need to work on as a team member is speaking out whenever I need help or so I can find something in particular to do in the sprint since it is not just my team who has to contribute to our work. I am hoping for this next sprint, I can get a specific issue that I can work on to contribute using my skills that I have learned from my previous classes.

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

Apprenticeship Patters Chapter 2 (Emptying the Cup)

For this week, I read the Apprenticeship pattern “Emptying the Cup”, the second chapter of the Apprenticeship Patterns. I found this pattern to be very interesting since this chapter teaches you how to effectively become a better apprentice, as well as how to use your experience of problem-solving to become a better member of a programming community later on. While the beginning of this Pattern explains the pouring of the tea cup, it is actually a metaphor that pertains to “clearing your mind of bad habits”, meaning that you should remove all distractions or de-motivators so that you can think more openly about the subject in mind.

I find it very interesting that the rest of the sections describing the “tools” to start your apprenticeship are sorted in a specific manner so that you yourself are familiar with all the experiences and different skills needed to learn a programming language. For instance, there is a problem and solution section in the “Concrete Skills” Section of “Emptying the Cup” that caught my attention. The problem state that a team believes that you cannot write a program, but that is where the solution tells you to learn about building concrete skills in order to convince the team to trust in you to be able to do the work. While the rest of the sections does not touch upon anything specific to programming, they all help you in showing your capability to help with coding.

What I found useful in this chapter was the “Your First Language” section that talked about the effective ways of becoming a better programmer. In the “Solution” section, there’s a specific segment where programmer Ralph Johnson explains in an interview on learning a programming language. When asked about which programming language to start with, he say “…the best way to learn a language is to work with an expert in it. You should pick a language based on people who you know. One expert is all it takes, but you need one.” Like the rest of the “Solution” section describes, I have learned that it is better to learn a programming language when you have an person or a group who can help guide you to writing better programs.

While the rest of the sections start to describe the many different problems and solutions to specific problems, the main takeaway I have from reading this apprenticeship pattern is to openly express your problems and work with your team on showing your commitment to programming in your career. I did not have any specific disagreements with this pattern, but I am still am curious about what the other sections have to show for learning the other patterns.

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

The Long Road

Summary

The long road pattern emphasizes the lifelong journey towards mastering software craftsmanship. In a culture that values quick success, it prioritizes long-term growth and continuous learning over immediate financial rewards and traditional career advancements. This path is more for those who are dedicated to mastering the craft than those seeking quick riches or executive rolls.

Reflection

With graduation behind me, it’s fitting to focus on the long road ahead. One of the lines from this pattern that stood out to me immediately was “For every step you take toward mastery, your destination moves two steps further away.” The ongoing theme through my computer sciences degree was that every time I would gain knowledge in a topic I would also gain even more knowledge about now much I don’t know. This really opened my eyes to how much it is going to take to master the craft. This started to feel daunting as it continued to happen, feeling like the destination is always getting further away. However, another key point in this pattern was that the journey is just as important as the destination.

When I think of what I know now compared to what I knew even just 2 years ago, it’s such a drastic difference. Even with the feeling of the destination getting further away, each step I took was still forward in my journey. With each step I grow and gain skills that I can continue to use. 

As I look to begin my career as a software developer, I understand that quick wealth is not feasible with my current lack of experience and knowledge in the field. This however is not something that will change overnight, which is something I am already aware of. As I look for a job, I really am looking for an opportunity to gain experience and learn while getting paid. This mindset values the knowledge and experience just as much as the monetary value gained from the position. As long as I keep this mentality moving forward I see the experience and knowledge paying for itself down the long road ahead. 

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

Sprint 3 Retrospective

Activity on Gitlab (from oldest to youngest)

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

  • Worked on verifying correct linters are present/used, pushed branch and was merged later

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend

  • Helped team by commenting details in regards to issue worked on as a group

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

  • Deleted branch to do some clean up at the end of the sprint

In the dynamic realm of sprint cycles, our team of five individuals embarked on a journey of collaboration, growth, and shared accomplishments throughout Sprint Three. As the semester progressed, we evolved into a more cohesive and efficient unit, leveraging our collective strengths to overcome challenges and achieve our objectives with confidence.

From the beginning of this sprint, our experience was characterized by seamless workflow, effective time management, and a strong emphasis on teamwork dynamics. Through a combination of collaborative efforts, individual contributions, and paired work, we navigated our sprint objectives with precision and determination, exceeding expectations within the designated timeframe.

Reflecting on our previous sprints, we collectively identified areas for improvement and implemented strategies to enhance our performance. One notable shift in our approach for Sprint Three was the refinement of our task allocation process and the adoption of a more strategic approach to problem-solving. Recognizing the importance of leveraging diverse perspectives and skill sets, we allocated tasks based on complexity and urgency, ensuring optimal resource utilization and productivity.

Furthermore, we continued to prioritize inclusive code reviews, fostering a culture of knowledge sharing and continuous improvement within the team. By conducting comprehensive reviews as a team, we not only enhanced the quality of our work but also reinforced our commitment to collective success. Paired work remained instrumental in our strategy, facilitating better communication, collaboration, and task completion efficiency.

Despite the inherent challenges of a five-person team, we maintained a cohesive and supportive environment throughout Sprint Three. Each team member actively contributed to discussions, shared insights, and collaborated with others to overcome obstacles. Our shared dedication to excellence and mutual respect for one another’s contributions fostered a positive team dynamic, elevating our overall productivity and morale.

Moreover, we remained focused on maximizing our time and resources by prioritizing tasks based on importance and feasibility. Setting ambitious yet attainable goals, we remained committed to completing at least 75 percent of our sprint backlog, ensuring progress towards our objectives while allowing flexibility for unforeseen challenges or revisions.

As we look towards future sprints, we are confident in our ability to build upon the successes of Sprint Three while addressing any identified areas for improvement. By continuing to prioritize collaboration, effective communication, and adaptive problem-solving, we are poised to further enhance our team’s performance and achieve even greater success in the upcoming iterations.

In conclusion, Sprint Three was a testament to our team’s resilience, growth, and unwavering commitment to excellence. Through strategic task allocation, inclusive code reviews, and increased paired work, we navigated our sprint backlog with confidence and cohesion, emerging stronger and more united than ever before. As we continue to iterate and refine our processes, we remain dedicated to driving innovation, fostering teamwork, and delivering exceptional results in all our endeavors.

From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.

‘Breakable Toys’ Pattern

The “breakable toys” pattern from chapter 5 is one of if not the most important pattern contained in this book in my opinion. This pattern specifically talks about the necessity of learning from failure even if your work environment does not allow you to do so. A situation like this is common within industries such as software engineering and the example the book gives of a juggler and how someone who can juggle three balls would not attempt to juggle five while actually performing which relates to software engineering as this pattern encourages you to make mistake and learn from your failures on your own time if your workplace does not allow it. “Breakable Toys” also suggests constructing a similar system to the one you may work on at work in order to be able to experiment on your own time and learn from your mistakes in an environment that directly resembles the one you are in at work. You should push yourself to find learning opportunities for yourself through the use of this pattern as if you do not have those opportunities at work then you must make your own in order to continue learning and get better at your craft. It is also stated that your “breakable toys” should be things that you find fun or have interest in so that even though they are meant to provide learning experiences for you, you are still engaged enough to where you look forward to working with them.

I think that this pattern is very important especially to a software engineer. No matter what company you work at there will eventually be a job where you are expected to make nearly no mistakes and you will not be able to try different solutions due to this expectation. But if you are able to experiment with different solutions on your own and see why they may not work or why they do work you can not only learn for yourself but you can also help the team you are working on evolve from using one standardized solution to using one that could be more efficient or faster.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.