Sprint Three Retrospective

Sprint 3 was productive for us in terms of development and in terms of cleaning things up, fixing loose ends, and getting ready for handoff. We finally got the reverse proxy fully working, made systems were able to be tested, and ensured that all the networking made sense inside the server. Also, we focused on making everything more organized by cleaning up our server environment, updating documentation, and going through our GitLab to get rid of clutter and make sure issues actually reflected what still needed doing. We cleaned out folders and containers that weren’t being used anymore and made sure any remaining ones were configured properly. This made things a lot easier to understand and reduced confusion when getting ready to present.

We also spent time updating our GitLab Issue Board. We closed out what was done, split up a few vague issues, and added new ones based on what we’d learned from previous sprints. That made planning less difficult, too. We also worked with another team to agree on a stable image that both sides could use without breaking things. It ended up working out perfectly and kept things moving forward. Once the guestinfosystem was implemented on the server (backend and frontend), we started working with the inventory system. To do this we generated a single docker compose file to pull all necessary images at once. Getting into a new feature felt like a win, especially after spending a figuring out the backend. And toward the end of the sprint, we started pulling our final presentation together. That helped us look back at everything we’ve completed and organize our thoughts so we were able to end the semester with something we could present to the class. What worked well was how much smoother things felt overall. Earlier sprints had a lot of research, trial and error, and  jumping between tasks. This time, we had clearer priorities. As a team, we knew what work needed to be completed and ensured we met our deadlines.

This sprint really aligns for me with the Apprenticeship Pattern discussing Concrete Skills. It’s about having practical experience with the tools you’re expected to use and actually being able to do something with them. The pattern explains that it’s easier for people to trust that you’re ready to contribute if you’ve already proven you can handle the basics. That hit home for me because some of the issues we faced caused a lot of time lost, but if we were more familiar with the tools it may have been more obvious. I had a general idea, but I hadn’t actually done it in a similar setup before, so it took longer and probably caused more confusion than it needed to. If I’d already practiced with a few tutorial examples or looked into those configs earlier, I would’ve been in a much better spot to make progress. Overall, the sprint proved to be successful and we have learned so much along the way. Sprint 3 was productive in a different way than previous sprints. I am glad we are starting to see the whole picture come together.

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

Sprint 3 Retrospective

The main issue that I worked on this sprint was the implementation of UUID as well as the use of bcrypt encryption algorithms to hash and store it in the database. This issue required me to rework most of the codebase: api, endpoints, CRUD functionality, and tests. There is still one test that I wasn’t able to pass, not 100% sure why. – https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/commit/cab7ee9496f3b0ec7f895153869de9fb6ded7def

Compared to the previous sprint, this sprint went a lot smoother and the team as able to finish their tasks/issues to an extent. Unfortunately, we weren’t able to fully implement features like role checking and accessing UUID from Keycloak tokens, due to these tasks depending on another team’s completion of implementing Keycloak. Nevertheless, as the semester was coming to an end, the team felt stronger due to better communication and everyone was determined to not only finish their task but also help one another if they required it. Some areas that the team could improve on was better communication with other teams. Since the role checking task was dependent on another team, it required us to have consistent communication, which we lacked. As a scrum master, I could have improved with pushing for more communication between the teams, especially when there seemed to be frustrations. Overall, as a team we did well in effectively presenting our semesters work and suggesting future work for future semesters. I personally enjoyed working with the Thea’s Pantry codebase because it gave me experience with full-stack development and allowed me to explore new concepts like proxies and data encryption. Additionally, this project allowed me to gain experience with valuable frameworks and tools like Vue.js, MongoDB, RabbitMQ, and Mocha Chai. After working with both frontend and backend, I can confidently say that I prefer backend development more than frontend.

If I had to choose just one Apprenticeship Pattern, it would be “Share What You Learn”. This habit says to routinely share something you’ve learned, whether that be on a blog or amongst your friends. To quote, “Being part of a community of individuals where both learning on your own and humbly sharing that newly acquired knowledge are valued is one of the most powerful aspects of apprenticeship”. Fostering an environment where you’re eager to learn is essential in the tech industry that’s constantly evolving. It enables you to change your perspective about learning as a whole; viewing it as an opportunity to grow. Because I was working outside my comfort-zone, I often found myself sharing what I was working and things I was learning with my teammates. I especially shared when I was encountering errors with my docker compose or the repository because it allowed us to think about why there were errors and helped my teammates avoid having the same problems. If I had read the pattern before the sprint, I would have likely shared more because it not only allows you to reflect on what you’ve learned but also makes your team more knowledgeable, even if they themselves haven’t learned/experienced it first-hand.

