Gitlab Descriptions

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend : created addBarcodeFrontend under our teams project to work on the scanner page.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend/-/commit/64bc3d4f720e6e8a69bafa709276beff820f719b : I added the scanner onto the frontend page, using a vue library to make it look good.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend/-/commit/200cac8ad4de849c3647b1223d9bc6f7075b8da2: I fixed the layout to how it ended up looking by the end of the sprint, as well as working on some other issues like fixing camera mirroring, and also added logos to the page.

Team Reflection

As this project is the first time I have worked in a team adopting the scrum methodology, I was a little hesitant at first as to how well we would work together, with possible conflicting problems that would only lead to decreased productivity, but the way that it has turned out isn’t like that at all. An important part of the lack of disagreements comes from our collective trust in each other to produce the outcome that we envisioned from the issue that they were assigned. Our issue allowed us to split our team into smaller teams, focusing on separate issues which would eventually connect to fulfill our team’s original project goal. This delegation of tasks to each subteam has allowed us to focus on our own tasks, while also checking in with each other to see how the rest are doing. This frees us of the burden of trying to work over each other to accomplish one thing which I believe would lead to inefficiencies and conflicting ideas. This subteam workflow allows us to dedicate our time and effort to one topic while checking in on the other topics to stay updated and give feedback. 

Although I just mentioned that the subteam system allows us to check in on each other and give feedback, this is somewhat untrue or at the very least an idealized version of what we are practicing. I do feel that I am working well in my subteam, and with my partner we are efficiently approaching our goal, however when it comes time to check in on the other teams, I feel as though I don’t get enough of an idea of the inner workings of what they’re doing to give good, constructive feedback. The same goes for my teammates giving me feedback. I think that is the tradeoff with this system though because it entrusts you with knowing what you’re doing, and I don’t think it’s as detrimental as it could be because each subteam at least has a partner that does give detailed feedback, sacrificing quantity for quality.

Apprenticeship Pattern

The perpetual learning pattern assumes there is always more knowledge to be known and your journey as a learner is never truly over. I selected this pattern because I think the pursuit of knowledge is important to sustain a continued expansion of knowledge and innovation, as well as satisfying a person’s internal sense of accomplishment and fulfillment. The point that this book tries to make about being a software apprentice is that you can become a master within your lifetime, but that doesn’t mean you stop learning. This pattern fits into the sprint because there was never a time I really felt like I fully understood a concept to a point where there wasn’t anything else I could learn by further investigating it or digging deeper. Even in established technologies or languages like HTML or CSS, there are a lot of things that many people may not know and working with it so much means I am more comfortable with it, but it doesn’t mean I am anywhere near mastering it, following this pattern of perpetual learning.

If I had thought of this pattern before the sprint started I would have gone into it more open-minded, knowing that anything I encountered would be surface level and that if I really wanted to I could go down a rabbit hole for each new thing I learned. There’s so much information out there that is almost impossible to get to, especially for me in the time of one sprint. I think to improve as an individual in future sprints, I could go out of my way to learn as much as I can so I can understand what I’m working on as best I can.

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

My task for Sprint 1 was to add a new date field that shows when the guest was created into the backend API. In this sprint, I worked closely with my teammate Sean Kirwin as he was working on the backend as well. I had to create a reference to the schema for the date of the first entry in the OpenAPI field. Below is the link to the merge request.

What worked well for me in Sprint 1 was being able to work on a task that I had experience with. I was confident to get what I needed to get done in a timely manner. I also appreciated the fact that I was able to work with one of my team members. 

As a team, I believe we worked well together. My team did a good job with the sprint planning and dividing the roles for each task effectively. Each team member was good at communicating what they had done each week of the sprint. I appreciated that my team members were always there to give constructive feedback each week and also helped me out when I had a question about how to navigate working on my task. A way my team could improve is show the work we did for the week instead of just explaining it. It would help visually. 

This task took me more time than it needed to. As an individual, I could improve my time management when it comes to working on my assigned tasks. Although I had improved my communication with the team throughout the sprint, I think I could do. I did not necessarily have issues with making the changes to the files, however, my partner and I had issues with the merge request. The pipeline kept failing because of the lint-commit-messages, but my partner and I were able to resolve this issue with research. 

