Category Archives: Sprint-3

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.

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.

Third Sprint Retrospective

Recently, my team completed our third and final Sprint. In this Sprint, I focused mainly on the design on the CheckInventory frontend once again. In the last Sprint, I had updated the header and the footer of the page, so this Sprint, I updated the information display portion of the page. I looked for some inspiration, which I found at the bottom of the WSU Thea’s Pantry page, where they used a white box floating in a gray background. I thought it was a decent design so I interpreted it. I kept the initial box design, except I upsized everything, and removed the title. I put the title floating above the box, bolded and in a dark blue. I increased the size of the font inside the box, and highlighted the weight itself in red. I gave the bottom and right side of the box a small shadow, to give it the illusion of floating. Finally I made the background a soft gray, which eases the eyes a bit better compared to a white background. I created a merge request for this issue, which would allow my teammates to use the code from it and update their own frontends. The last issue I tackled was the navigation bar. Originally, it had links to go to ‘Home’, ‘Check Out’, and ‘Check Inventory.’ I had removed these links from my navbar when I added it as they did not work, but it left the bar a bit bland, and we would need it eventually, so I put back the ‘Home’, and added a ‘Add/Donate.’ I made it so that it underlines when a user hovers over them. When the page is resized, the navbar collapses in a hamburger button. A user should be able to click on this button, which could drop down the options from the navbar. The button did not work, so I spent a bit of time trying to figure it out, only to realize it took eight characters to fix, but regardless it works, and on a mobile phone view as well. I went ahead and fixed some things about it, having it so that the options drop down on the right side of the page instead of the left. The ‘toughest’ part was fixing the design of the hamburger button itself to match the rest of the page. I had to create my own hamburger button in Canva, imported it as an svg file, and then I was able to change the button. I made a merge request for this as well, which allows my teammates to take the svg file and use it on theirs too.

What worked well was communication, we were quick with answers when someone needed something, quick on reviews and merging, etc. It was something we’re always good with, which is good. What worked well for me was still working on the frontend design, again it felt more like something I wanted to do rather than work. I wanted it to look good, and so I gave it my all to make sure it would look nice. Something that didn’t work well was making good use of my time. With the issue about the hamburger button, I had researched a lot and played around with a lot of solutions to get it to work until one did.  Felt like I could’ve figured that out faster, but I didn’t.

I don’t think there’s a lot we can improve on as a team. In my last blog, I suggested a stand up to clarify what we were doing individually, but since we have solidified ourselves into certain parts of the project, we all just knew what each of us were doing. Individually, I could improve on doing more, I felt like I was not doing enough work compared to my fellow teammates. 

A pattern that I can relate to during this Sprint was ‘Read Constantly.’ It basically means although I’m learning all these new and difficult things, there are more difficult things beyond that, and I feel like I won’t be able to catch up. After researching and reading about my issues, I felt this way, not just in this Sprint, but in the previous ones as well. If I had read this pattern before, I don’t think it would’ve changed anything. I still have to read and research my things, ultimately that’s how I grow.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

MR36 | Backend functionality and design consistencies

MR38 | Thank You popup

MR39 | Visual Design Update and Hot-Reloading

MR40 | Max checkout weight set to 30 pounds

These are my merge requests for my finished tasks of connecting the backend to CheckOutGuestFrontend for actual checkout functionality and design consistencies, adding a “thank you” popup after someone checks out, updating the visual design of the frontend to be consistent with the others as well as adding hot reloading upon changes, and setting the max checkout weight to 30 pounds.

For Sprint 3, what worked well for me as an individual was working on a different part of the project, with different challenges and issues than my in the first two Sprints. These new obstacles were exciting for me, and I felt like I was able to learn a lot whilst staying engaged in my work and getting issues resolved. I felt really motivated to complete these issues because of the change of environment.

As a team, I really enjoyed working with all of my teammates and spending time with them in class. Everyone was quite welcoming and trusting of each other, which led to an amicable and fun work environment. Working together with a group of people you can be yourself with is a great experience, and can make it really easy to ask others for help or to admit your mistakes. Our team vibes being high encouraged better communication, and more interest in our work. Being honest with each other worked really well for us.

On an individual level, what didn’t work well, similar to last time, was that I could have been more productive in-class than I was. I got distracted sometimes, and possibly could have been distracting others, but I still got work done. Other than that, I think I did alright.

On a team level, we didn’t have many mishaps or things that didn’t work well. We were able to communicate our issues, what we’re working on, what we need help with, and our merge requests very clearly, and we were quite organized when it came to putting together presentations and updating our issue board. We almost always had everyone present in-class, which helped our productivity substantially.