From the blog CS@Worcester – Computer Science Through a Senior by Winston Luu and used with permission of the author. All other rights reserved by the author.

Sprint 3

Sprint 3 served as a continuation and deepening of the progress made in Sprint 2, with a clearer focus on finalizing core system transitions and significantly improving communication within our team. While Sprint 2 did not meet all of our productivity goals, it provided valuable insight into our workflow and highlighted areas for improvement. Those lessons helped us enter Sprint 3 better prepared, with more defined objectives and a more collaborative mindset.

In this sprint, we concentrated on three primary technical tasks. First, we transitioned the identification system from WSUID to UUID, which is a major improvement in terms of data consistency and security. Second, we continued modifying the backend endpoints to verify user authorization based on roles by utilizing access tokens. Third, we enhanced the RabbitMQ messaging system by adding a message block that includes the operation date, operation type, and guest object information. This change improves both tracking and reporting for system activities, which is essential for reporting purposes.

Work was divided evenly among team members, continuing our strength in distributing tasks effectively based on each person’s strengths and areas of focus. Sean and Hiercine worked closely together on refining backend logic, ensuring that endpoints were properly validating access tokens and enforcing functionality restrictions based on user roles. Lynn and Winston concentrated on updating every relevant system component to remove WSUID references and replace them with UUIDs, improving data security and system reliability. I focused on extending the RabbitMQ functionality, implementing the logic needed to include operation data in each message, which adds valuable structure to the reports

One of our ongoing strengths, which became even more evident during this sprint, was our collaboration. Despite having distinct tasks, we consistently looked for ways to assist one another. Whether it was through peer code reviews, giving advice, or helping debug issues, we embraced a team-oriented mindset. This aligns with the “Rubbing Elbows” pattern as working in close proximity and staying connected to one another’s progress. This type of collaboration helped us move faster, avoid duplicated effort, and maintain a shared understanding of the system as a whole.

However, we did face some obstacles. Certain tasks took longer than expected due to knowledge gaps, particularly as we learned to implement unfamiliar technologies. Additionally, our progress was partially blocked by dependencies on another team. We had to wait for them to finish implementing their check-role functionality, which was necessary for Sean and Hiercine’s role validation work and for me to complete the RabbitMQ enhancements. This highlighted the importance of coordination in multi-team environments.

Despite these delays, we remained in a strong position to complete the project successfully. If anything, Sprint 3 revealed the importance of proactive communication both within our own team and with external stakeholders like our professor or other teams. Increasing updates internally and with the professor might have reduced these blocks.

Overall, Sprint 3 reflected meaningful progress not just in terms of deliverables but also in our development as a team. We grew more confident, more skilled, and more collaborative, all of which are essential traits we’ll carry with us into our future work in the tech industry.

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective Blog Post

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-category-based/backend/-/commit/3ae85c192e180983dcf961f20dcf16f085ddab26 :
[Merge branch ‘database’ into ‘main’] – This was a review by me of Marlon’s work which was focused on getting the pipeline on the backend up and running.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-category-based/backend/-/commit/202fc47311dc73df775d7f03b9994fcedb25eb46 :
[Merge branch ’15-yamlint-error-fix’ into ‘main’] – This branch had some tweaks to the pipeline as well as changes to the yaml files so that they were properly formatted for the pipeline.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-category-based/backend/-/commit/8cd54420550699a154d7e7c1d5fb662990d80a14 :
[Merge branch ‘fix-entrypoint’ into ‘main’] – This branch modified the endpoint files, the index.js entrypoint, and the inventory object, adding a new UPC code check, changing the default inDatabase check to use the name of a category, as well as some other functionality.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-category-based/backend/-/commit/24b16f138e0fcb22c04dcc99f73973a64bb1cd6d :
[Merge branch ‘opanapi’ into ‘main’] – This branch modified the openapi.yaml file link so that the server could read in the schema for the API and added a rabbitMQ message send on createCategory.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-category-based/frontend/-/commit/77f74b81324ad09e69f1815c14e95cc3698dcf32 :
[Merge branch ’12-connect-frontend-to-category-based-backend’ into ‘main’] – Says it in the title, I modified the docker-compose.yaml in the frontend to pull the image made through the backend pipeline so the frontend had a working backend.

