Implementing the Low Stock Alert System – Reflections from Sprint-3

During Sprint-3, I focused on building and refining a critical feature for our inventory management backend: a low stock alert system. Alongside this, I dedicated time to improving project documentation and maintaining clarity in code contributions. This sprint challenged both my technical implementation skills and my ability to communicate system behavior effectively for team collaboration.

What Was Implemented

The low stock alert system was designed to run once daily at 10 AM on weekdays, checking if any products in categorized_database.json had dropped below their respective minimum stock threshold. If a product was low, an email alert was automatically triggered using nodemailer and Gmail’s SMTP service.

To ensure this didn’t overload the system, I used a time-gated setInterval() inside index.js that only allowed email triggers if the day was between Monday and Friday and the hour equaled 10. The function checkAndSendLowStockAlert() in stockAlert.js handled the core logic and email composition.

Documentation Work

I also spent significant time documenting:

  • Purpose and responsibilities of the new stockAlert.js module.
  • Integration lines in stockAlert.js showing how and when the alert system executes.
  • Comments in code explaining each logic block.
  • A issue description called Low stock product alert covering everything from cron-like scheduling logic to pending Gmail credentials that require updates for the system to function securely.

GitLab Activity Highlights

What Worked Well

  • Modularization: Separating the alert system logic from index.js into its own file (stockAlert.js) helped maintain clean code structure and made debugging much easier.
  • Scheduled execution: Implementing a weekday/time condition made the feature realistic for workplace use and prevented unnecessary system loads.
  • Collaborative Documentation: Keeping a running commentary in GitLab merge requests helped the team understand changes quickly and facilitated smooth peer reviews.

What Didn’t Work Well

  • Gmail integration required an app password and correct permissions. The first few test runs failed due to missing or incorrect credentials.
  • Initial testing limitations: Since the alert only triggers once per day at 10 AM, simulating scenarios for rapid testing was a challenge.
  • Delayed implementation of logging: Early iterations lacked logs or fallbacks, making failures harder to trace.
  • After talking to professor Karl, he wanted to the server to handle this, so an issue was created so it alert can be server-handled task.

What Could Be Improved as a Team

  • Create a shared .env or config file that can be used across modules instead of hardcoding emails or thresholds.
  • Develop a simulation mode to test time-bound functions instantly, especially for scheduled jobs.
  • Review and testing sessions could be more frequent and planned earlier in the sprint.

What Could Be Improved as an Individual

  • I should’ve created mock data and test harnesses sooner to simulate alerts without waiting for specific days or times.
  • Next time, I’ll also write unit tests for alert logic to ensure that key conditions are evaluated correctly.
  • I should’ve been quicker to document issues with the Gmail setup and create a checklist for anyone running the alert system in another environment.

Apprenticeship Pattern: “Breakable Toys” (Chapter 3)

Summary: The “Breakable Toys” pattern encourages developers to build small, personal projects that simulate real-world systems, allowing them to make mistakes safely and learn without real consequences.

Why I Chose It: This pattern resonated deeply with my experience during the sprint. The low stock alert feature was like a small “toy system” that had the same structure as production-level alert systems (scheduled jobs, email APIs, condition checks) but existed in a controlled environment.

Relevance: During this sprint, I often wished for a sandboxed copy of our inventory system just to run quick iterations. The constraints of the main codebase slowed experimentation. Had I consciously embraced the “Breakable Toys” mindset earlier, I could have built a parallel mini-system that isolated alert logic and Gmail testing—speeding up development and reducing risk.

How It Would’ve Helped: Reading this pattern in advance would have prompted me to:

  • Clone and strip down the inventory codebase into a test script.
  • Avoid introducing bugs into the primary system.
  • Feel more confident experimenting with cron-style scheduling and async email logic.

Low Stock Alert System

From the blog cs@worcester – A Journey through CS by mgl1990 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

During the third and final Sprint of this semester, me and my partner Hiercine basically did exactly what we did during the last Sprint. We continued to work on modifying the endpoints within the guestinfosystem backend in order to accept access tokens that will let the system know if the request comes from someone who is authorized to make that request. Since we worked on the same task and just made some more progress, I’ll explain the code that we came up with.

