Assigned Gitlab Issues

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

Continued and finished the development of the launch page for Thea’s Pantry

Reflection

During this sprint I wish I was better about just starting my work. Often I kept delaying it because I was worried about problems down the line that haven’t even occurred yet. Another thing i should’ve done was just ask for help regarding the page when i wasn’t sure on what to do. If I had just asked then I would have saved myself a lot of headaches. This could also apply to asking for help regarding keycloak. Because at many points I was confused about how the tokens worked, or what roles I had to account for. It took me a while to realize that keycloak would handle the login for me so I didn’t need to implement that myself. Which would have saved me some time. One thing I think I did well was learning the vue framework and transferring my work to the vue framework. And kinda just the overall structure of vue and what i needed to do.

During this period i missed quite a few classes so i can’t speak as well as we did in our classes. One thing I can say is that at some point we kind of broke off into two groups. And each of our groups was tackling a different issue together. I’m thinking of the time that me and Andrew teamed up to find the port mapping while Cameron and Ben worked on another issue. This kind of goes into something I talked about before. But I think I could’ve done a better job of communicating to the team that I was stuck and or times where I couldn’t come in due to other issues. I also didn’t share my work very often with the team to get their input.

The pattern I tried to employ this time around was the Craft Over Art pattern. This pattern is about having the chance to build something impressive. While you have this great opportunity, its important not to get ahead of yourself. Remember to keep the function in mind and make sure the software can function properly before adding the flare. I think this was an important pattern for me to keep in mind because at many points I was full of ideas of what I could do. But by doing this I overwhelmed myself because I had no idea of how to complement. So at a certain point I decided on making sure that the launch page can first fulfill its function, before getting into the more aesthetic stuff. Especially near the end of the sprint I became more focused on getting the page and token stuff to work first. In the end I didn’t have as much as I wanted to improve the look of the page. But I did have something functional in the end which is better than something that looks nice but is broken.

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Gitlab Descriptions

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend/-/commit/96464eb852632dc728f438b7f4c0165831091a80 – Changed the modal pop-up to better match our visual identity guidelines.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend/-/commit/93a04bbdc54647d56d91fe797d7b3fea86c42236 – Changed the inventory table layout to accommodate for smaller screen sizes by adding a slider to view the entire length of the table.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend/-/commit/d81fe66a0adf27aff2dd29f7ba3713be9b9aa09d – Added buttons to navigate between the scanner and inventory pages to not make it necessary to go to the home page first.

Sprint Reflection

This was our last sprint, and I think that during this sprint a lot of my previous qualms were addressed and fixed. One thing I had said before was that I thought our communication was lacking in certain areas and that since we were working in pairs, the rest of the group was mostly in the dark about what we were working on, but I felt an increase in transparency this sprint. It felt like more of a team effort which I think was in big part because we were finally finishing up working for the semester so everything that we were working on individually was coming together. Working on the final presentation also helped with this as we felt everyone needed to be on the same page to be able to deliver a presentation that showed off our project well.

This leads to what I don’t think went as well, which was that it didn’t feel like as much progress was being made toward the project this sprint, at least in comparison to previous sprints. This was probably due to our presentation preparation, as well as a focus on cleaning up already implemented features rather than starting new ones. We knew since this was our last sprint that it was the time to wrap up what we were working on, which is probably why it felt like not much was getting done, but in reality I think what we actually did was just as important. 

I can’t think of any major improvements to make to the team to get it to function better, as we worked just as well as I think we could have. It was a pleasure working with this team and I think that these reflections in past sprints helped us come to a point where those points of improvement were answered and made us become an efficient team. As an individual though, I do think that I could have done more, which again circles back to the point of not feeling like too much was done. Looking back at what we’ve done though, I am happy with our progress, seeing as we started the semester with a blank slate and now we have a functioning scanner/database app. It’s just a personal feeling that more could have been done, but I think it’s true that there is always room for improvement. And I also think it’s good for me to have that mindset, but for this project specifically I’m not disappointed with my performance.

Apprenticeship Pattern

The apprenticeship pattern that stuck out to me for this sprint was the “walking the long road” pattern. It’s an important one that comes with mastering a discipline, the mindset that you are never really done learning, that there is always more knowledge to be had, always more challenges to overcome. This being our last sprint makes this pattern important, because we just spent months working on a project, emulating a real scrum team, but it doesn’t mean we are anywhere near mastery. Just because the semester is over and we completed this chapter doesn’t mean we are done, in fact I’d say we are at the very beginning of our journey still.

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