To improve as a team, we could have done better with ensuring that everyone is on track/working on something, since we never really did the 5-minute standups at the start of each class like we said. Another good idea could have been to involve people in different aspects of the work, rather than everyone sticking to the same place for each Sprint. Giving each member a chance to explore another area of the work would help everyone become well-rounded in their knowledge of the project and in general.

To improve as an individual, I should try to focus a bit more during class, and arrive a bit earlier. I had issues towards the end of the semester with arriving a little later than usual, which hurt my productivity, and I could have missed some important things.

For this Sprint, not many of the Apprenticeship Patterns apply to me, so I’ve decided to go with “ Concrete Skills”. This describes a situation where one wants to work on a good development team, but they don’t have the practical experience. The solution provided is to upgrade your concrete skills and fundamentals, so that you can be immediately useful to the team, thus gaining trust and repertoire faster. This seems very applicable to new grads and people trying to get internships, as they lack the experience to get the job, but feel as if the job could propel their learning forward.

I selected this pattern because as I search for full-time jobs for post-graduation, I find it harder and harder to find companies willing to hire completely new-grads without any professional experience. My time in this class, and this Sprint, have been a solid emulation of a professional working environment, but I know there are many more factors that are involved in an actual company’s development team. I just feel like if I could get that first job and have a good experience, I would learn a substantial amount and feel much more confident about my place in the industry.

If I had read the pattern before/during the Sprint, it would have helped put me on a more focused path towards maintaining the fundamentals of programming, which would allow for professional teams to have more trust in me as a newcomer.

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

Sprint 3 Retrospective Blog

In Sprint 3, I did not have a specific personal task. Instead, the sprint was primarily spent working together to fix issues that were generated in Sprint 1 and completing outstanding tasks from Sprint 2. As a recap, in Sprint 1, my task was to add a new date field to the backend API to indicate when a new account was created. In Sprint 2, my task was to modify all endpoints to accept access tokens so that the system could verify whether the request was being made by an authorized user or not.

What was best for me in Sprint 3 was being able to fix bugs that were present, which gave me better insight into the general structure and functionality of the system. Better understanding of backend behavior, especially in how to apply access tokens and authorization, I gained a lot of experience in backend development. What did not work best for me was when we did a merge request, the pipeline failed because of lint comments and tests. My teammate Sean and I were so confused about why the test failed in the pipeline. The error was in an endpoint that we did not even touch when working on our tasks. This is not ideally how I wanted to end the Sprint, however, we did not have enough time to fix this issue.

In general, I believe we worked quite well together as a team. My team was effective at sprint planning and working on each team member’s task well. All members of the team were good at reporting what they had accomplished every week of the sprint. I liked that my team members were always there to provide feedback every week and also helped me when I was not sure how to go about doing my assignment. As we have come to the end of the semester, I honestly do not have much to say about my team improving. In the future, I hope that each team member continues to improve in their personal tasks in their future workplaces where they need to work in a group.

Since Sprint 3 involved less outright ownership and more integration and collaboration work, I found my experience closely relating to the “Be the Worst” pattern in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The “Be the Worst” approach tells programmers to specifically put themselves in situations where they are the least experienced or the least able member of the group. The idea is that this positioning optimizes for growth by allowing you to learn from more experienced colleagues, be challenged by high expectations, and learn good habits by watching and collaborating with others.

I chose this pattern because my experience in Sprint 3 repeated its underlying message. Rather than concentrating on completing work on new tasks, I was deeply involved in teamwork, reviewing and debugging code that I did not write, learning unfamiliar parts of the system, and completing work that demanded a broader view of the backend infrastructure. This made me consider how valuable it is to be in situations where you’re pushed to learn by being around more experienced or otherwise capable coworkers.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/118

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

Sprint 3 Retrospective

Gitlab Activity:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/addinventoryfrontend/-/merge_requests/42

This merge request was made to update the design of AddInventoryFrontend to match the design of CheckInventoryFrontend that Anthony Cao implemented. This was done to maintain consistency and use on-brand color schemes for Worcester State University and Thea’s Pantry. A navigation bar was also added to redirect to the home page, but functionality for this can be added by teams in the future.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/addinventoryfrontend/-/merge_requests/43

This merge request was made to implement a drop-down menu in AddInventoryFrontend. Instead of entering WSUID for submission, users select an option from a drop-down menu characterizing themselves; if ‘Other’ is selected, a comment is required prior to submission.

