In sprint 2 my team and I actually got the project functioning as we had intended. We now have a webpage with a scanner that can read UPC codes off any product we can find. A fetch script that takes that UPC code and uses an FDA API to give us data on the product. This data includes brand, brand owner, product category and a description. This data is then merged into our back end and stored with a quantity that gets manually entered. 

While demoing the webpage our customer seemed very interested in it and how user friendly we had made it. They seemed concerned about having to scan every individual product until they saw that you only needed to edit the quantities after scanning one single time. There is only one issue we have in that regard. We are not able to find absolutely any products data in that FDA API. However we are in the process of creating manual entries that will be saved, so it will only be a problem the first time that item is scanned. Attempting to keep our theme of user friendliness.

It has been cool and very rewarding for the team to actually see our project function this way. We’ve all done projects where things don’t really get to the point of looking and functioning like a completed product. This is a first for a few of us.

Our communication with each other during the weeks has stayed pretty consistent throughout this entire semester. I would say that is the strongest characteristic of this team. We all hold each other accountable by just being visible and seeing the others working hard to get this done.

Relating our team with a chapter from the book apprenticeship patterns, a good one would be – be the worst. With our strong communication and the fact we are putting the different parts of our project together into one product. We all noticed the strengths each member has to offer. All though this does not perfectly match the example of the book by surrounding yourself with a full team that is better than you. I think we have all done a good job at noticing each other’s strengths and understanding of each portion. This sprint showed how much we really started to learn and grow as a team. 

After sprint one I wanted to make it clearer for everyone to understand what each part of the team was doing and where they were at. This sprint actually managed to do a lot of this for me. While putting the pieces together everyone really started to see the full picture and there was points when you could see the excitement across everyone’s face when things started to shape up and start working. This also proved to create a more cohesive team as the pairs that had been working in a more broken off system were having to explain what they did in order to get certain parts to function properly. Now that everyone’s working in the same directories we all witness the fast pace of progress we have had the whole time, that I believe I was the only one really witnessing.

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

-this is the current state of our project. It has a working webpage, back end and fetch script that works between them.

Start up:

• start the backend using bin/rebuild.sh

• Install the live server extension on vscode
• Right click scanner.html and open with webpage
• Start scanning items =]

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.

If I were to put our journey so far in simpler terms, that gamers like myself would have an easier time understanding, I would say that this whole project has felt like an MMORPG game. During the first sprint, we all had nearly no idea what we were doing, trying to do easy tasks just so we could get a few levels and understand the mechanics behind the game so we could maybe get a glimpse of the bigger picture. After that was said and done, coming into the second sprint of this project, we all felt more comfortable with the project and its continuity. By now, we all have a clear image of our roles and what we bring to the table. We no longer run around aimlessly trying to defeat a minor boss, but now each of us has developed specific skills that make “fighting challenges” feel like a walk in the park, and everything goes smoothly like clockwork.

The one apprenticeship pattern that I would choose for this sprint would be “Concrete Skills – Making your abilities tangible and demonstrable”. We are entering into a more advanced phase in our journey as CS students, with most of us graduating in a month, so now is the time to let go of the abstract knowledge and hone tangible and demonstrable skills. This pattern really pushes you to refine your skills with specific and marketable abilities. The division into subgroups pushed us to learn more about particular skills. Working on the backend and connecting it to the frontend pushed me to learn or better yet, refine some skills that I thought I had a pretty good understanding of until I had to put them in practice. My teammates had already done a great job setting up the front end and adhering to visual identity guidelines, which meant I had to do as good of a job as they did, making everything functional and smooth.

After creating a functional backend last sprint, now I had to connect it to the frontend and make it actually “do something”.
I started by copying the front-end files my teammates had worked on so far to our main branch and started editing their scanner and database files. A simple JS script to fetch the information from the FDC database and add it to our own backend was all that it took to give life to our project. It took me a while to figure out the correct pathing for each API call, but once that was set up, everything was a breeze. My teammates had also created a “Database” page in which we would store our scanned products. I populated the page with items stored in our backend from the previous scanner page. After that, adding two buttons that were connected to simple API calls made the page more interactive. Now we can easily store, edit, and delete products, which is way more than what was asked of us initially.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend/-/commit/b57e1ea44a8113bac4075769da0b25336c975c8f – my latest commit with all the functionalities.