The main issue that Hiercine and I had during this Sprint was having to depend on another team. On the last day of class, we checked in with the professor and the other team still hadn’t finished their code so we weren’t able to proceed. We had to leave our code as a merge request draft for someone else to work on in a future semester, leaving a blank spot for the other team’s code to get inserted.

While we did have a major issue that prevented us from being able to fully complete our work, I think Hiercine and I did a great job finishing what we could. We made sure to communicate the situation with each other, the rest of our team, and the professor. We also made sure to research more into keycloak to figure out how to use it since that’s what the other group was using. As a team, I think we did a great job and don’t think that there is much we could have improved upon.

A pattern from the Apprenticeship Patterns book that is relevant to my experience during this Spring is the “Use the Source” pattern. This pattern focuses on the importance of digging into the actual source code when you’re trying to understand how something works instead of relying on secondhand documentation, assumptions, or waiting for explanations. I selected this pattern because of how Hiercine and I looked at the group’s code and did our own research on keycloak instead of asking the other team to explain it to us, since that didn’t go well last time. The “Use the Source” pattern encourages this behavior, allowing you to understand it yourself.

Here is the checkAuthorization endpoint we created (with line numbers):

  1. /*const axios = require(‘axios’);
  3. async function checkAuthorization(request, requiredRole) {
  4. try {
  5. //Assuming the user’s role is stored in a token (e•g-, JWT in headers)
  6. const userToken = request. headers.authorization;
  8. if (!userToken) {
  10. return false; // No token, unauthorized
  11. }
  13. // Make a request to the authentication service to verify the role
  14. const authResponse = await axios.get (“https://your-aut api.com/verifyRole”, {
  15. headers: { Authorization: userToken }
  16. });
  18. const userRole = authResponse.data.role; // Assuming the API returns { role: “pantrystaff” )
  19. return userRole == “PantryStaff” || userRole == “PantryAdmin”|| userRole == “SpecificUser”; //SpecificUser == UUID
  20. }
  22. catch (error) {
  23. console.error (“Authorization check failed:”, error);
  24. return false;}
  25. }
  26. module. exports = checkAuthorization;*/

Here is an explanation of what each section of the code does:

Line 1: Imports the Axios Library for HTTP requests.
Lines 3-6: Starts a try block to handle errors while extracting the Authorization token from the request headers.
Lines 8-10: Check to see if the token is missing, returns false to deny access if there isn’t one.
Lines 13-16: Sends a GET request to the external authorization service using the token in the header to validate the user. This is what the other group would provide.
Lines 18-20: Extracts the user’s role from the response and checks if it matches one of the roles.
Lines 22-26: Logs any errors and returns false, as well as an export statement to make the function reusable in other files.

Here is a link to the merge request draft: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/118

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

Sprint #3: Retrospective

Gitlab Deliverables:

With Sprint #3 being the last chance to make substantial progress towards the project, there was an inherent pressure to go above and beyond. Our team’s first step towards reaching this goal was finally, after these three sprints, achieving success in testing the GuestInfoSystem online. Before this sprint, we struggled to find what caused conflicts between the backend and frontend. A joint effort with our team adding a missing network in the Docker-Compose file, and the GuestInfoSystem team removing a problematic variable, we were finally able to have the GuestInfoSystem respond. Now our team can add new users and track their information within the volume. Without the cross-team collaboration, we may not have been able to correct this issue. On the wave of success we had with implementing GuestInfoSystem, our team began to look to integrate other services within Thea’s Pantry. As much as I wanted to continue pushing forward, I was a bit too weary of the end of the sprint coming ever closer. I grew more concerned that our team would continue to see new tasks that we could not complete this semester. Reflecting back, I wish I weren’t as concerned with leaving ‘loose ends’ for the incoming team, as perhaps I could’ve been more effective in helping my team with their new developments. To mitigate this concern, we created two new files. One was the onboarding documentation, which was written by me, and the other was an experimental Docker-Compose file, which was to be explicitly stored separately from the latest working version. This was an effective way of addressing ‘loose ends’, as the onboarding documentation covers content that can be found in the ‘stable’ docker-compose file, while new developments can be found and tested using the experimental docker-compose file. Throughout this entire sprint, our team was working to our best abilities, therefore I don’t have any critiques or feedback at this point. It was very interesting to see our methods and approaches to problems change throughout each sprint. For example, we always kept a very open discussion about our progress with the GuestInfo team. Over the three sprints, this discussion eventually evolved into directly collaborating in their development to see the changes we wanted in server deployment. Our team was dedicated to evolving our work, and if we were given another sprint, I’m sure there would be even more room for improvement.