The pattern I related to from the Apprenticeship Patterns book was “Learn How You Fail”.In this chapter, it highlights the significance of being aware of your weaknesses and areas of failure. It implies that although learning improves performance, shortcomings and failures endure unless they are actively addressed. The most important lesson is to seek self-awareness about the actions, circumstances, and habits that contribute to failure. Making deliberate choices either to accept and overcome limits or to do better in particular areas is made possible by this self-awareness. The pattern promotes a balanced approach to growth and discourages self-pity or perfectionism.

I chose this pattern because it is closely related to my experience during the sprint. I ran into issues with time management, working with others on code reviews, and managing merge request issues during the sprint. I became aware that I was frequently making the same errors, such as failing to consider edge scenarios or misinterpreting project specifications. I could have dealt with these failure patterns proactively rather than reactively when issues emerged if I had been more deliberate about identifying them early. The “Learn How You Fail” pattern would have helped me take a step back, identify recurring problems, and strategize ways to improve.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/107

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

Evidence of Activity on GitLab

1. Meeting with Customer to Identify Categories
   • A .js file named categories.js was built to help my peers start testing different category structures.
2. Data Extraction for TeaSparty Project
   • The USDA FoodData Central downloadable data was extracted to build a comprehensive database.
3. Database Optimization
   • The original database file was over 3.2GB and contained multiple unnecessary fields.
   • A Java file was developed to remove unnecessary fields such as foodNutrients, nutrients, rank, protein, and their respective IDs.
   • Successfully reduced the database from 3.2GB to 0.7GB, making it more manageable for our project.

Reflection on What Worked Well

1. Customer Collaboration
   • Meeting with the customer to identify category requirements ensured that the project met their needs effectively.
   • The creation of categories.js provided a starting point for peer testing, helping streamline future work.
2. Database Optimization
   • By removing unnecessary fields, the database was significantly reduced in size, improving efficiency.
   • The pre-cleaning process helped identify redundant fields early on, making subsequent steps more manageable.

Reflection on What Didn’t Work Well

1. API Call Extraction Issue
   • Initially, I attempted to extract the database via API calls but encountered a limitation: API calls only supported retrieving 100 items at a time, whereas there were over 100 pages to extract.
   • Researching solutions, I found that automation was the best approach, but due to my lack of expertise in automation, I couldn’t implement it effectively.
2. Challenges in Categorizing Products
   • A Java file was created to categorize all products, but it was crashing due to issues with object field descriptions containing multiple nested quotes.
   • Example issue: "description":"ORIGINAL SWEET & SMOKY BAR \"\"B\"\" \"\"Q\"\" SAUCE, ORIGINAL".
   • As a workaround, I manually cleaned some of the problematic entries but am still looking for a better solution.

Reflection on What Changes Could Be Made to Improve as a Team

• Better Communication
  • Ensuring consistent updates within the team would help synchronize our work and avoid redundant efforts.
  • More frequent check-ins to discuss roadblocks and potential solutions could improve efficiency.

Reflection on What Changes Could Be Made to Improve as an Individual

• Increase Work Hours on the Project
  • Spending more time on the project will allow my peers to see my progress and provide feedback earlier.
• Dependency on Others’ Progress
  • I am currently waiting for Alex to finish the dev container. In the meantime, I am focusing on cleaning the db.json file so I can upload it as soon as possible.

Apprenticeship Pattern: “Expose Your Ignorance”

Summary of the Pattern

The “Expose Your Ignorance” pattern from the Apprenticeship Patterns book emphasizes acknowledging one’s knowledge gaps and actively seeking to learn. It encourages transparency about what you don’t know while making efforts to bridge those gaps.

Why This Pattern Was Selected

During this sprint, I faced challenges with API automation and data cleaning that slowed my progress. If I had openly acknowledged my lack of expertise in automation sooner, I could have sought help from peers or external resources earlier in the sprint. This pattern aligns with my experience because it highlights the importance of being upfront about knowledge gaps and taking proactive steps to fill them.