This was the last sprint of the semester so there wasn’t much that didn’t work well. The team communicated well as usual, consistent merge requests were being made across the InventorySystem – WeightBased and things progressed smoothly. As an individual, I had no issues implementing the drop-down feature in AddInventoryFrontend that the client suggested but I personally struggled with finding work towards the end of the sprint. My teammates also seemed to struggle with this. There was work to be done, but the end of the semester offered an awkward phase of trying to still get things done while not taking on a task too large that would surpass the remainder of the time in the semester. AddInventoryFrontend seemed to be at a stage where significant changes would have to be done at a later date, so I ended up assisting Guilherme Salazar Almeida Nazareth with writing tests using Mocha and Chai for InventoryBackend. He was able to wrap this up in time for our sprint demo. No changes were needed during this semester to work effectively as a team, we mostly just had to focus on finishing up strong.

The pattern I choose from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye” to describe Sprint 3 is “The Deep End.” This references the fear of taking too much on at once due to not feeling comfortable/ready to do so. The want to grow your skills or portfolio while feeling a sense of imposter syndrome is a very common thing. I think this accurately describes the end of the semester for my team because although everyone still had work to do, we feared taking on too large a task for fear of not finishing it in time. But reflecting on this, it might have been better to start a large task and give future teams a template to work with instead of not trying to develop anything larger at all. If I read this pattern at the beginning of the sprint, I probably would have put my Scrum Master title to use and encourage myself and my teammates to take on larger tasks and assure them that with proper documentation and descriptions on Gitlab, we’d actually be helping future teams with their work. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Sprint #3 Retrospective

 Hello

I cannot believe how quickly this year has come to a close. It seems like just yesterday I was struggling comprehending what I was doing in this course, but now I have gotten to the point where I feel like I have a grasp on how things are actually going. In terms of what got done, I implemented Rabbit at long last, and it only took me 3 sprints to get here! Along with that I made sure the messages we were sending matched the specifications posted on discord, and I made sure that the messages were only being sent if the requests themselves were valid (i.e. weight isn’t null, and it won’t take more than the inventory has). I think I really came into my own near the end of my time in this class,  I did a good job speaking to my group more often, I put out a number of good commits, and overall I had a better grasp on what was actually going on, which I certainly couldn’t say at the start. Though if I had to pinpoint something that didn’t work very well, I definitely think it was my communication with my group about what all of my work actually does. I get consistently asked what certain ports are being used for, and near the end of the sprint we ran into a snag relating to a library I was using. If I had explained what everything was more thoroughly, it could have prevented some headaches in my opinion. Our team continues to work quite well together, we communicate pretty openly at meetings, and I am not afraid to ask questions like I was before. I think near the end of the sprint we kind of lost focus a bit, and we, myself included, started slacking off on things once the majority of the sprint’s work had been done. We might have been able to come up with some other issues than the ones we have posted on Gitlab, but perhaps we wouldn’t have, who can really say for sure, our stuff is basically already done from my understanding. As for me, I am trying not to slack on any of the work required for this class in the last weeks of the semester. While the last presentation is a good week or so away, I am trying to make myself as available as possible, and I am trying to keep on top of everything so that the presentation isn’t rushed. 

For the design pattern I’ve chosen for this post, I went with something that I feel really encapsulates all of the work I’ve done over the course of the semester, and that is Sustainable Motivations. The pattern states that a software craftsman should hone their skills to cope with ever changing specifications and demands from customers. It recommends trying to remain motivated by writing things down that motivate you about your work, and trying to keep in mind that not every day programming will be perfect. Throughout the course of the semester I have had a kind of moving target problem with the scope of my work. At the beginning, the issue I was assigned requested I use RabbitMQ to send messages on inventory actions, but it did not mention the fact that RabbitMQ wasn’t implemented in the Inventory Backend at all. So suddenly, the scope of my work had changed dramatically, and I spent most of the first sprint stressing that I wasn’t doing as much as I should while I got RabbitMQ running. Later on, things like queue creation and library conflicts became a problem, and it seemed like the further I got in, the farther away completion of my goal was. I think if I had read this pattern at the start of the semester, or even at the start of sprint 3, I would have taken some time to actualize that I was never going to have a static goal with this kind of work, and perhaps I would have cut myself a little slack in that regard. 

Overall I’ve enjoyed this class quite a bit, and my time in college in general, since I am graduating. I’ve learned a lot from this course, and gained a lot of experience that I will doubtlessly use in industry. So, all that remains now is for me to coast through the finish line, and see where my career takes me from there.

Thanks for reading my blog! Who knows when or if I’ll post again, but it’s been interesting writing about all the work I’ve been doing for classes in a public facing way. I might even try this whole thing again sometime, who knows! :p

 

Merge Requests:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/69

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/68

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/66

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.