I guess if I had prior knowledge of the above-mentioned pattern, I would have had an easier time working on the project, as I would have “honed” my knowledge of backend-to-frontend connections beforehand, which would make my work even more efficient.

My teammates continue to be a great force in this project, and we are able to communicate clearly between us and solve issues in a short and manageable time without putting a lot of strain on ourselves. In fact, our communication might even backfire in a sense because we solve the issues so efficiently that we don’t even put them up on the issue board, a simple “hey, we have to fix this” is all that it takes to “clear” an issue, so we might want to work on that a little bit for the upcoming sprint.

Going back to my analogy, I guess that by now we have reached “level 40” with the cap being at 60. I hope that as we reach the “end-game,” we continue to have the great teamwork that we have had so far and that has helped us so much. We all have our roles and work cut out by now, so tackling this last sprint should be easy, with the end result being a successful project that we will leave behind but take with us valuable, tangible skills to help us take on future projects and challenges.

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

During Sprint 2, my main task was to update our REST API by replacing the use of WSUIDs with UUIDs. Our sprint planning phase for this sprint was good, we broke down the tasks into what everyone would be doing for the sprint. Our communication was effective, especially during our team meetings in class. To implement the switch from WSUID to UUID, I updated the open API specification to reflect the new identifier structure. One of the key wins in this sprint was the successful refactor of the API to use UUIDs instead of WSUIDs for identifying guests. This transition improved the design by making guest identifiers more secure and consistent. I gained a deeper understanding of Open API specifications and how to maintain consistency across the schema definitions and endpoint parameters. Using UUIDs helped eliminate potential conflicts or collisions that may have occurred with custom WSUIDs. Collaboration also worked well with my team. Once I communicated the change to my teammates, everyone was supportive in reviewing related files and helping test the changes locally. This made integration and deployment less stressful.

At first, I underestimated how widespread the WSUID field was across the codebase. I initially thought I could change a few lines in the schema, but it quickly became clear that the change had to be made in multiple endpoints, error responses, and even test data. I had to backtrack several times to hunt down instances of WSUID that I missed earlier, which slowed down progress and created some confusion. Additionally, I didn’t write enough tests initially. As a result, one of the updates to the /guests/{uuid} path temporarily broke until I realized the mock data still used WSUID formatting. In the future, I need to write and run tests as I go rather than treating it as a final step. As a team, I think overall we have worked well and collaborate well with each other. Personally, I need to improve at assessing the scope of tasks more accurately. I underestimated the time and complexity involved in replacing WSUID to UUID. I want to become more consistent about writing tests early in the process.

“Be the Worst” from Apprenticeship Patterns (Chapter 2) encourages developers to seek out teams where they are the least experienced. The idea is that being surrounded by more skilled developers pushes you to grow faster through mentorship, observation, and collaboration. During this sprint, I didn’t have as good experience working with API design and backend architecture. At first, I felt a bit behind, especially when I didn’t account for all the areas affected by the WSUID-to-UUID switch. This pattern reminded me that growth often comes from being challenged by your environment and teammates. Had I internalized this pattern from the start, I would have asked more questions earlier instead of assuming I had to figure everything out solo. I would have scheduled a quick check-in to confirm I was on the right path before updating the spec. By embracing being “the worst,” I could’ve saved time and avoided some of the errors that slowed me down mid-sprint. This sprint taught me that meaningful growth comes from deep work, reflection, and surrounding myself with teammates who challenge and support me. I look forward to carrying these lessons and complete sprint 3 successfully.

References.

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

From the blog CS@Worcester – Lynn'sBlogs by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

A lot of things worked pretty well this sprint compared to the last. Communication, effort, work, progress, collaboration, planning, and more were all present and at a great level compared to the last sprint. We still had our own section that we mainly worked in but there was plenty of collaboration for tackling a difficult issue, researching an issue, or just divvying up work should someone have free time. I think that our Sprint 2 goal was very concrete and our issues that we made at the start of the sprint as well as throughout led to a smooth sailing to the finish line.

