Sprint 2 really changed the way I see collaboration. As an introvert, I used to be scared of team projects and working with others. But during this sprint, that mindset shifted completely. It turned out to be fun and rewarding to collaborate with a team where everyone was understanding, supportive, and eager to learn together. After receiving helpful feedback at the end of Sprint 1, we had a much clearer understanding of what needed to be done. In Sprint 1, we struggled a lot with confusion and having different views, but this time around, we had a shared direction that made a big difference.

Throughout Sprint 2, we faced more complex problems than before. My partner and I worked on several issues based on the feedback we received, as well as on things we identified as a team. Our main priorities were fixing the camera mirroring issue on the UPC scanner, updating the frontend’s visual identity, and adjusting the layout for mobile and tablet devices.

We successfully fixed the mirroring issue, which felt like a big win. However, aligning our frontend designs with the other teams was much more difficult than we anticipated. Initially, we had decided on a color palette, fonts, logos, and design styles that we thought represented the project well. Midway through the sprint, though, we were given Worcester State University’s Visual Identity Guidelines, and suddenly, everything we had designed had to be reworked. It was frustrating to undo what we had already built, but it taught us the importance of flexibility and communication.

Another major challenge we encountered  and that we had to push into Sprint 3, was getting our web app running on a server rather than just locally. We started working on it, but deployment turned out to be trickier than we expected.

Here’s a look at some of the issue we were working on:

• Issue 13: Get website running not just on local server – Worked on deployment strategies for moving our app beyond local environments.
• Issue 15: Fix mirroring issue on front facing camera – Solved the problem with the mirrored display when using the front-facing camera.
• Issue 16: Modify page layout for different screen sizes – Improved the page layout to make it responsive on mobile and tablet screens.
• Issue 20: Modify layout to implement WSU Visual Identity Guidelines – Updated frontend designs to match the WSU branding requirements.

Overall, I think our team worked really well together this sprint. Despite the technical obstacles, especially around connecting the frontend and backend, we stayed positive and pushed through. We were eventually able to connect both parts and present a working version of the app to the customer, which was a great feeling. As a team, one area we could improve on is making sure everyone is on the same page and updated about what the different sub-teams are working on. Sometimes there were minor moments of confusion because different people had slightly different ideas of where each group was at. It wasn’t a major issue this sprint, but better communication would definitely help prevent misunderstandings and keep us even more organized. On a personal level, I realized that learning never really stops when you’re working in the tech industry or when you’re a developer. If there’s something I want to improve on, it’s learning new concepts more quickly. Being able to pick up new ideas faster would help me feel more confident during team discussions and allow me to contribute more effectively.

 In the Apprenticeship Patterns book by Dave Hoover and Adewale Oshineye, one pattern really stood out to me this sprint: “Rubbing Elbows.” It talks about the importance of working closely with more experienced peers and teammates. Instead of trying to learn everything on your own, this pattern encourages you to learn through collaboration, by watching how others work and asking questions. I chose this pattern because it perfectly describes what changed for me. This sprint  working side-by-side with my teammate helped me learn so much faster than I could have on my own. If I had read about “Rubbing Elbows” earlier, I think I would have embraced collaboration a lot sooner instead of seeing it as something intimidating. It would have reminded me that it’s okay and even expected  to learn through other people, not just through personal effort.

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

During Sprint Two, my main task was troubleshooting an issue with sending data to MongoDB and its connection within Docker. Initially, a teammate had trouble sending the fake data from RabbitMQ to MongoDB. The data was reaching the RabbitMQ queue, but there were problems with the consumer. I suggested that we seed fake data directly into the database so we could work on calculating totals and building the report. When working on that, it soon became clear that the issue was not the consumer but the connection to MongoDB itself. Even with the database running and showing access to an empty database on the browser, we could not add the fake data from the queue. Further attempts to connect to the database did not work. At the end of the sprint, we decided to split the data transfer portion into another subproject for sprint three.