A design pattern this sprint spoke to one of my internal conflicts: ‘breakable toys.’ Once we had the GuestInfoSystem running, it did not feel real. My first reaction was to be very gentle with the service or any future development, as it could jeopardize our working version. We spent so much time reaching this point that I shut down any threat of instability. This carried on for a day, until the next class, where I allowed myself to let go of the stability. In reality, no more progress could be made if I kept being cautious about making any changes. Here, the idea of breakable toys would help enrich my understanding. Now that we had a working model, it was up to our group to try new things, see what breaks, and learn from it. Our workspace has now become our sandbox. We could try to implement new functionality, such as adding new services from Thea’s Pantry, and see how the server responds. One important takeaway from this sandbox was learning that my endpoints, specified by the reverse proxy, didn’t work and needed to be researched further. By breaking the service we spent so long trying to build, our team was able to find new goals to set our minds to. Most importantly, treating the server as a breakable toy has taught me to let things change. Changes we push forward may break the functionality of the service, but that doesn’t mean it will always be broken from that point onwards. I now allow changes to occur, expected behaviors to break, and to learn from those lessons during that downtime.

-AG

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

Sprint 3 Retrospective: Closing the Chapter

I never imagined we’d make it to the end of this project. At the start of the semester, I was nervous about working with new people and uncertain about the project I was assigned. Throughout this journey, I’ve learned a great deal about the importance of team building, communication, and the process of learning new things. Now, looking back, I’m proud of everything we’ve accomplished together.

During Sprint 3, what worked well for my team and me was that we had already achieved most of our core goals in Sprint 2. This allowed us to shift focus toward refining the application by cleaning up code, improving the UI, and enhancing some backend features. My front-end partner and I revisited unresolved issues from earlier sprints, including:

  • Issue 13: Get the website running, not just a local server – We attempted deployment but weren’t able to get the site running beyond local environments.
  • Issue 14: Fix rear-facing camera – We worked on improving the camera view, but the issue remains unresolved.
  • Issue 22: Add a table for the database page – We successfully added a new page that displays scanned items in a structured table format. We also added buttons to navigate easily into the scanner page and index page.

What Didn’t Work

Despite our efforts, we were unable to deploy the web app to a live server or fully resolve the rear-facing camera bug. These remaining issues were thoroughly documented in GitLab so future teams can continue from where we left off. Our team could have also benefited from clearer and more consistent communication. There were moments when some members weren’t fully aware of our status or progress, which led to minor delays and misalignments. This is understandable, as everyone was juggling multiple responsibilities and deadlines toward the end of the semester.

Team & Individual Reflections

As a team, we met our main objectives, but better communication and consistent updates would have improved our overall workflow. Individually, I could’ve contributed more by keeping the GitLab issue board better organized. This would’ve helped not only our team but also future contributors understand what was done and what still needed attention.

Apprenticeship Pattern: Record What You Learn

The pattern I chose for this sprint is Record What You Learn. This pattern emphasizes the importance of documenting lessons, progress, and experiences throughout a project whether in a journal, blog, or project management tool. I chose this pattern because there were moments when I couldn’t remember if we had already tried certain approaches or fixes. Having a clear record in GitLab helped us revisit past attempts and stay organized.

This pattern also reminded me how important it is to consistently use and update our issue board not just for tracking tasks, but also as a learning tool. If I had read and followed this pattern from the beginning, I would have been more intentional about journaling progress and decisions after each sprint. Moving forward, I plan to apply this pattern to future projects by maintaining both personal notes and team-wide documentation.

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

Sprint 3 Retrospective

For this last sprint, I myself focused on the Reporting Data Transfer project within the Reporting System part of the system. Following from last Sprint, I continued to work on the process that would take guest information data and take it from RabbitMQ and insert it into the mongo database (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/96).

