Category Archives: CS@Worcester

Sprint 3 Retrospective The Final

Photo by Ollie Craig on Pexels.com

Debug Ducker here, now with my final Sprint retrospective for the semester. I want to not only reflect on the progress made on this sprint, but also the past sprints as well.

Initially, when starting the project, we had a different scope in mind than what was needed. Expiration dates aren’t what many think they mean. They are made by a company, there are no governing bodies that oversee expiration dates, and meant for markets to throw stuff out that isn’t fresh. So we decided to instead try to make it so that when a product is scanned, it will then display the USDA food guidelines on what to do to ensure the food is within the spoilage range. We then introduced what we had for our customer during Sprint 1, which at the time, we had the scanner system and the inventory backend. What we learn here is that the customer has an idea of what they want, while the programmers may have a different idea. The customer said that in the pantry, they remove food after 6 months, and realizing this decided to shift our development to just displaying if a product goes bad after six months, so the group worked on displaying how long a product in the inventory can go on for instead. I feel this is a great example of customer input that I learn, as they may have an idea that we can not change completely, but improve on through software, so instead of manually checking the food, they can just check in the database what products are past the six months. As a result, our final product reflects that

This last sprint was our tidying-up sprint. We just needed to tidy some code to make it cleaner and also fill out some documentation for the next group, which I was in charge of. The tidying code is where the issue lies. You see, we use a certain code as a base to work off from for smoother development. The problem is that a lot of the words and variables used are based on the previous code base, which was guest. Since this backend is meant for product, we wanted to replace every instance of guest with product so future developers won’t be confused like we were. Unfortunately, just finding and replacing all instances of guest was not going to be easy, as the problem was deeper than a few JavaScript files. It seems the issue lies deeper within the code, and it was an issue that would have taken too long to fix. I feel perhaps we could have avoided this issue at the start if we had gone out of our way to change the variable names in the beginning of the project. Though I am still not sure if that had fixed everything.

Before we end, I want to thank my team for being the best one I’ve had. I don’t think I’ll find an understanding and kind group like this even in my upcoming professional career. I’m going to graduate from college soon, a big change in my life with new responsibilities. Furthermore, I remember a pattern from the book “Apprenticeship Patterns”, by Dave Hoover and Adewale Oshineye. This book has been mentioned a lot in my retrospective, but a lot of what is said is thought-provoking. The most thought-provoking pattern to me is the Long Road. This pattern speaks about learning and growing your skills over a long period to be what is called a master software craftsman. You need to think in the long term, not short-term gains. I feel this will be important when it comes to my future in the software development field. It is going to be a long journey where I will gain new skills and abilities that will leave me unrecognizable from my previous self. Though this one will take time and an unknown amount of time that I am prepared to face. It will be a journey full of unexpected twists and turns, but it will be worth it in the end. I learned a lot from this group project and I hope to apply it in the future

Thank you for your time, Debug Ducker out.

Final results of the Backend in collaboration with me and 2 other devs

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

Final results of the frontend scanner work

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

From the blog Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

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

This is the link to sendBarcodeToBackend method that I implemented.

What Worked Well

This sprint, I focused heavily on developing a method where the the detected barcode will automatically send a GET request to the backend, establishing a form of communication from the frontend to the backend. I used the native BarcodeDetector API, which allowed me to avoid external dependencies and keep the code lightweight. The automatic fetch to the backend based on a detected barcode worked exactly as expected, and it felt satisfying to see a 200 ok status in the browser’s network tab confirming backend communication. Our Git workflow also went smoothly , I was able to create feature branches, merge through merge requests, and pass all pipeline checks without major issues.

What Didn’t Work Well

Initially, I attempted to send the barcode data to the backend using a POST request, assuming it was the right choice. However, the backend only supported a GET route, which led to a 404 error. It took some time to trace the problem, especially because no error message appeared visually in the UI. Additionally, I had trouble with Git merge conflicts after another teammate merged changes to main before mine. I had to learn how to pull the latest from main, resolve .cspell.json dictionary conflicts, and push again.