How This Pattern Would Have Changed My Behavior

Had I followed this pattern earlier in the sprint:

• I would have sought advice from team members or forums on API automation instead of spending excessive time trying to figure it out alone.
• I would have explored existing libraries or tools for handling JSON parsing issues more efficiently instead of resorting to manual cleaning.

Conclusion

This sprint provided valuable lessons in data handling, API limitations, and the importance of seeking help when needed. Moving forward, I plan to improve communication within the team, allocate more time to the project, and be more proactive in addressing technical challenges. Applying the “Expose Your Ignorance” pattern will help me become a more effective contributor in future sprints.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

GitLab Activity

During this sprint, I contributed to multiple aspects of the project, focusing on both collaborative research and frontend development. Below are the key tasks I worked on, with links to the related issues:

1. Issue #26: Created a fake frontend – Designed and developed a simulated frontend to represent the user interface for testing and demonstration purposes.
2. Issue #20: Researched Docker architecture – Collaboratively explored and documented Docker architecture with the team to establish a strong foundation for the project’s infrastructure.
3. Issue #31: Created dummy pages for frontend login redirect – Built placeholder pages to simulate the login redirection process, enabling smoother navigation during development.

Reflection on Performance

What Worked Well

This sprint highlighted some clear wins for both myself and the team. Collaborating on Docker architecture research proved to be an invaluable learning experience. By pooling our knowledge and resources, we quickly gained a better understanding of Docker’s potential for our project. On the frontend, creating the fake frontend and dummy login redirect pages allowed me to apply and refine my skills in UI development. These tasks were particularly fulfilling because they provided tangible progress toward a functional interface.

What Didn’t Work Well

While the sprint had its successes, there were also challenges. Managing time effectively across multiple tasks was one of my personal struggles. For instance, balancing the research on Docker architecture with the development of the frontend required careful prioritization, and I occasionally found myself spending too much time on one task at the expense of another. Additionally, the lack of established workflows for testing the fake frontend made it harder to identify and fix issues early on.

Changes to Improve as a Team

As a team, we could benefit from setting aside dedicated time for pair programming or collaborative problem-solving sessions. This could enhance our understanding of challenging topics, like Docker architecture, and ensure that everyone feels confident in applying what we’ve learned. Regular check-ins or daily stand-ups could also help us address blockers more quickly and align our efforts more effectively.

Changes to Improve as an Individual

Individually, I want to work on improving my time management and task prioritization. Establishing a clear plan at the start of each sprint, with time allocated to specific tasks, could help me maintain better focus. I also aim to proactively seek feedback on my work, particularly when tackling new challenges like Docker architecture, so I can learn more efficiently and avoid unnecessary delays.

Apprenticeship Pattern Reflection

Selected Pattern: “Expose Your Ignorance”

For this sprint, I chose the Apprenticeship Pattern “Expose Your Ignorance” from Chapter 2. This pattern emphasizes the importance of acknowledging knowledge gaps and actively working to address them by seeking help, asking questions, and being open about what you don’t know.

Summary

The pattern advocates for embracing ignorance as a normal part of the learning process. It challenges the notion that developers should appear to have all the answers, encouraging honesty and curiosity instead. By exposing ignorance, individuals can learn more effectively and foster a collaborative environment where everyone feels empowered to grow.

Relevance to My Experience

This pattern resonated deeply with my experience during the sprint, particularly in the context of Docker architecture research. Initially, I felt hesitant to admit my lack of familiarity with some Docker concepts, but collaborating with the team and sharing our findings made the learning process much smoother. Similarly, while working on the fake frontend, I encountered unfamiliar scenarios where seeking guidance earlier would have saved time.

How It Would Have Changed My Behavior

If I had fully embraced this pattern from the beginning of the sprint, I would have been more proactive in asking questions and seeking clarification during our Docker research sessions. I might also have reached out to teammates or mentors for advice on frontend best practices when creating the fake frontend and dummy pages. In future sprints, I plan to actively apply this principle by fostering a culture of openness and curiosity, both for myself and within the team.

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