However, for this Sprint after discussion the project architecture and planning out a better way that would be able to work around the limitations that presented when trying to code the same functionality in the backend, I started a new and separate project that would only run this data transfer. I first set up the project with all the files that the other projects had and the new files that it would need, including the RabbitMQ files that were simply copied over to the new project. From there, the structure also changed in placing files in the testing directory to better set up for the testing of the system. From there, I went about making sure that everything was working and in the place it needed to go, installing dependencies, and restructuring the docker files to have everything launch correctly. This is where I had a few issues.
The interaction of many different and new systems led to, again, a lot of roadblocks that stopped progress. I wanted to avoid this from the last Sprint but again my unfamiliarity with how to debug without that debugging being isolated to one place and instead spanning multiple systems without clear error messages. Even so, every problem I ran into I feel at least let me learn more about the system and just get more experience with working on multiple systems.

With how topics were assigned, we didn’t work too much as a full team other than coordinating progress and progress meetings, but instead were kind of paired off into two people working on the front end and two on the backend. I worked well with Griffin, as we were both working on creating the testing framework for our separate functions and we were able to answer each other’s questions. By delegating issues to each person, we ended up doing this a fair amount. While I think that this method did allow us to develop across the whole project, as there was not much starting code there, and have improved functionality for multiple different tasks, it diminished the amount of group work we could do. After working on this project for a semester now and looking back, I can see that in some places I definitely could have benefitted from having someone work directly with me to discuss with and work through problems together and lean on each other’s knowledge, but at the same time it is a trade off as our efforts would be focused on less tasks overall but farther for a single task we chose to work on.

As for the apprenticeship pattern that most applied to this sprint, I would say the third pattern, the long road. While the book uses the context of getting a prestigious or well-paying job, I think it relates to working on this project in class as well. Reflecting on the class and the project itself, I feel like I had tunnel vision trying to just get the issues done as much as possible and without prompting from the class material, feeling like the end state of the project was the main determining factor of the final grade. Looking back now at the syllabus and grading scheme, I realized that the focus of the class was more around working in the environment of a group coding project where you yourself don’t see the whole project all the way through, but are able to come in, understand the code, and be able to improve it when you are done, instead of having a fixed goal such as, “the project needs to work and be fully functional at the end of sprint three.” That still would have been nice, but I think that with how many different types of coding and computer science jobs there are, my experience working in this way will be more important when in a job than any specific solution that I came across.

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

Sprint 3 Retrospective

During Sprint Three, my main focus was on restructuring the frontend. While two teammates continued working on the data transfer subproject and reporting logic, I worked with another teammate on getting the frontend functional. Since we shifted our focus away from the database issue in sprint two, we have made more progress on our issues and had more achievable goals.

Before restructuring, I spent some time debugging the frontend/backend connection, which we thought was a blocker for my teammate. I tested switching the backend Docker image from the main branch to our latest reportingAPI branch, but ran into further issues. I felt we should resolve the pipeline issues and update the frontend structure before troubleshooting the connection issue, especially since it was not a blocker for UI development. I created a new branch from an earlier commit and fixed a CSpell error in the pipeline before focusing on the frontend.

The main blocker at the start was that the frontend was outdated. It used an older file structure and lacked Vite, which did not align with the other projects, like guestinfofrontend. My teammate had trouble developing the frontend UI because it was outdated and could not preview the changes. To help him with the UI, I began restructuring the frontend and set up the development and preview environments. Before restructuring, I confirmed that Vue 3 and Vite would work so my teammate could preview his changes to the UI live. Once that was done, I started working on frontend-dev-up and frontend-prod-up scripts, ensuring they worked properly. When setting up Vite, I had used the newest version, which caused some compatibility issues. I downgraded Vite so it would work with node:14 Alpine used in the other projects.

Despite the frontend/backend connection not being fixed yet, we were able to update the frontend’s file structure, set up Vite, and develop the new UI.

Our decision to move the data transfer to a new subproject allowed us to have more achievable goals for sprint three. My teammate and I communicated consistently and collaborated effectively on the front end. Using the guestinfofrontend structure as a reference made the process much smoother.