Team Improvements
As a team, we could communicate more consistently during merges. There were moments when teammates worked on overlapping files without letting others know, which resulted in Git conflicts. We can improve by checking in more frequently on Discord or maintaining a better shared task board to reduce surprises and overlapping edits.

Personal Improvements

I want to get better at anticipating backend constraints , such as which methods (GET, POST) are actually available. I also want to be more proactive about asking teammates before starting work on shared components like the router or layout. In the future, I’ll aim to do smaller commits more frequently and leave helpful comments for reviewers so my merge requests are easier to understand and approve.

Apprenticeship Pattern: “Record What You Learn”

Summary:
This pattern encourages developers to keep a personal record of lessons, mistakes, workarounds, and discoveries during their learning journey , whether in a journal, blog, or notes folder.

Why I Chose This Pattern:

During this sprint, I encountered several learning moments , like how to properly use environment variables (VITE_API_URL), how to avoid hardcoding backend URLs, and how to debug merge conflicts. These are things I could easily forget if I don’t document them. I started keeping a small dev log after reading this pattern, and it’s already helping me.

How It Would Have Helped Earlier:

If I had followed this pattern from the start, I could’ve avoided wasting time retracing my steps when I forgot how I handled similar problems earlier in the sprint. I would have written down how I fixed the fetch issue with the GET request or how I resolved markdownlint errors. That would’ve also made it easier to share knowledge with teammates during check-ins.

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.

Sprint 3 Retrospect Blog

At a certain point in life, you start to notice a pattern. Older individuals often tell you, “Don’t worry, it will be over before you notice, so try to enjoy it.” People told this to me when I started High School, and I was complaining about its hardships, and they said the same phrase again when they caught me complaining about College. I always seem to learn my lesson a little too late, but luckily this time I caught it at the right moment. This last sprint on one of my last college classes was nothing short of enjoying my time surrounded by good teammates and working on a field that I became familiar with.

In the earlier sprints, we were caught off guard by what we had to do. This sprint, however, we had a clear vision of what needed to happen. All that was left was a little push.

Our inventory system was almost done by the end of the second sprint. We needed to add some final touches. We also had to clean up the code so that it would be presentable for future teams. After taking some opinions into consideration, we decided to add a few more features to it so that it would be overall complete for use, even for certain items that were not part of the Food Data Central Database. Playing around with adding new items to the back end and creating the necessary front-end infrastructure to do so the past sprints had me equipped with enough skills and knowledge to implement this feature seamlessly and tirelessly. Adding a few new modals after the scanned UPC was not found on the FDC database was not an issue as it would be the same procedure I used in the last sprint to populate the back end with new items. What was tiring at the time was having to manually input every attribute of the new item each time it was scanned. The temporary workaround for that issue was to cache the data to the local machine memory the first time an unidentified item was scanned. By doing so, every other instance that particular UPC code would be scanned again the attribute sections would already be populated with the previous input. This, however, was a temporary solution to the problem, as it could be an issue when the Web App is used in the future. If the same application is run on a different machine, it would not recognize those items as the cached memory for that machine would be null, and if by some means the cached memory were to be cleared using developer tools we would still find ourselves with items whose attributes would need to be scanned again.

Another feature added to the project this sprint was the sorting of different attributes. A simple sorting function which sorts a populated list based on their values and letters was added to the database file. Appointing this function as an “onClick” to the attribute table could sort the population of the table in a descending or ascending order of values for integers, and prioritizes the first letter of the category and sorts them alphabetically for strings.

Last commit done to the project side branch before merging to main:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend/-/commit/9ecee33738a922be4f200ba106064a1aad6f40a6