Our communication as a team went really well this sprint. We had quite a bit more of back and forth due to the pipeline getting finished and being deployed to the frontend and also the backend image being called by the frontend. There were meeting on the weekends set up for these tasks and we were there and got the job done. I learned this sprint not to just trust the linters blindly, I spent quite a long time researching just to find out my issue was an improperly typed http header ( http:/localhost vs http://localhost ). Also learned that while the linting might fail, in our case due to the commit-message lint applying to all the branch commits and not just the last merge commits, the pipeline can still be set to continue to the testing part. This would allow an image to be built if the test passed even if the lint did not, which was contrary to how I understood the linter to work.

Throughout this sprint we had our roadblocks, but we would immediately ask the Professor whenever we needed his knowledge and expertise, but not so much that we hampered our own learning.

We did not end up implementing that “contract” idea I had and there was still some people missing from the meetings but I think this sprint those who were not at the meeting still got done the work that was expected of them. Again, we got the project done, the documentation is done, and the final presentation came out pretty well in my opinion. Is there room for improvement as a team ? Yes of course. But are those improvements able to be applied to the team ? No, the class has reached its end.

I could not access the Apprenticeship Patterns book through the host service, it has put up some paywall and I honestly do not want to make a brand new email and then a brand new account for the purpose of getting to look at this online book for 5 minutes. Instead I will say this, my experience this sprint was very different to the two sprints before. This was a “closer” sprint and the documentation step was more rigorous than I thought it would be. The stress of the “last pushes” of code was felt this time around. I have this somber feeling, I am done and did good work. Especially considering our group started with empty repositories, we did pretty damn good. But looking back I have that nagging thought, “I could have done more. I could have done this here and that there.” But as my Software QA professor said, “Good enough is good enough.”

From the blog Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective Blog

This sprint, my colleague and I focused on improving the security of our user identification process by applying the bcrypt algorithm to hash user UUIDs. This enhancement ensures that sensitive user data is protected, even if our data storage were to be compromised. Gitlab activity included integrating bcrypt hashing into the backend to hash user UUIDs using a cost factor of 10, modifying bcrypt configuration to use a fixed salt, ensuring consistent hashes across runs, and submitting final changes to incorporate one-way hashing of UUIDs into the main codebase. Collaboration was a strong point during this sprint. My teammate and I divided the responsibilities clearly: while I explored and tested the technical implementation of bcrypt, they focused on integrating the updated code into the overall architecture and ensuring compatibility with existing endpoints. The decision to use a cost factor of 10 proved ideal, it gave us a reasonable level of security without compromising performance. Our communication also worked well. We checked in frequently and held short meetings to keep each other up to speed. As a result, we were able to rapidly troubleshoot issues and make decisions quickly, like choosing to use a fixed salt instead of a randomly generated one to produce consistent UUID hashes.

One issue we ran into was a lack of documentation around the UUID hashing logic. Initially, we assumed the random salt provided by bcrypt would be fine, but after seeing inconsistent hash outputs during tests, we realized the need for a predictable result. This led to a mid-sprint pivot toward using a fixed salt. We had to backtrack, re-implement, and update our test cases, which took us some time. This could have been avoided with better planning. Additionally, we ran into some confusion around git merge conflicts when integrating our changes into the main branch. While we resolved them, it highlighted the need for more careful branch management and communication before pushing large updates. As a team, we could benefit from implementing a more structured approach to testing and reviewing security features. If we had written our unit tests alongside the feature development instead of afterward, we could have caught edge cases and salt inconsistencies earlier. Pair programming or doing short walk-throughs of each other’s code before merging would also help with smoother integration. We also realized the importance of having centralized documentation. Creating a shared sprint wiki or README update plan could help future developers (and our future selves) understand our design decisions, especially when it comes to something nuanced like hashing algorithms.

Personally, I’d like to improve on anticipating the implications of the tools I use. Initially, I took for granted that bcrypt’s built-in salting behavior was the best option without considering how it would affect UUID. Doing more research ahead of implementation or even reaching out for guidance from more experienced developers, could have saved us time. I also want to get more comfortable with conflict resolution in Git. While I understand the basics, more practice and familiarity with rebase, stash, and other tools would make collaboration smoother. In Apprenticeship Patterns, the pattern “Dig Deeper” encourages developers to go beyond surface-level understanding and truly learn the underlying mechanics of a technology. It’s about investigating not just how something works, but whyit works that way. I chose this pattern because it reflects exactly what I failed to do at the start of this sprint. When I implemented bcrypt, I understood it hashed securely, but I didn’t dig into how it used salt or how to configure it for consistent output. Had I taken the time to explore bcrypt’s inner workings, I would have realized the random salt would cause each hash to differ and planned for a fixed salt approach from the start. If I had read and applied “Dig Deeper” earlier in the sprint, I believe our implementation would have been more efficient and less prone to last-minute changes. This pattern reinforces the importance of understanding the tools we depend on.

References.

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

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

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

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.