I believe too much time was spent on the frontend/backend connection issue during sprint two and at the start of sprint three. It was not a blocker for the issues we were working on, and we could have started earlier on the frontend restructure. Also, I understood less of the progress made outside the frontend changes with my teammate, so there could have been better communication between us on the other issues.

I should have been more careful when implementing Vite and Vue 3 for my teammate. In a rush to get the development and preview running, I neglected to check on the versions used in guestinfo to see if they match. Although it was not a big issue to switch to an older version, it added more time that could have been used elsewhere.

I chose the “Use the source” pattern, which discusses the importance of reading and understanding existing code to gain knowledge and improve skills. During Sprint Three, I had to examine and understand the guestinfofrontend so I could update the file structure in the reporting frontend. I was able to use the existing code as a guide for setting up Vite and restructuring the project, deepening my understanding of the frontend as a whole.

Gitlab Commits:

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

  • Reverted to an earlier commit on a new branch and fixed the CSpell error before focusing on the frontend.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/commit/db74190e17b0f4078c3f7030126cfde805814824

  • Set up Vite for UI development and preview.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/commit/b42c2d567e67e11ceb3c7d431ed22116baf70613

  • Reorganized file structure to match guestinfofrontend and fixed compatibility issues.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/commit/fe54704c381fabb3b1012361663eb9b4f8bbc7d9

  • Small pathing fix.

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

Reflections on Testing Endpoints and Growing Through Practice

Merge Request #70: Added unit and integration tests for CheckInventory and UpdateInventory using Mocha, Chai, and Chai-HTTP.

Sprint-3 marked the final stage of our project, and my main task was implementing unit and integration tests for the CheckInventory and UpdateInventory endpoints. I had previously written the code for both endpoints, so I was already familiar with how they were supposed to work. That understanding made writing the tests conceptually easy, as I didn’t need to spend time figuring out what the endpoints should do. I knew the expected behaviors and edge cases, which helped guide the testing process and made the test coverage meaningful.

Where I ran into difficulty was not with the logic itself, but with the testing tools specifically, using Mocha, Chai, and Chai-HTTP together. Setting up a testing environment using these tools was trickier than expected. I struggled with managing asynchronous behavior, handling server start/stop during tests, and writing assertions that worked reliably. These challenges weren’t about writing poor logic they were about not being familiar enough with the tools to use them efficiently. That lack of familiarity cost me a lot of time and caused some frustration as I repeatedly debugged problems that had more to do with tool configuration than with the quality of my code.

Looking back, I think one clear improvement for future teams would be to include a basic test template and some documentation in the repository for setting up and using the test tools. Even a single working example using Chai-HTTP would have gone a long way in making the setup easier. That kind of shared resource would reduce the learning curve for everyone and ensure more consistent testing practices across the team.

On a personal level, this sprint reinforced how important it is to practice with tools before relying on them in a real development environment. Even though I knew exactly what needed to be tested, I wasn’t confident with Mocha or Chai. If I had taken the time earlier in the project to experiment with those tools in a small, isolated sandbox, I would have been much more effective during this sprint. That early practice would have prevented many of the delays I encountered and made the testing process smoother and more productive.

The apprenticeship pattern that best fits my experience during this sprint is Practice, Practice, Practice. This pattern emphasizes the importance of repeated, focused practice in low-risk environments. It’s not just about learning something once it’s about practicing it enough that it becomes second nature. That’s exactly what I missed with Mocha and Chai. I hadn’t used them enough beforehand, and it showed. If I had internalized this pattern earlier, I would have taken time before the sprint to build a few quick test cases from scratch, just to become more comfortable with the tools. That effort would have paid off by giving me the fluency to move faster and avoid common mistakes.

Sprint-3 was a good close to the project. It reinforced that understanding the code is only half the challenge being effective also means knowing your tools. With deliberate practice, I could have made this sprint more efficient and less frustrating. That’s a lesson I’ll carry into future projects.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective Blog Post

Sprint 3 has been an insightful experience filled with both achievements and challenges. This sprint primarily involved working on backend functionality for Thea’s Pantry IAM system within the LibreFoodPantry initiative. One of my key contributions was addressing Issue #3, which required analyzing authentication workflows, improving data handling, and refining API integrations. Throughout this sprint, I learned valuable lessons about balancing functionality with efficiency, while also adapting my approach to problem-solving.