In Apprenticeship Patterns, the “Familiar Tools” pattern emphasizes the importance of mastering your environment—whether it’s your editor, command-line interface, or even your IDE. These tools are your instruments, and just like a musician, your fluency with them can either make your job seamless or frustrating. My tool for this sprint was my familiarity with the system that we had created previously, and the basic functions I had learned on my earlier classes. As I was searching for libraries to create the sorting and this pattern reminded me to stop jumping from tool to tool but instead double down on the ones I have used the most. The end result was nothing glamorous, but it does speak for itself. Less friction and more flow.

In the end, we reached our goals, but the feeling of satisfaction continues to be bittersweet because for some of us, it was the last project before graduation. As we now go on different paths, this project will link us to the good times we had working together, and to remind us to not be sad because its over, but to be happy because it happened.

With that, I conclude this journey.

Ano, over and out.

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.

Sprint Retrospective 3

The third and final sprint of our semester was eventful and successful for our team. We made great progress on many of our major tasks. It was a relatively smooth sprint with only a few resolvable issues. Our communication was on point, and we remained entirely transparent about our goals for the sprint. The focus of this sprint was finishing the guest info system’s installation and setting up subsystems as we went forward. We successfully worked with another team to fix the formatting on the guest info system and we now have a stable build. Our team also completed port mapping, and created a table for our ports. We also have a working landing page (missing Keycloak) and the beginning of a working weight-based inventory system. We set fair and manageable goals throughout this sprint, and prepared the next teem excellently for the tasks to come. We are fully pushed to gitlab with all our important information, and we have documentation to guide future teams. I spent my time doing three major tasks; getting the guest info system working fully, researching different ways to handle multiple docker compose files, and beginning work on the weight-based inventory sub-system.

What I thought didn’t work well in the sprint was the time crunch on our issues. While we made great progress, due to the upcoming presentations and end of the class we did not finish as much as we’d have liked. We left some tasks incomplete to a minor degree, although we are proud and happy with the work we made. I would personally have liked to finish the inventory sub-system. I was unable to do that due to time constraints at the end of the semester. We were working on getting the guest info system working up until that point. 

As a team our biggest weakness is our shared lack of knowledge in the subject, requiring us to pool our brains for certain tasks. While we worked independently to a great degree in this Sprint (an improvement from the last two sprints), I feel that due to the complexity of our tasks, we did not adequately work independently where we could have. A lot of time in my opinion was lost to this communal working, although we did get farther than expected with the sprint. As an individual I could improve better at communicating my work. During team work class I am not immediately vocal with what I am working on, and although I am making progress I am not being entirely transparent with my team. Going into future work I will be more transparent with my work, having learned from this experience.

The apprenticeship pattern that best describes my work in this sprint is Walking The Long Road. I felt that this fit because of the work I was doing throughout this sprint. While I could have stopped coding and cleaned up with more clerical work, I continued to remain persistent with adding features and improving our server. This led me to research merging docker compose files and adding the inventory system, which became an excellent end-of-sprint addition. Teams in the future will benefit from this addition, as they will have an easy portion to implement into the server to get their feet wet. By remaining consistent at improving my abilities, I avoided resting on my laurels and considering the job done before it had been completed.

My tasks:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/25
This was my earliest task, involving fixing the disconnecting backend. Working with Professor Wurst and Cameron, this was completed.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/10 

This was my major task for this Sprint. I spent time making sure the guest info system was running smoothly, as well as adding new subsystems to test towards the end of the sprint. 

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

Software Development Capstone, Final Sprint Review

For my final apprenticeship pattern, I wanted to find one with a message that I could take with me into my future work with software development that would continue to help me improve after my academic career has ended, as well as even years into a professional career. Chapter 5’s Expand your Bandwidth touches on this topic, and explains how one can expand their knowledge beyond the context of what is needed in a specific project or job.

With regards to experience and knowledge, the two common pitfalls a developer can find themselves in are having only an understanding of the tools needed for their specific role, and only possessing a surface level understanding of the knowledge they have. Personally, I believe that these two problems have the same root cause; when you only concern yourself with what you need to know for your work, your knowledge stagnates and you exclude yourself from experiences that would improve your craftsmanship.