I wouldn’t say that there was anything that didn’t work well but rather things that could be worked on. Communication could always be improved, and even though it’s a night and day difference between Sprint 1, there were some points in which it would’ve been nice to hear from certain team members what was going on or why they weren’t present. This may be more of just my personal feelings but there is one member who handles almost all Gitlab organization and use and takes notes of our meetings, and I’m not sure if it’s for their sake or for the team’s sake, but I feel that they could ask the rest of the team to help with any of these. They are the most adept at using Gitlab and I assume wants to stay on top of things and as organized as possible but I’m certain other team members could help out even if a little. 

To improve as a team, communicating when a team member can’t make the meeting and making good progress and decisions without certain team members present would be great. I think we divvy up our issues well but other work that aren’t exactly issues could be divided up between members especially if it’s rather menial.

I think I could’ve gathered a better idea of our group’s work and flow and what other team members are working on. For the Sprint 2 Review, I prepared to share what I had worked on but was wholly unprepared to share what other members have worked on and present our work. 

The apprenticeship pattern I felt was most relevant to my experiences was “Confront Your Ignorance” from Chapter 2. This pattern states that “There are tools and techniques that you need to master, but you do not know how to begin… and there is an expectation that you already have this knowledge.” The solution to this pattern states to “Pick one skill, tool, or technique and actively fill the gaps in your knowledge about it.” Although this pattern doesn’t exactly describe my experience during the sprint, it felt the closest out of all the other patterns. Rather than tools and techniques, I would say that I need to better understand our group’s work and plans as well as individual members’ work. To handle this, I could go through our Gitlab issues seeing what has been accomplished and who is assigned to what, I could explore our repositories to get a better understanding of the individual pieces of the project, and I could simply ask my team members about what they have worked on, what they plan to work on, and their idea of our group’s work. Taking notes would’ve been a great option as well due to how much information might be shared during our meetings.

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

This sprint pushed us a bit more out of our comfort zones as we moved deeper into authentication, authorization and infrastructure setup. While we had a better sense of our team dynamics and project direction, some unexpected technical challenges tested our adaptability and communication. Especially, With Keycloak setup and JWT integration becoming a major focus, we encountered some unexpected challenges that helped us grow both technically and as a team.

Evidence of activity

• Configure Realm Export Script/Command(s): Exported realm configuration from binary to JSON to enable version control and team collaboration.
• Added user group/role to JWT payload: Configured keycloak settings to add users needed information to JWT payload.

What worked well

Clearer Role Distribution:
This sprint had more defined roles, which helped prevent overlap and increased efficiency.

Deeper Technical Understanding:
Working with Keycloak gave us valuable hands-on experience with client scopes, tokens, and user roles.

Proactive Communication:
Team members were quicker to reach out for testing, review, and feedback. That made a noticeable difference in momentum.

why didn’t work well:
One major challenge was managing Keycloak realm configuration collaboratively.

At first, we exported Keycloak changes (clients, roles, users) using the admin console, which generated binary .realm files. These couldn’t be diffed, merged, or version-controlled properly. This became a blocker when multiple teammates made changes at the same time.

The workaround:

• We each exported changes into JSON format.
• Then we manually merged the configurations later, ensuring nothing was overwritten.
• We also began documenting our changes to avoid confusion.

It was tedious and not ideal, but we learned the value of choosing version-control-friendly formats early on when working with tools like Keycloak.

Individual improvement goals:
– Programming Improvement: Over the last sprint, I struggled with translating my thought process into actual code and logic. This made me realize that while computer science courses often emphasize theory, I need to spend more time improving my practical programming skills to bridge that gap.

– Ask Sooner: I struggled with JWT for hours, when help was just a message away.

Apprenticeship Pattern: “Concrete Skills”

Summary:
The “Concrete Skills” pattern emphasizes the importance of acquiring real, tangible skills that make you immediately useful to a team. These are the kinds of abilities that allow you to contribute from day one—whether it’s setting up a development environment, debugging a system, or deploying a service.

Why I Chose It:
This sprint made me realize how much more confident and helpful I feel when I have concrete, hands-on experience with the tools we’re using, especially Keycloak. Initially, I felt lost trying to work with realm exports and JWT validation because I didn’t have real-world practice with them. After digging in and troubleshooting the JSON config issue, I started gaining practical skills that I could apply directly to our project.