One of the aspects that worked particularly well was team collaboration. Engaging in technical discussions with peers helped clarify complex issues and streamlined our workflow. GitLab was an essential tool in maintaining transparency about project tasks, allowing everyone to track contributions and progress effectively. Another highlight of this sprint was the feedback loop—code reviews and discussions allowed for refinement in implementation, ultimately leading to higher-quality results. These collaborative efforts reinforced the importance of communication and collective learning in a development environment.

However, there were also several challenges that surfaced throughout the sprint. Unexpected dependency issues caused delays in backend development, requiring troubleshooting and adjustments. Additionally, occasional miscommunications led to minor confusion regarding task ownership. While these issues did not significantly disrupt progress, they highlighted the need for clearer delegation and proactive communication. Another obstacle was testing coverage. We faced last-minute debugging challenges, which could have been avoided with stronger automated testing earlier in the sprint. These setbacks underscored the importance of planning ahead and maintaining consistent testing practices.

Moving forward, there are key improvements that both the team and I can implement to enhance future sprints. On the team level, establishing clearer communication protocols would prevent misunderstandings in task delegation. Additionally, conducting early dependency assessments could help identify potential roadblocks before they impact development. Strengthening our testing strategy will also be crucial to reducing last-minute debugging and ensuring stable releases. On an individual level, I plan to work on better time management, which would help me balance workload efficiently and reduce stress toward the sprint’s end. Furthermore, improving my understanding of authentication systems would allow me to contribute more effectively to similar backend tasks in future sprints. Finally, I aim to be more proactive in seeking clarification when encountering uncertainty rather than hesitating and losing valuable development time.

The apprenticeship pattern that resonated most with my experience during this sprint was “Craft Over Art” from Apprenticeship Patterns. This pattern highlights the importance of focusing on practical craftsmanship over aesthetic perfection when developing software. It suggests that while writing clean, elegant code is valuable, the priority should always be delivering functional and maintainable solutions. I selected this pattern because, during Sprint 3, I found myself spending extra time refining and perfecting small details in the authentication backend instead of prioritizing full functionality first. While striving for quality is important, I realized that over-focusing on perfection can sometimes detract from the broader project goals.

Had I embraced this pattern earlier, I would have directed my attention toward building a reliable and functional authentication system first rather than obsessing over fine-tuning minor details. This approach would have allowed for more efficient contributions to Issue #3, as I would have spent less time on unnecessary refinements and more time ensuring the overall integrity of the backend system. Looking ahead, I aim to apply this mindset by focusing on practical, maintainable solutions while reserving optimization and refinements for when they genuinely add value.

Overall, Sprint 3 has provided meaningful learning experiences that will shape my approach in future development work. The blend of successes and setbacks underscored the importance of adaptability, teamwork, and continuous improvement. Moving forward, I plan to apply these insights to future sprints, strengthening both my technical skills and collaborative contributions.

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

Sprint 3 Retrospective

I’d say that this sprint was as successful as the last. Communication, effort, work, progress, collaboration, and planning were all present this sprint. Compared to last sprint, we all had our own sections and could focus solely on those sections due to the workload being more tedious rather than difficult. Our Sprint 3 goal was concrete and we made good progress but unfortunately, did not achieve it fully. We did, however, plan and map out where our work can go and where it can be improved for future semesters or for future work.

As said previously, we did not fully achieve our Sprint 3 goal as there was a bit more work than we anticipated to achieve a clean repository and fully implement and integrate our IAMSystem into Thea’s Pantry. In my opinion, communication and effort did taper off towards the end of the sprint likely due to it being the end of the semester as well as college for most of us. Sprints also felt as though they became shorter and shorter, simply flying by and not letting us achieve everything we wanted to achieve.

To improve as a team, I think more planning could have been done to have a better idea of what issues and tasks might show up towards the end of the sprint. Communicating our concerns with the professor, asking for another perspective on our planning and issues.

I certainly felt the end of the semester and sprint coming so I definitely did put in less effort at times. I could have reached out to my teammates for more immediate clarification on things I was confused on and focused on working on my issues more. 