What worked best in this sprint was our team’s collaboration and the understanding I gained through independent research. From the get-go, our team had very few issues communicating. We checked in on each other during class and collectively made decisions on the project’s future without any conflict. Everyone seemed committed to their tasks, which allowed us to complete our sprint goals on time.
Throughout the sprint, I encountered many aspects of the project I was unfamiliar with, including RabbitMQ, MongoDB, and Docker. A lot of my time was dedicated to researching, reading blog posts, watching tutorials, and testing to understand how they worked. With the newest Sprint 2 goals involving the production and consumption of data using RabbitMQ and inserting it into MongoDB, I feel more confident handling these tasks.

What did not work well in the sprint were some complications with my operating system and a lack of documentation on GitLab. At the beginning of the sprint, I had trouble opening a port with my Mac, with my solutions working in some moments and not working in others. Eventually, that issue was fixed, but being unable to test during that time hindered my contribution. I worked locally to get things running with my Mac, testing the reporting backend and understanding how everything fits together, but I did not always push that work or create merge requests to show my progress. Much of my effort went into trial and error testing, and sometimes, my work felt redundant. I need to better communicate with the team so I can accomplish tasks more efficiently.

So far, we have been communicating well in class, and there has not been a need for constant checkups on Discord. That could change, and probably should, with the upcoming sprint. We will need to communicate effectively if our tasks end up conflicting. I could communicate better on Discord and will strive to do so in the next sprint. Working around work and school has been difficult, so I should discuss that with my group so we are on the same page.

The pattern from the Apprenticeship Patterns book that aligns well with my experience during Sprint one would be Confronting Your Ignorance. This pattern involves identifying gaps in your knowledge and actively working on them, even if the gaps are from areas people on your team assume you already know. It encourages you to fill these gaps through whatever methods work best for you, including reading, individual projects, or asking for help.
I selected this pattern because I recognized gaps in my knowledge and confronted them so I could contribute to the team effectively. I spent a lot of time getting familiar with RabbitMQ, MongoDB, Docker, and the Reporting System. I leaned on some of my teammates, who felt more comfortable with the tools, asking questions during class. I also did independent research, reading blog posts, tutorials, and documentation. These aspects of the sprint were most relevant to the Confronting Your Ignorance pattern.
I do not believe reading the pattern would have changed my behavior during the sprint. I understood that there would be different levels of expertise in a team, and not knowing something was not a weakness but an opportunity to learn. What’s important is that you take steps to fill the gaps in knowledge, which is what I strived to do during the sprint.

Link to Gitlab:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/37999a7f42ed4eb89d6f7ab2e2a4d530fec3010c

• Updating the dev container file and fixing the issue where the 10350 port would close unexpectedly.

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

To start, this was my first real team project where I felt like all of the team members were highly capable of putting something of value together. It’s been a great experience to learn and collaborate with such a good group.

We started this project basically from scratch, learning just how difficult that actually is. Over time we worked out our goals and expectations along the way. Through some facet of peer pressure and blind faith I got elected to lead the team, though each member has done something to guide all of us in one way or another. 

This leads to the topic of what worked well with our team. First, we all tried to get to know each other a little better. Aside from having the same major and concentration, a friendly connection has absolutely benefited us when it comes to communicating and holding each other accountable. It also fostered an environment of being able to ask questions and for help when it was needed. It quickly became a good time coming to class and being on time just to see each other and show our work in person. Due to instinct or pure luck, the best move we made was breaking our group up into pairs, otherwise known as pair programming. This allowed us to have 2 people focusing on each aspect of our project making progress in all areas simultaneously. 

For myself, one part I would like us to improve is being more on top of explaining the finer details of what each pair is working on. Being the leader I am seeing the big picture of the project but I do feel at times the others get a little lost in their own portions. During the sprint reviews I think we did a good job showing each other what that meant, but we could certainly get better when it comes to the day to day aspect.

All of this culminates into one of the things that really stuck out to me in the second chapter of the book Apprenticeship Patterns referenced in a previous blog. This chapter was about “emptying the cup”. This phrase is an amazing metaphor for not allowing yourself to think you know too much to be able to learn from others. Too often have I myself fallen victim to my own thinking of already understanding all there is to know about a given subject. Sometimes it’s really beneficial to go into something with a fresh and open mind.