How It Could’ve Helped Earlier:
If I had taken time before the sprint to develop specific, concrete skills—like how to export/import Keycloak realms properly, or how JWT verification works at the code level, I could have contributed more efficiently and with less frustration. This pattern reminded me that building a toolbox of real, usable skills is what makes you valuable in a team setting—not just theoretical knowledge.

Final Thought

Sprint 2 challenged me on a deeper level, not just with code, but with collaboration, tooling, and infrastructure. The lessons around version control, documentation, and communication will stick with us as we move forward. We’re not just building an app—we’re learning how to work like a real development team.

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

When choosing an apprenticeship patten to write about for this sprint, Chapter 4’s Rubbing Elbows stuck out almost immediately. The problem raised by the authors is one for those who prefer to work independently when writing and developing software. The agency to decide which direction to approach a task, coupled with the efficiency of being the only decision maker, is appealing, and developers can absolutely be successful working this way.

The downside is, those who work alone cannot draw on the experience and knowledge of others, and place a hard limit on their productivity. Additionally, there are so many micro-techniques that can sometimes only be learned through partnership; small strategies that on their own are insignificant but accumulate over time into a much stronger knowledge-base.

The balance between independent and team focused development is something that I would like to continue to work at. Over the past sprint, I believe I did a better job of communicating progress on my issues and problems I needed help with. That said, I could always be better. I would like to place more focus on making myself available to my team mates for assistance with issues. Partially due to the desire to be productive and deliver a successful product, but also due to the ideas outlined in the Rubbing Elbows pattern. I’ve found over the past sprint that an area I’d like to improve in is the more practical knowledge that I would normally pick up working in groups and communicating with my team.

Some tasks I accomplished during the sprint:

1. Completed JSDoc Environment setup: Our backend code now uses JSDoc compatible tags in comment lines, which is used to auto-generate developer documentation. Link
2. buildReport outputs correct report totals with headers: the buildReport class in our reporting system backend correctly formats report headers and calculates correct tallies for visit info. Link

For the final sprint, I plan on finalizing the buildReport backend code and designing tests to be ran on the function. The final component is the connection between the backend code and the database, which I also will be working on with my team. Because we are now in the final sprint, my main overall goal is to finish developing the project as far along as time allows before making sure the environment is prepared for future work.

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.

Last week, my team completed our second Sprint. Like the first Sprint, we did a good job. Each of us stuck to the parts we left off after the first Sprint, so with me, that meant continuing with the CheckInventory frontend. The issue I wanted to get done by the end of the first Sprint was connecting the backend to frontend, so that instead of displaying a hardcoded value, it would pull from the backend. By doing so, the frontend would have its full functionality. However, that was easier said than done, as I spent almost two weeks trying to figure it out, only for my teammate to figure it out before me. They had created a shared network for their frontend that connected to the backend. I ended up using the same shared network with no problems. I created a method that called ‘GET’ from the backend in order to display the value. The next issue was figuring out how to call this method upon mounting the page. I spent a week trying to solve this, until it was suggested that I try calling it through a button press, as that had success with my teammate’s frontend. I tried that, but the button simply refreshed the page. Later, I tried a different button, which ultimately worked. However, I was not satisfied with that, so I did some more research and found a ‘beforeMount’ method, which solved the problem. I committed, and made a merge request for both the shared network, method and mount issue. With a week left of the Sprint, I spent time playing around with the design of the frontend, as there was discussion in the visual identity team. I refactored the frontend in order to call the header, CheckInventory, and footer components in the App.vue file, instead of using a router, like it was originally. I then fixed the footer to sit properly, and used the appropriate colors and fonts, according to the school’s guidelines. I completely overhauled the header, using the ‘Thea’s Pantry’ logo, adding a navigation bar, and adding a yellow strip to the bottom. Additionally, I used the correct colors and fonts, once again complying with the school’s guidelines. I was able to commit and merge those changes before the end of the Sprint, and present them to the client.