For my team’s sprint 3, there was not much more functionality we wanted to implement. On one hand we had the front end and back end working exactly how we wanted it to, for the full purpose of a demonstration. On the other hand, we knew that we would have to back track. The backend needed to be refactoring to fully represent an inventory backend instead of the guest info backend we had forced into working for us. This proved to be much more work than expected, more on that later. We also had a few different looks in regards to the actual display our front had. Slightly changing colors, logos, their sizes. All of the things you would expect when it comes to user interfaces and experience. While my own work focused mainly on the back end it was a good experience and very eye opening to work with the team members who were tweaking things and making different versions we were choosing from. It was fun to see what the tedious and seemingly bland work I was doing on the backend actually visualized and became something that felt actually usable.

For my own work on the backend, I was trying extremely hard to work with a teammate to go through Renaming and refactoring everything. At this point we had taken a backend that was being used to store guest information. Names, ID’s, and other identifying or important information. Them converted it to instead take the place of an inventory system that had not existed. This meant that the collections being used, the end points, the oaths, a lot of the comments, all of the documentation and all of the included tests. Would all need to be rewritten. What seemed easy on the surface quickly spiraled. Looking back it probably would of been better to dive into this issue before expanding on the whole project. By this time we had already connected the front end to it and a fetch script that worked as a middle man. After weeks of trying over and over to make this conversion. It became clear that it would have to become a project for whoever comes after us to work on. Although the opportunity is still available if I decide to take another shot at it, solo and on my own time. 

In order to at least make some progress I had moved forward with rewriting all the tests. I am extremely grateful for having learned Mocha and Chai testing from an old classmate a full year ago. He was also, is surprising serendipity, the person who had worked on the original tests for the guest info backend. Once I realized this I reached out to him just to check in and he was able to give me a couple resources and remind me of an assignment we had done together that proved to be a massive help.

This helping hand from a friend I had made really brought me back to the section finding mentors of the apprenticeship patterns. Having a network with friends who have understanding and experience in areas where you’re lacking can be such an amazing resource to utilize. Surrounding yourself with smart people, even if they’re not directly involved in what you’re working on can be a saving grace.

In the end, not as many features and additions were made in comparison to the first two sprints. Sprint 3 was a fun challenging experience that helped me reconnect with an old friend and rediscover how much I love testing software. 

With the original goals of all of the variable name changes, comment changing, documentation updates and rewritten tests. We were at least able to complete the documentation and testing. I even got the pipeline to finally pass with all of the tests and spelling checks.

I’m proud of what this team accomplished and the state of the project they were leaving behind for future teams to further develop. 

If I don’t get to it first >:) it is open source after all

From the blog CS@Worcester – Mike St G – 448 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

So here it is, the final Sprint. I have to admit, it was a lot more lax compared to the previous two sprints.

The main things we focused on this sprint was wrapping up to prepare for the end of the semester, and making sure our work is ready for future courses. For me, this was three things. One, merging my work to main. Two, write up documentation for the future courses. And lastly, making sure my part of the presentation was ready.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-category-based/frontend/-/commit/443acdb08e49f7bb1c722fc415eb4fd27251a95d

Here is my merge request for the documentation I made.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-category-based/frontend/-/commit/16defd74aa955d6283efeb86d38ddc74b9d19caf

And here is the merge request for my work onto main.

Looking back on older work on how to do merge requests was a fun challenge, having to sift through a bunch of older courses with Professor Wurst to remind myself. I learned through Alex that the repository already contained a bash file that squash all the commits I made into one singular commit. This was extremely helpful to keep track of the commits I made.

I ran into a bit of issues when first trying to push my changes, but I later found out it was due to my Visual Studio Code trying to push to my Github account rather than my GitLab account for some reason. Easy fix was to simply reset my login info stored within the editor.

I feel as though at the end of the day, our team worked very well. We could have definitely been a bit more communicative, as I felt there were a couple moments where I would try to communicate with them in Discord chat that I would be left on read, but otherwise we were relatively clear with helping each other and staying on track. I felt like my participation in the group was a bit more equal this time around, but still lacking in comparison. Marlon and I agree that my work was a lot more abstract compared to them, so it is very hard to equate my work to my teammates.

For this Sprint’s pattern, I chose “Expose Your Ignorance” from Chapter 2. Throughout this sprint, I found myself struggling to remember how to properly use Git. Much like the pattern suggests you do, I was able to confront my peers about the issues I was having and they were able to assist me in return. I feel like I could have used this skill a lot more as throughout my entire time in this course, I didn’t really ask for help. I felt like I had to be in charge of my own work and should learn things on my own. I should take the time in the future to break that habit down.

Overall, I am happy how this sprint went. I feel as though this was absolutely a strong one, but not as strong as Sprint 2. I simply feel this due to the fact there was less of a workload being pushed in comparison, which isn’t necessarily a bad thing! I feel like throughout this course I have learned a lot about working as a team and finding my place within one. I’m hopeful I am able to utilize these skills in the workforce, and be an effective employee for whoever hires me.

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

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 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.

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.