The apprenticeship pattern I felt was most relevant to my experiences was “Sustainable Motivations” from Chapter 3. This pattern states that “Working in the trenches of real-world projects is rigorous, sometimes tedious, sometimes exhausting, often frustrating, and frequently overly chaotic or constraining.” The solution to the pattern says to “Ensure that your motivations for craftsmanship will adapt and survive through the trials and tribulations of The Long Road.” I felt that this pattern accurately described my thoughts towards the end of the sprint and semester. At the end of the semester, there are finals, tests, projects, and assignments that just stack on top of one another and yet at the same time, I begin to stagnate, become lazy, and just care less about classes. It’s not a healthy look, especially for a class that has me working with others. As said earlier in this post, I put in less effort and communicated less and I feel that it was in part due to the end of the sprint and semester. I’m not sure if reading this pattern would have changed my behavior for this sprint but I’m certain that it would stick in my mind. Ensuring that my motivations will adapt and survive through trials and tribulations is difficult, especially when it comes to something that I only find some passion in, that being school.

PlantUML Diagram
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/iamsystem/documentation/-/issues/6

Doc and Slides for Presentation

https://docs.google.com/document/d/1vdtsqOBUlb6vR9Kk1nA_DyvjzlWilgOncTuN0RgqK8Y/edit?tab=t.0

https://docs.google.com/presentation/d/1bbhAUBVL1Rcj-5Xrl-NrxjolY1JN8tTfAafBbvJJyfQ/edit#slide=id.g354f193b1fb_0_37

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

Sprint 3

During Sprint 3, I focused heavily on the backend authentication logic. My main task was to modify the codebase so that it could dynamically retrieve the correct public key used for JWT validation. This step was crucial for ensuring that our system could securely verify user tokens issued by Keycloak. Instead of hardcoding a single static key, the backend now pulls the current key from Keycloak’s endpoint and matches it using the kid field found in the JWT.

This task pushed me to explore how Keycloak exposes realm-level signing keys and how JWTs are structured. It also helped me better understand public key cryptography and secure token verification.

During Sprint 3, I focused on backend authentication endpoint logic by modifying the codebase to dynamically retrieve the correct public key for JWT validation. This task was essential to ensuring our system can securely verify user tokens issued by Keycloak. It challenged my understanding of authentication flows and pushed me to dive deeper into how Keycloak exposes realm keys.

Evidence of activity

Issue: modify backend to dynamically retrieve public key

Implemented logic within checkRole.js to call getPublicKey() and extract the appropriate key using the kid field from the JWT and matching it against the list of keys returned by Keycloak.

link: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/iamsystem/fake-backend/-/issues/4

What Didn’t Work Well:
One major blocker this sprint was that the endpoint wasn’t receiving a JWT token as expected. After some investigation, I suspect the issue is related to the backend not properly communicating with Keycloak, possibly failing to redirect or authenticate correctly before reaching the protected route. This made it difficult to fully test the dynamic key retrieval logic, and the issue is still unresolved as of the end of the sprint.

What Could Be Improved as a Team:
Our team could benefit from more consistent backend–frontend integration testing and clear documentation on authentication flow. It wasn’t always obvious where the token was supposed to come from or how to manually test the endpoint without the frontend completely wired up.

What I Could Improve as an Individual:
I want to improve my ability to troubleshoot backend services in containerized environments. I lost time trying to debug the issue without logging enough information or verifying network communication with Keycloak directly. Going forward, I’ll add more temporary logs and use tools like Postman or curl to manually test endpoints early in the process.

Apprenticeship Pattern: Breakable Toys
This pattern encourages building small, throwaway projects where it’s safe to fail, experiment, and learn without pressure.

Summary: Breakable Toys is about creating personal projects that mirror real world systems but are safe to break. These projects help you explore ideas, try new technologies, and learn from mistakes without real-world consequences.
Why I Chose It: During Sprint 3, I treated parts of our backend authentication system like a breakable toy. Since I wasn’t sure how Keycloak integration would work, I built a small test route to experiment with JWT decoding and key matching before applying the logic to the real project.
Behavior Change: This mindset helped me be less afraid to experiment. I now approach new problems by first building a quick, isolated version just to understand how things work, which makes me more confident when implementing the final solution.

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