What worked well was still communication. We all communicate really well, and when we need something from someone, or someone to review something, it’s done fairly quickly. Our chemistry has also become more friendly, we’re more open and joke around with each other, while also being strict with our work. Speaking of work, something else that worked well was solidifying our roles in a way. Since we all stayed working with stuff we worked on during the first Sprint, we knew what we were doing from the beginning, instead of figuring out everything from scratch. Personally, what worked well for me was being proactive, especially with the design part of the frontend. I felt motivated to make it look good, and it felt less like work. However, something that did not work for me was again the expectation of doing enough. Towards the end, I felt like I was, but I felt most of the time I wasted a lot of time researching. It is not exactly my fault, but it also is.

As a team, there’s not much we can improve on, as communication is good, chemistry is great, and we have done a lot of work and progress. Something I suggested in the last blog post was clarifying what we are working on, like a stand up at the start of class. We had done this one time. Although I do not think it’s necessary, it could be a way to clear up confusion if there is any. Personally, what I want to improve on myself is using my time better. I feel I spend too much time researching, and although I cannot just speed that up, I could do it more efficiently.

The Apprenticeship pattern I chose for this Sprint was “Retreat into Competence,” in layman’s terms means I am overwhelmed by how dumb I am. This is referring to the fact that I have to spend time researching in order to fix my issues. There is nothing wrong with doing that, it is just that I spend too much time doing that. If I had read that before the Sprint, it probably wouldn’t have changed anything.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-category-based/frontend/-/blob/WEB-APP-FRONTEND/src/frontend/src/components/BurgerMenu.vue?ref_type=heads

This is the link to the burgermenu component that I recently implemented.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-category-based/frontend/-/blob/WEB-APP-FRONTEND/src/frontend/src/App.vue?ref_type=heads

This is the link to the change i made in APP.vue to make sure the navigations between pages was working.

What Worked Well

What worked well this sprint was my ability to identify the direction I needed to go in early. By proactively researching what types of menus we needed (such as a scanning menu and an inventory display menu), I was able to start building out the feature rather than waiting for instruction. Additionally, I took more ownership of frontend work this sprint, which helped me feel more confident in my contributions. Our team also communicated better this time, which made planning and aligning tasks easier.

What Didn’t Work Well

Time management was one of my weaker areas this sprint. While I began working on the menu features early, I underestimated how long certain aspects, like tying barcode input to inventory display, would take. As a result, some parts are still in development. Another issue was not asking for help as early as I should have when I got stuck on some front-end design decisions, which could’ve saved me time.

Team Improvement Suggestions

Our team has improved in communication and breaking down tasks, but we could still do a better job tracking progress on GitLab. Sometimes, issues remain open even after tasks are completed, which makes it harder to see what’s done at a glance. Adding regular, short update posts during the week, even if work hasn’t been pushed yet would help us stay more aligned. I also think we could benefit from regular 15-minute team syncs mid-sprint.

Personal Improvement Suggestions

Individually, I’d like to work on improving my frontend development speed and getting more comfortable integrating UI features with logic and API calls. I also need to be better about reaching out when I hit roadblocks rather than spending too long stuck. Going forward, I will try to break down my assigned features into smaller sub-tasks and check them off one by one to maintain steady momentum.

Apprenticeship Pattern: “Expose Your Ignorance”

Summary:
The “Expose Your Ignorance” pattern, found in Chapter 2 of Apprenticeship Patters by Dave Hoover and Adewale Oshineye, emphasizes that developers shouldn’t hide what they don’t know. Instead, they should openly acknowledge areas of inexperience and use that as a tool to learn and grow. This transparency not only helps personal development but also builds trust within teams and encourages collaboration.

Why I Chose This Pattern:
I chose this pattern because it perfectly describes one of the issues I struggled with this sprint. There were a few moments where I wasn’t entirely sure how to implement something correctly in Vue.js, especially around the menu layout and dynamic binding of scanned values. Instead of asking for help or noting my uncertainty in discord chat, I tried to figure it out myself and ended up wasting valuable time.

How It Could Have Helped This Sprint:
Had I truly embraced this pattern earlier, I would have flagged those areas where I felt unsure and asked for input from my teammates or professor. This could have saved me hours of trial and error and allowed me to refocus on other key tasks. Going forward, I want to normalize being transparent about what I don’t know so I can get help sooner and grow faster.

From the blog CS@Worcester – Software Dev Capstone by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.