For example, while developing the inventory back-end there were at least 5 times where I had to start completely over. While this sounds like it would be extremely frustrating I was noticing that every time this happened, I was learning something new along the way. After having worked with the guest info back-end I thought I was going to breeze through replicating it. It wasn’t until doing it over and over that I realized just how much I was missing under the surface.

Nearing the deadline I was actually becoming a little worried that it wasn’t going to work out in time. We would have to move it into the next sprint. However due to having so much practice and my partners assistance making a mock version of what i was creating. We were able to very quickly and easily put together a working prototype of the true vision we had. This prototype is also proving to be fundamental to how we continue into the next sprint.

In the end my team came together and had 3 portions of this project ready to demo for the customer and our professor. It all worked exactly how we planned and it was so refreshing to witness. We all did a great job and should feel proud for how far we managed to come in just one month working on this and knowing each other.

Here are all 3 portions

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/guestinfobackend/-/tree/main/src?ref_type=heads

• This is a 2 for one. 

• The mock database itself was created by me and my pair partner Prince.

• The script to fetch data from an API we are utilizing was done by our teammate Anairdo

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

• This directory is the front end our other teammates have been working on to pair up with our backend. Credit to Adam and Donna

From the blog CS@Worcester – Mike St G – 448 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

Created a separate branch from the frontend to solve the CORS/SSL issue

Created epics for larger tasks and broke them down

Organized tasks into issue boards

Prepared for Sprint 2 by adding new tasks

Documented important information regarding issues and how they were solved

In sprint 1, we were able to mostly complete everything we planned out; needing some revisions in certain areas. As a team, we performed well with eachother and communicated effectively to ensure all tasks were progressing at a timely manner. Additionally, we looked to eachother for help when we were stuck and didn’t know how to progress further, preventing teammates from falling behind in their tasks. What didn’t work well ocurred near the end of the sprint, where a teammate didn’t fully complete their task like they were supposed to, requiring one person to complete their task in sprint 2. This problem could have been solved if the team incorporated weekly code reviews to ensure that all areas of the task is looked over and nothing is forgotten. As the scrum master for the team, I plan to push for this element in future meetings.

Another improvement for the team that will be implemented in sprint 2 is better meeting time management. Since we only meet twice a week as a team, we should take this time to share progress we have made to the whole team. This could be any code written or any interesting articles that are useful to know. The primary goal of the capstone is to simulate a real development environment and solve tasks effectively. Equally important, however, is the opportunity to absorb and learn as much as possible. Something your teammates discover may prove valuable to you in your future career.

To improve as an individual, I want to get involved in other peoples tasks and try to offer my input in any way possible. Instead of being preoccupied by my own assigned tasks, widening my scope of work to my teammates tasks will allow me to grow as a developer and expose me to various tasks.

One pattern from Apprenticeship Patterns, that aligns with this sprint is “Confront Your Ignorance”. The pattern emphasizes the importance of recognizing and addressing gaps in your knowledge. Instead of avoiding unfamiliar topics, you should actively seek out challenges that push you to learn. This involves identifying areas where you lack expertise, setting goals to improve, and dedicating time to research, practice, and experiment. By taking on tasks outside your comfort zone, you develop problem-solving skills, adaptability, and a deeper understanding of new concepts. It pushes you to adopt a continuous growth mindset and helps you become a more effective and well-rounded developer. Going into capstone, I knew that I wanted to push myself to learn as much as possible, which is why for the first sprint I chose a task that I had zero prior knowledge about. In order to work on my issue, I had to research about CORS and SSL certificates, both of which are crucial concepts in web security and backend development. This process involved reading documentation, troubleshooting errors, and experimenting with different configurations to understand how they functioned. Choosing this issue to work on has also exposed me to the use of proxies, that route frontend requests to the backend. Utilizing a proxy will ideally allow the http backend url to connect to the https frontend url. In sprint 2, I plan to experiment more with proxies.

From the blog CS@Worcester – Computer Science Through a Senior by Winston Luu and used with permission of the author. All other rights reserved by the author.