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.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/merge_requests/14

This is my merge request for my finished task of writing documentation on how to implement and use nodemon for faster, more efficient development.

For Sprint 2, what worked well for me as an individual was being able to use the other pieces of documentation as a reference, and also being able to utilize Markdown’s formatting to give the documentation a clear and understandable look. I had also kept track of my process of installing nodemon with a Google Doc file, which made it immensely easier to retrace my steps and know what worked and what didn’t. Although it was my first time writing documentation, I didn’t feel lost at any points, and I was able to create a set of instructions I felt confident in and proud of.

As a team, we stayed very organized throughout the entire Sprint, keeping track of issues and merge requests as they were posted. Most merge requests were either discussed in-class or over Discord, which helped the other team members understand the changes being made. I feel like we really gelled well as a team, and morale was high, which enabled everyone to feel comfortable with bringing up issues or asking for help. Everyone has been great at completing their fair share of work, both when it comes to the project itself and the Sprint Review presentations. 

On an individual level, what didn’t work well was I felt as if I became distracted at times during class, when I could have been more focused on completing my work. This is something I am actively working on being better at. I could be a bit more productive in-class sometimes, but this is not to say I never get anything done. I also felt as if I wasn’t completely sure about how the documentation should be written, or if the instructions I wrote would be applicable to everyone. This is something I think is okay at this point, but it was a bit of a back-and-forth struggle when it came to making certain decisions.

On a team level, there was not much that did not work well. We’ve improved our communication from last Sprint, and we are getting issues done and merge requests out at a steady pace. I think something we might need to clear ourselves up on are certain issues regarding visuals, but otherwise I think we are in a good spot.

To improve as a team, we should ask either Professor Wurst, the client, or the Visual Identity Team some clarifying questions about our issues (what the visuals of the webpages are supposed to look like, for example). I think we could clean up our Issue Board a bit as well, as it seems a little cluttered with old Issues.

To improve as an individual, I should definitely try and focus a bit more during class. Productivity would increase, and hopefully I could get more done with the time we have left. I could do better in arriving to class on time, as the last couple of classes I was running late and had to search for parking for a long time. 

For this Sprint, not many of the Apprenticeship Patterns apply to me, so I’ve decided to go with “ Rubbing Elbows”. This describes a situation where one feels there are better techniques to the craft that are escaping them. This may not be exactly true, but it seems to be based on the apprentice’s experience and emotions about what they’re working on. It stems from stagnated learning, which can lead to one feeling inferior about their implementation.

I selected this pattern because while I was writing the documentation for implementing nodemon, I felt as if I was overcomplicating the whole process and that there was an easier way to accomplish the same goal. I felt that, realistically, installing nodemon shouldn’t have been too difficult, and that I was using an inferior way to implement it. It relates to my experience during this Sprint because I was feeling inadequate about my work being the “right” approach to implement nodemon.

If I had read the pattern before/during the Sprint, I would have asked another team member to work with me on installing nodemon to see if it was truly as convoluted as I was making it. The other developer might come up with a different solution, which would be a good perspective to have.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

During Sprint-2, my focus was on contributing to the tasks assigned to me through GitLab. These tasks included Issue 4 and Issue 2. Both were critical components in ensuring the functionality and reliability of the fake frontend module in the LibreFoodPantry project. As the sprint progressed, I had the opportunity to reflect on the highs, the challenges, and the lessons learned. Here’s my summary of the experience.

Evidence of Activity on GitLab

• Issue 4: Task to implement functionality improvement in the fake frontend. This required debugging and making updates to enhance module performance.
• Issue 2: Debugging and addressing existing issues with edge case scenarios in the fake frontend module.

These activities provided me with valuable experience in problem-solving and adapting to unexpected challenges, which were prevalent throughout the sprint.

What Worked Well

One of the key successes during Sprint-2 was the level of collaboration within the team. Regular communication ensured that tasks were clearly defined, and support was readily available when needed. I found that breaking down complex problems into smaller, manageable components made debugging much more efficient. Issue 2, in particular, benefited from this approach, saving considerable time and allowing me to focus on improving code reliability. Additionally, Issue 4 was completed with minimal revisions thanks to the clarity of the requirements and prior preparation.

What Didn’t Work Well

However, Sprint-2 also presented its fair share of challenges. Initially, unfamiliarity with certain aspects of the codebase slowed my progress. The intricate structure of the fake frontend module required extra time to understand before making meaningful contributions. Furthermore, testing processes revealed several edge cases that were not anticipated during planning, leading to some delays in resolving issues. These experiences underscored the importance of early preparation and thorough testing.