The book places emphasis on the value of the desire to go further and learn more in unique and unfamiliar ways. The common examples of attending professional development and technical conferences and events, as well as using online courses and videos about new topics, are present. However, the idea of looking through forums and mailing lists to find other people’s problems and replicating them to solve them, was a new one for me. Of course I’ve used sites like StackOverflow before, so I knew that this was something one could do, but I hadn’t realized the value it had in improving my own knowledge.

Expand your Bandwidth begins with a quote from Jim Highsmith, author of Agile Software Development Ecosystems:

“Learning about what we don’t know is often more important than doing things we already know how to do.”

A great way to summarize the value of going the extra mile to learn more, and a message I want to keep in my mind for my future in software development.

In our final sprint, I focused on the integration between the database containing the visit info and the backend code we’ve developed to generate the report. This meant refactoring the backend code to accept and parse data from RabbitMQ, as well as handling the connection itself. The connection between RabbitMQ and the backend has been causing issues, and needs further debugging work before it can be deployed.

Reflecting on the sprint as a whole, I’m not completely satisfied with my own work. The original plan had been to develop testing for the backend code during the sprint, which I spent two weeks working on before deciding the connection between the database and backend was more critical to the functionality of the project, and needed priority. Compounded with the problems that arose during development and debugging, I wasn’t able to finish the work within the duration of the sprint. I believe choosing at first to work on testing was a mistake on my part, and that poor planning contributed to not meeting the goals my team had set. However, I also believe that the work that was done on the backend code was productive and is very close to completion. For future work, I want to improve my planning and time management by allotting myself some time during the sprint planning as extra time, in case a feature or issue ends up taking longer than anticipated. This way, I will be able to afford setbacks such as those that occurred this sprint.

Link to updated most recent commit

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.

Sprint 3

During sprint 3, I kept working on the frontend, like the last sprint, I had been stuck trying to get the backend up, while trying to work on the frontend. I had a teammate work with me for this sprint to complete it. We worked on two different branches, mine and Jason’s.  Inside my branch, I was having a problem starting up the frontend through development mode, so I decided to see the original branch and work back into the updates I had made. Jason was able to start the frontend without the backend using dev. This gave me the advantage of designing the frontend and seeing what would work. Working with someone this sprint improved the sprint overall for me because last sprint, everyone else was in the backend while I was working in the frontend. My teammates were helpful, but without working with someone directly in the frontend, it was difficult to get help on exactly what I needed.  

First starting on the design, I had noticed that I had to make the banners and everything the perfect size, or it wouldn’t be eye-appealing. Small things like having the top and bottom borders being same size were important. One of my biggest problems was attempting to make sure the page could fit on one page without having to scroll, because, first, designing the front end, there would be empty white space that wasn’t needed, or having the logos be too small. But I was able to persevere and have a design that I was proud of. I also have to give credit to Byron, who posted his design, which I translated into my design. It helped in choosing what logos should be prioritized and gives the frontend a coherent design.

  For this sprint, I would choose Kindred Spirits as the pattern that most resonated with me. This pattern highlights the importance of working together and working with someone who is like-minded and is determined to learn and accomplish their goals. This is great to have in a team because it allows teammate to grow together while also accomplishing their tasks. Working with a teammate this sprint greatly affected the amount of work I was able to accomplish. I was able to complete more in a shorter amount of time given. Directly working with Jason during this sprint gave me more insight into the issues we faced and helped me grow faster and feel more supported. Before this sprint, as I mentioned, I was isolated, working on the frontend by myself. It was difficult to troubleshoot my work with others because they were working on different aspects of the project, mostly in the backend. My teammates were helpful in what they could help me with, but there was always a disconnect because I didn’t want to slow them down on their work, and they were working on the backend. Working in collaboration with Jason allowed me to exchange ideas and confirm each other’s work. It gave me more confidence to ask questions because we were working in unison on the same problem. If I had been aware of this pattern earlier, I would have gotten a partner sooner because working in isolation isn’t a deterrent to just you but to the whole team.

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

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.