This was the main experience for half of the team, while the others worked on JSDoc, calculating report totals, and developing the frontend. We faced setbacks throughout the sprint but collaborated well and tackled the problem from different angles each week. Unfortunately, the troubleshooting process regarding the MongoDB connection bore no fruit. We misidentified the problem early on, which took some time, but this was mostly due to our inexperience with Docker. When comparing and implementing the guestinfobackend with our backend, I grew consistently confused about what was causing the issue and believed it had something to do with using the docker container we did not understand.

Moving the data transfer portion to a different subproject seemed like the best approach. It will move us around the roadblock we hit and give us an achievable goal for sprint three. Although we could not solve the issue, I still learned a lot about MongoDB, MongoDB Compass, how to seed fake data, the docker-compose, and how Docker can complicate connections between different services.

Our team did not initially understand the extent of the problem, and in hindsight, we should have had all teammates working on the issue earlier. We assumed the roadblock would be resolved quickly, but we should have brought the rest of the team in after week two. Our communication in and out of class has been fine, but while we were stuck on the database, I believe similar roadblocks on the frontend side were being downplayed. Since we are no longer stuck on the database, I will focus on helping with the frontend during sprint three.

Individually, I need to deepen my understanding of Docker containers networking and ports. None of the attempts produced functional or testable changes, and we actively discussed what we tried each week, so it was disheartening not having anything to commit. I was scrapping entire changes and trying different approaches constantly to no avail.

The apprenticeship pattern reflecting my experience for this sprint would be “Learn How You Fail.” This pattern emphasizes analyzing the reason for your failures and not dwelling on them. Understanding what led to the failure, like incorrect conclusions, gaps in knowledge, or missed details, can turn something frustrating into a learning opportunity. I chose this pattern because the sprint was full of failed attempts. Despite researching and testing each week, we could not solve the problem. Initially, it was frustrating, but seeing it as part of the process makes more sense when stuck. Our group talked about our lack of experience in Docker, and it helped us to know what we needed to work on and that I was not the only one confused. If I had read this pattern earlier, I may have worked on the issue with less frustration and more patience.

While I did not make any commits this sprint due to the unresolved database issue, I was consistently involved in troubleshooting the MongoDB connection issue alongside my team, as shown in the weekly reports.

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

My task in Sprint 2 was to modify all endpoints to accept access tokens that will determine the system whether the request is from an authorized individual making that request. The goal is that these tokens will let the system know if the requester is authorized. But this can only happen after the IAM team figures out how the tokens will work. In this sprint, I collaborated very closely with my partner Sean Kirwin.

What was best for me in Sprint 2 was to work with Sean and continue to work on the backend. I was working on an issue that I am comfortable with again. I was also able to continue a task that was in progress from the previous sprint.

As a team, we still managed to get along. Communication from my teammates was really the best. Every individual could complain about what issues they were facing, why they were late to class or missing class, and was helpful whenever someone needed help from a teammate. Every week, my teammates were always there to offer helpful criticism, and I appreciated their help when I needed it. They also answered my questions about how to proceed with my assignment. I know that there is always room for improvement. However, I think that my team did very well in this sprint and we did not have any major issues during this sprint.

Relying on another team was somewhat challenging for me. We were not able to accomplish as much as needed because we were waiting to see how the tokens will be, as it is the IAM team’s decision to make that. Although we keep communicating with them on Discord, in my opinion, we should have sat down and spoken face-to-face or on Zoom so that we can better understand each other’s views. I sort of felt like both teams were getting a bit mixed up with each other’s arguments. The pattern I associated with from the Apprenticeship Patterns book was “Create Feedback Loops”. Here in this chapter, it highlights the importance of constant, actionable feedback in speeding up learning and improvement in the journey of an apprentice towards mastery. Feedback loops facilitate the discovery of weaknesses, confirm progress, and hone skills. They are imperative to move from apprentice to journeyman and later to master because they enable self-awareness and incremental improvement.

I chose this pattern because it is so closely related to what was happening in the sprint. Although it is stated not to move/work on tasks from the previous sprint, I managed to do so because I had the time available to complete a small mistake that was executed in sprint 1 in order to wait for feedback from the other group so that I could work on my task in sprint 2. I was able to learn the feedback from my other team members and rectify the small mistakes done during sprint 1. The “Create Feedback Loops” pattern helped me to step back, hear the feedback from my peers, and strategize on how to improve.

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

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

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.