Changes to Improve as a Team

Reflecting on the sprint, there are several improvements the team could make to enhance our efficiency:

1. Knowledge Sharing: Organizing sessions to familiarize team members with the codebase would help reduce delays caused by a lack of understanding.
2. Proactive Testing: Incorporating more comprehensive testing during the earlier phases of the sprint could catch edge cases sooner.
3. Clearer Documentation: Providing detailed documentation of tasks and processes can ensure everyone is aligned and reduce ambiguity.

Changes to Improve as an Individual

At a personal level, I identified several areas for growth:

1. Skill Development: Spending dedicated time learning tools and frameworks used in the project would enhance my ability to tackle tasks with confidence.
2. Proactive Engagement: Being more proactive in seeking clarification when tasks feel ambiguous would help minimize initial slowdowns.
3. Time Management: Allocating focused work periods for specific tasks could improve overall productivity.

Apprenticeship Pattern Selection: “Expand Your Bandwidth”

• Summary: “Expand Your Bandwidth” is a pattern that emphasizes the importance of stepping outside one’s comfort zone to learn new tools, techniques, and frameworks. By actively seeking opportunities to grow, developers can broaden their capabilities and handle more complex challenges.
• Relevance: This pattern directly relates to my experience during Sprint-2, where unfamiliarity with parts of the codebase initially caused delays. By expanding my bandwidth through dedicated learning, I could address similar tasks more efficiently in the future.
• Impact on Behavior: If I had read this pattern before Sprint-2, I would have approached the unfamiliar codebase with a proactive mindset, dedicating time to research and practice before diving into the tasks. This preparation could have prevented the slowdowns experienced during the sprint and improved my overall contribution.

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

This sprint pushed us out of the setup phase and into the real struggles of implemenation. Our focus was on certificate configuration, domain integration, and establishing a stable server environment capable of supporting frontend and backend communication through Docker Compose. We encountered technical challenges that required a lot of trial and error, especially with NGINX, RabbitMQ, and SSL certs, but we made real progress and learned a lot along the way.

Key Work Accomplished:

• SSL Certificates: After experimenting with self-signed certs, we shifted direction and enabled Let’s Encrypt with Certbot. I verified auto-renewal functionality using a dry run, ensuring long-term reliability.
• Domain & NGINX Setup: Switching from IP to domain access opened the door for proper HTTPS handling and better routing. We spent time researching NGINX as a reverse proxy and adjusted our configuration to support this change.
• RabbitMQ Troubleshooting: I spent time debugging why connection.createChannel in messageBroker.js fails during Docker Compose builds. The issue appears tied to the container configuration or startup timing, which I plan to isolate in the next sprint.
• Documentation: Added notes and resources for Docker Compose Watch (for future CI/CD use) and contributed to team documentation related to server setup and troubleshooting steps.

This sprint tested our patience and problem-solving skills. Even when progress felt slow, I stayed focused on learning and finding answers. I also made it a point to keep the energy positive in the team, especially when the same problem stretched across multiple weeks. I think maintaining that morale helped keep us all engaged and moving forward. One area I’d like to improve is how I manage my research time. It’s easy to get stuck digging through forums or chasing edge cases, so next sprint I want to be more intentional about how I explore solutions and when to pivot. I also want to get better at helping guide conversations to a technical conclusion more efficiently during group work. My top priority going forward will be testing subsystems and verifying proper communication across containers. I also want to finalize our server hosting and make sure the front end is accessible through the domain without errors. Overall, I’m proud of our persistence. This sprint was about learning and solving problems within the systems we’re building.

Apprenticeship Patterns: The Long Road

This sprint reinforced the mindset behind Apprenticeship Pattern: The Long Road—that true growth in software development comes from persistence, patience, and a long-term commitment to learning. While troubleshooting issues like Docker container problems and RabbitMQ errors was frustrating at times, I stayed focused on understanding the root causes. Each challenge became an opportunity to learn. I’ve started recognizing that even slow progress is part of the journey to achieving the goal. This pattern will help me stay motivated and positive, even when things don’t go as expected. Moving forward, I want to manage my time better when diving into technical problems and continue building habits that support my learning and my team. There is still a lot of work to complete for our team, but I think we expect this and we will hit the ground running for the last sprint.

From the blog cameronbaron.wordpress.com by cameronbaron and used with permission of the author. All other rights reserved by the author.