https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/merge_requests/14

This is my merge request for my finished task of writing documentation on how to implement and use nodemon for faster, more efficient development.

For Sprint 2, what worked well for me as an individual was being able to use the other pieces of documentation as a reference, and also being able to utilize Markdown’s formatting to give the documentation a clear and understandable look. I had also kept track of my process of installing nodemon with a Google Doc file, which made it immensely easier to retrace my steps and know what worked and what didn’t. Although it was my first time writing documentation, I didn’t feel lost at any points, and I was able to create a set of instructions I felt confident in and proud of.

As a team, we stayed very organized throughout the entire Sprint, keeping track of issues and merge requests as they were posted. Most merge requests were either discussed in-class or over Discord, which helped the other team members understand the changes being made. I feel like we really gelled well as a team, and morale was high, which enabled everyone to feel comfortable with bringing up issues or asking for help. Everyone has been great at completing their fair share of work, both when it comes to the project itself and the Sprint Review presentations. 

On an individual level, what didn’t work well was I felt as if I became distracted at times during class, when I could have been more focused on completing my work. This is something I am actively working on being better at. I could be a bit more productive in-class sometimes, but this is not to say I never get anything done. I also felt as if I wasn’t completely sure about how the documentation should be written, or if the instructions I wrote would be applicable to everyone. This is something I think is okay at this point, but it was a bit of a back-and-forth struggle when it came to making certain decisions.

On a team level, there was not much that did not work well. We’ve improved our communication from last Sprint, and we are getting issues done and merge requests out at a steady pace. I think something we might need to clear ourselves up on are certain issues regarding visuals, but otherwise I think we are in a good spot.

To improve as a team, we should ask either Professor Wurst, the client, or the Visual Identity Team some clarifying questions about our issues (what the visuals of the webpages are supposed to look like, for example). I think we could clean up our Issue Board a bit as well, as it seems a little cluttered with old Issues.

To improve as an individual, I should definitely try and focus a bit more during class. Productivity would increase, and hopefully I could get more done with the time we have left. I could do better in arriving to class on time, as the last couple of classes I was running late and had to search for parking for a long time. 

For this Sprint, not many of the Apprenticeship Patterns apply to me, so I’ve decided to go with “ Rubbing Elbows”. This describes a situation where one feels there are better techniques to the craft that are escaping them. This may not be exactly true, but it seems to be based on the apprentice’s experience and emotions about what they’re working on. It stems from stagnated learning, which can lead to one feeling inferior about their implementation.

I selected this pattern because while I was writing the documentation for implementing nodemon, I felt as if I was overcomplicating the whole process and that there was an easier way to accomplish the same goal. I felt that, realistically, installing nodemon shouldn’t have been too difficult, and that I was using an inferior way to implement it. It relates to my experience during this Sprint because I was feeling inadequate about my work being the “right” approach to implement nodemon.

If I had read the pattern before/during the Sprint, I would have asked another team member to work with me on installing nodemon to see if it was truly as convoluted as I was making it. The other developer might come up with a different solution, which would be a good perspective to have.

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.

During Sprint-2, my focus was on contributing to the tasks assigned to me through GitLab. These tasks included Issue 4 and Issue 2. Both were critical components in ensuring the functionality and reliability of the fake frontend module in the LibreFoodPantry project. As the sprint progressed, I had the opportunity to reflect on the highs, the challenges, and the lessons learned. Here’s my summary of the experience.

Evidence of Activity on GitLab

• Issue 4: Task to implement functionality improvement in the fake frontend. This required debugging and making updates to enhance module performance.
• Issue 2: Debugging and addressing existing issues with edge case scenarios in the fake frontend module.

These activities provided me with valuable experience in problem-solving and adapting to unexpected challenges, which were prevalent throughout the sprint.

What Worked Well

One of the key successes during Sprint-2 was the level of collaboration within the team. Regular communication ensured that tasks were clearly defined, and support was readily available when needed. I found that breaking down complex problems into smaller, manageable components made debugging much more efficient. Issue 2, in particular, benefited from this approach, saving considerable time and allowing me to focus on improving code reliability. Additionally, Issue 4 was completed with minimal revisions thanks to the clarity of the requirements and prior preparation.

What Didn’t Work Well

However, Sprint-2 also presented its fair share of challenges. Initially, unfamiliarity with certain aspects of the codebase slowed my progress. The intricate structure of the fake frontend module required extra time to understand before making meaningful contributions. Furthermore, testing processes revealed several edge cases that were not anticipated during planning, leading to some delays in resolving issues. These experiences underscored the importance of early preparation and thorough testing.

Changes to Improve as a Team

Reflecting on the sprint, there are several improvements the team could make to enhance our efficiency:

1. Knowledge Sharing: Organizing sessions to familiarize team members with the codebase would help reduce delays caused by a lack of understanding.
2. Proactive Testing: Incorporating more comprehensive testing during the earlier phases of the sprint could catch edge cases sooner.
3. Clearer Documentation: Providing detailed documentation of tasks and processes can ensure everyone is aligned and reduce ambiguity.

Changes to Improve as an Individual

At a personal level, I identified several areas for growth:

1. Skill Development: Spending dedicated time learning tools and frameworks used in the project would enhance my ability to tackle tasks with confidence.
2. Proactive Engagement: Being more proactive in seeking clarification when tasks feel ambiguous would help minimize initial slowdowns.
3. Time Management: Allocating focused work periods for specific tasks could improve overall productivity.

Apprenticeship Pattern Selection: “Expand Your Bandwidth”

• Summary: “Expand Your Bandwidth” is a pattern that emphasizes the importance of stepping outside one’s comfort zone to learn new tools, techniques, and frameworks. By actively seeking opportunities to grow, developers can broaden their capabilities and handle more complex challenges.
• Relevance: This pattern directly relates to my experience during Sprint-2, where unfamiliarity with parts of the codebase initially caused delays. By expanding my bandwidth through dedicated learning, I could address similar tasks more efficiently in the future.
• Impact on Behavior: If I had read this pattern before Sprint-2, I would have approached the unfamiliar codebase with a proactive mindset, dedicating time to research and practice before diving into the tasks. This preparation could have prevented the slowdowns experienced during the sprint and improved my overall contribution.

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

This sprint pushed us out of the setup phase and into the real struggles of implemenation. Our focus was on certificate configuration, domain integration, and establishing a stable server environment capable of supporting frontend and backend communication through Docker Compose. We encountered technical challenges that required a lot of trial and error, especially with NGINX, RabbitMQ, and SSL certs, but we made real progress and learned a lot along the way.

Key Work Accomplished:

• SSL Certificates: After experimenting with self-signed certs, we shifted direction and enabled Let’s Encrypt with Certbot. I verified auto-renewal functionality using a dry run, ensuring long-term reliability.
• Domain & NGINX Setup: Switching from IP to domain access opened the door for proper HTTPS handling and better routing. We spent time researching NGINX as a reverse proxy and adjusted our configuration to support this change.
• RabbitMQ Troubleshooting: I spent time debugging why connection.createChannel in messageBroker.js fails during Docker Compose builds. The issue appears tied to the container configuration or startup timing, which I plan to isolate in the next sprint.
• Documentation: Added notes and resources for Docker Compose Watch (for future CI/CD use) and contributed to team documentation related to server setup and troubleshooting steps.

This sprint tested our patience and problem-solving skills. Even when progress felt slow, I stayed focused on learning and finding answers. I also made it a point to keep the energy positive in the team, especially when the same problem stretched across multiple weeks. I think maintaining that morale helped keep us all engaged and moving forward. One area I’d like to improve is how I manage my research time. It’s easy to get stuck digging through forums or chasing edge cases, so next sprint I want to be more intentional about how I explore solutions and when to pivot. I also want to get better at helping guide conversations to a technical conclusion more efficiently during group work. My top priority going forward will be testing subsystems and verifying proper communication across containers. I also want to finalize our server hosting and make sure the front end is accessible through the domain without errors. Overall, I’m proud of our persistence. This sprint was about learning and solving problems within the systems we’re building.

Apprenticeship Patterns: The Long Road

This sprint reinforced the mindset behind Apprenticeship Pattern: The Long Road—that true growth in software development comes from persistence, patience, and a long-term commitment to learning. While troubleshooting issues like Docker container problems and RabbitMQ errors was frustrating at times, I stayed focused on understanding the root causes. Each challenge became an opportunity to learn. I’ve started recognizing that even slow progress is part of the journey to achieving the goal. This pattern will help me stay motivated and positive, even when things don’t go as expected. Moving forward, I want to manage my time better when diving into technical problems and continue building habits that support my learning and my team. There is still a lot of work to complete for our team, but I think we expect this and we will hit the ground running for the last sprint.

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

Gitlab Deliverables:

• Issue Board Maintenance => Throughout Sprint #2 I was responsible for creating and tracking tasks within our group. Additionally, I reviewed the syllabus and noticed that we missed a Backlog Refinement session during our first Sprint, so I allocated two dates (one for each remaining Sprint) for Backlog Refinement sessions. I led the discussion in reshaping our scope and adding/removing tasks in accordance to that scope.
  • Link to Issue Board: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/boards
• Secrets/Docker Compose.yaml Research => This task was inspired by a component of Docker Compose I researched very late into our first Sprint. I completed my research and created documentation on this feature once I was able to implement it in a testing docker container. The main goal of implementing this was to securely hide the certificates we’d use (and mention) in our Docker Compose file. Unfortunately, we pivoted away from the self-signed certificate in favor of using domain, which completely discontinued the use of this research
  • Link to Documentation:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/documentation/-/blob/main/Documentation/Secrets.md?ref_type=heads

Compared to Sprint #1, Sprint #2 has felt like much more substantial progress has been made. During the beginning of the Sprint, we pivoted our approach from using a self-signed certificate to using a domain to create a secure connection. With this newly acquired domain, we acquired a certificate that allowed us to securely connect to the FrontEnd’s services. I was unfamiliar with the process of applying for the certificate and renewing it at the time, but our team discussed how this would work which helped me learn new aspects of networking. Just before we acquired our domain, I finished my research on Docker Compose Secrets, which at the time I thought would work perfectly with our self-signed approach. Ultimately this work will go unused as we soon ditched the self-signed certificates in favor of using the domain. I decided to keep the documentation, as future teams may need this information for this project or to learn more about Docker Compose. 

Beyond that set of documentation, I would say my most successful contribution to this Sprint was setting up the Reverse Proxy to the FrontEnd service. On the surface the Reverse Proxy was only implemented by using ~3 lines of code however, I spent a couple of hours learning what a Reverse Proxy was and which ports were being occupied by the GuestInfoSystem. Looking back at the time I spent implementing this I wish I made two specific changes to my approach. First, I wish I recorded which ports were being occupied. During my first 30 minutes of testing the reverse proxy, I was able to have a running FrontEnd connected to our domain, at the time I didn’t think this was the desired result so I soon spent another hour or two trying to see what other ports were occupied (and which services they led to). This oversight of not recording port information would not have only saved me time but could have helped provide a visual to the team illustrating what port we would need to access for a specific service. The second change to my process I wish I changed was not creating documentation. Looking back at the time I spent learning what reverse proxies were, I wish I set aside a small list of my findings. Once I had the reverse proxy working, I gave my team a quick walkthrough, but future teams might need this information. To resolve this I plan on adding a section to the Onboarding documentation, which I will write during Sprint #3, discussing the reverse proxy I created and how to find/change it.

I’m continuing to learn and apply the apprenticeship pattern “Be the Worst” from Sprint #1, but I’ve begun to focus on another pattern “Create Feedback Loops”. One thing that I pride our team on is communication among peers and shared knowledge. If we find something new such as a new approach to solving a problem or an interesting bit of research, we do our best to share it when we meet during the beginning of class. By contributing to our group’s wealth of knowledge it creates a feedback loop that not only encourages other team members to find new information but also reinforces what you have learned individually. This apprenticeship pattern encourages the developer to take a metric and see how much of that they, individually, provide to their team when compared to other team members. Our feedback loop helps keep me on my toes, as when I don’t feel like I’ve contributed to our knowledge (or by extension progress), I develop an internal drive to take on something out of my comfort zone. During this Sprint I chose to learn about Reverse Proxies to contribute to this feedback loop. Not only would my findings be applied, but I could then further encourage and enable the work of my peers. 

The last note thing I would like to note is our team’s performance over this Sprint. I have learned a lot by tackling the issue of connecting our FrontEnd service as a group, but moving into Sprint #3 I want to see how more effective I can become in tackling individual issues. During our class meetings, we typically focus on one goal and research it together. I’ve learned that I have a hard time keeping up when new information and approaches are being tested. The best way I can word this struggle is the sense of there being ‘too many cooks in the kitchen’, so moving into Sprint #3 I want to refocus my effort on my personal work. In doing so, I hope I can become a much more effective team member.

-AG

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

The second sprint was a time that honestly could have been more productive but it was a time spent learning and preparing our tasks for the final sprint. This is the second sprint and set of work that we completed as a team during this capstone. The first sprint was able to teach us how to effectively and efficiently spread out the work. In our second sprint, we were met with some more speed bumps. In this sprint, the work revolved mainly around modifying endpoints to accept access tokens and modifying the guests from using WSUID to UUID. In addition, this sprint also included adding log messages to the endpoints for rabbitMQ to improve the reporting system. These main tasks were split evenly between 4 of the members while the side task could be handled by one person.

In terms of things working well we were able to work well as a team to divide the work to be efficient in completion. Sean was working on the back end with Hiercine to start on modifying the endpoints to accept access tokens for user roles. This is supposed to allow the system to know who should be accessing certain items. We also had Lynn and Winston working to modify the guests to use UUID instead of WSUID. This is one of our biggest strengths. The strength being our team working abilities and being able to collaborate to make the workflow more effective and efficiently. Next, are the things that didn’t work well. I believe that everything we did was to the best of our abilities. The only things that could be commented on as not working well is our lack of knowledge in certain areas which caused some tasks to not be completed. For example, I was having an issue with the rabbitMQ system.

I believe as a team we are still in a good spot and be able to complete everything that must be done before the end of the semester. I think as a team we can work at continuing to improve communication internally and with the professor when needed.. In addition, I believe when it comes to merge requests we can be more efficient in making sure we verify that everything is working as intended when multiple merges are happening close together. As an individual, I believe I can improve on learning more about the tools so I understand more what is happening so I can make better solutions for the issues at hand such as rabbitMQ. I also believe I can work more at improving how I collaborate within the team.

The pattern I selected was “Rubbing Elbows”, this is the same as last sprint because I felt it still related well to how we work as a team. Even though we all had our own assigned issues, we were able to find commonalities between them allowing us to work together to increase efficiency and find solutions that we would not be able to find on our own. The “Rubbing Elbows” pattern is knowing when to seek collaboration and being able to learn from those you are working with. I don’t think reading this prior to the sprint would change anything since we already were collaborating especially after the last sprint.

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

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

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

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

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.

Configured proxy to handle requests from HTTPS frontend to HTTP backend

Added new date field dropdown and reformatted date

Still working on transitioning from wsuID to UUID

In sprint 2, as a team we worked well with making progress on our large tasks like modifying endpoints to handle tokens and transitioning from wsuID to UUID. Additionally, we looked to eachother for help when we were stuck and didn’t know how to progress further, preventing teammates from falling behind in their tasks. What didn’t work well occurred due to lack of communication, since both of these tasks depended on Section 1 Team 1 working on the login and keycloak token, it created a standstill since the team didn’t know what how the keycloak token was going to be generated and how the roles were going to work. This problem could have been solved by meeting with team 1 and discussing in person of how we can collaborate and help each. Nonetheless, we were able to design our task around stub functions and once team 1 is done with their task, we can substitute it with their changes.

Another improvement for the team that will be implemented in sprint 3 is better code review. We later noticed that some things in regarding the date field was missing, causing problems with the frontend communicating with the backend. More specifically, the frontend was sending back a json file that didn’t match with what the backend was expecting. This caused problems for other teams because they couldn’t run the guestinfosystem.

To improve as an individual, I would like to get better at managing a team. As of now, I see our team and in it we have subsections of people who usually collaborate together. Going forward I want to get more people involved in discussion and overall progress reporting.

One pattern from Apprenticeship Patterns, that aligns with this sprint is “Reflect As You Work”. This pattern emphasizes the importance of regularly stepping back to evaluate your own progress and learning as a developer. Instead of just grinding through code or tasks, it encourages you to actively think about what you’re doing, why you’re doing it, and how you could improve. This kind of reflection helps identify strengths to build on and weaknesses to address, turning everyday work into a learning opportunity. In this sprint, I spent a lot of time reflecting on not only how I was performing, but how the team was performing. Being a scrum master for the first time, I felt it was my responsibility to ensure everyone felt confident taking on their task. I made a conscious effort to check in with each team member during our meetings and encouraged honest feedback for improvement. By reflecting on the team dynamics, I was able to adjust where I needed to spend more time coding and where I needed to offer support. “Reflect As You Work” became a principle that helped me adapt into the role of scrum master, despite being my first time

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.

Throughout the second sprint, we had a great basis to launch from for our project. We made great strides throughout the sprint and diagnosed some important issues barring our progress. Our second sprint was far more difficult than our first, but we remained determined as a team and hit some major goals. I thought we communicated in this sprint far better than before, and overall worked well on major progress blockers. The most important of these issues was an issue connecting the back and front ends and managing certificates for our server. We set fair and manageable goals despite these major issues, which were started or met by all members of the team. We were again very transparent in our communication, and our communication was frequent and on-topic. I spent my time doing three major tasks; setting up persistent data storage for our back-end, researching certificates and helping to set up SSL for the server, and troubleshooting our failing back-end at the end of the sprint.

What I thought didn’t work well in the sprint was the complexity of our issues. While I thought we set manageable and fair goals, they were complex and large. Many goals had to be reworked throughout the sprint, and were met in some capacity. Many issues got pushed to Sprint 3 due to issues we could not solve ourselves. This was a learning moment for me in particular. I would have liked to resolve all our issues on our own, but sometimes outside expertise or another team is needed to resolve an issue. Even if in our case that other team is the IT department, or Professor Wurst. 

As a team I would say that we could better work independently once again. I felt that despite our fair communication, most team work classes resulted in everyone sharing issues. This is something I wanted to avoid, but it happened nonetheless. I would prefer that we work at most in pairs on individual issues, so that major issues do not get sidelined. I felt that my previous retrospective on Sprint 1 should have been vocalized. This is where I think I could improve directly as an individual. I should be more honest in my communication and bring up this flaw sooner, rather than wait for it to improve. Going into Sprint 3 I will be more open and clear about any flaws or issues I see for us all to improve together.

The apprenticeship pattern that best describes my work in this sprint is Retreat into Competence. This fit because the work done throughout the server this Sprint was charting new ground in complex errors. The groundwork we set up in Sprint 1 helped us get our foot in the door, but our SSL certificate issues and back-end connection issues became major roadblocks. I managed these roadblocks by frequently retreating to what I had learned so far, and it allowed me to chip away at the issues and diagnose what to apply to the server.

My tasks:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/13
This was my first successful task in the sprint. I successfully connected our back-end to a local filesystem in our server and cleaned all our directories of unnecessary files. I tested persistent storage, and it works fluidly.
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/18 

Most of my sprint was again spent working on the issue of SSL certificates for our server. I continued to research self-signed certificates until I decided that the best course of action would be to seek out Professor Wurst for a domain. I also worked out that there were unresolved DNS issues in the certificate that were brought to IT. Since this point we have had no SSL issues, and I have updated back-end URLs to accept https.
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/25
Here I made small progress testing the back-end’s failure before we rolled over to Sprint 3. This is an ongoing issue for Sprint 3 as of this retrospective. During Sprint 2 I made progress in diagnosing the issue of RabbitMQ’s failure, and tested various methods to attempt to resolve it and prevent the back-end from crashing.

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.

If there’s one thing I can say happily about this sprint, its that it went seriously better then the last one!

Lately, I’ve been focused on setting up a universal design for many of the applications that are being worked on throughout all of the groups in this class. Examples of which are show below, as well as a link to the specific GitLab issue they’re tied to.

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

The first two shown are my initial generalized mock-ups, showing a generalized feel and theme while also showing off some elements like buttons and subtitles that would be commonplace. The last two are the two latest I’ve made, specifically for the user information group, implementing many of the design critiques that other groups and the professor have given me from the initial design.

For me, I found being able to work in an environment I’m comfortable with, that being visual design, helped a ton with my comfort and goal-setting within this sprint. I felt like I was put on-track compared to last sprint, and was able to do significant work. However, that being said, I felt like I was significantly independent and on my own for a majority of it. None of my team members were doing the same as I, and the work I was doing was specifically for the entirety of the class, not just them. So it felt like there was a bit of disconnect there, and could be fixed for next sprint.

I feel as though I did a lot better than I did last sprint, I was a lot more enthusiastic then before, but I do feel I could have communicated a bit better with my team about my new path in this sprint. I felt I left them behind a little bit, especially Jaylon, who was alone in the Frontend development. Next Sprint, I plan on improving on this by trying to split the visual design aspect of my work evenly with work for my team in specific. As for our team, I cannot really comment too much about what we could change as a group, as I feel they’ve been doing fine, I’m just the weakest link they have at the moment.

For a single pattern, I chose Your First Language as found in Chapter 2, which states that you only understand one or two programming languages, but not the ones particularly known for the job at hand. I chose this one as I felt like understanding a lot of the languages being used in our repositories are something I have minimal understanding in, and need to learn better to help my group as best I can. It suggests I toy around with new languages whenever I can, to best help and learn the ones needed. I feel as though this is something I would have already done, given my lack of time to do so, as I find myself having to juggle with work from this course with my others. However, that does not mean I’m willing to give it a shot going forwards.

All in all, I feel like this sprint was a success, and am looking forwards to the next one, which will be our last sprint. Here’s to improving where I can in that one as well!

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.

Hi Debug Ducker here, and wow Sprint 2 came and went really fast. I have a lot to share today as well as realizations about myself and the project. Then afterwards I can say one last goodbye and sprint 3 ends, which is coming sooner than I think.

Now what I been working on these past few months was an inventory culling system that will tell the user whether or not food is past their expiration date by USDA standards. The progress on it as of now it more or less complete. It feels strange to say but we are pretty much at the finish line. This was felt after Sprint 1 were the path forward was decided and could be completed in due time. Which left the group working on the backend to not have a lot to do. Because the solution just needed time and everything would be fine.

After that we were pretty much done and I realize that some task can realistically be completed by two or less people. In a way I felt I wasn’t pulling my own weight. Perhaps I should have tried to be more involved with the process than I was and that could of made me feel that I was doing more. I guess that is the result of some projects that the seemingly big task was rather simple so now you just feel, rather empty about the whole thing.

Fortunately, I was given the task of filling out documentation, which is really important as what if the new people that work in this project need a guide. I and with some direction would be the one to write it all out. Documentation is a lot more important than people give credit, a place that can give you all the details about a project is rather handy when you are working on said project. Which I had something similar when I first started. Now I am working on clean up with another partner of mine, and we may be able to get that done soon too.

Last time I reference the book, “Apprenticeship Patterns”, by Dave Hoover and Adewale Oshineye and there is a pattern that reminds me of this situation. The pattern was emptying the cup similar to accurate self-assessment, the idea here is that if you don’t allow yourself to be willing to learn or do more then you aren’t going to do better. I feel I should have pushed myself to at least see what else could have been done with the project, instead of feeling useless.

Here is my work on the Documentation, I mostly did the readme and fixed up the instructions

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

Here is the Backend work so far in collaboration with other group members. The result was full integration with the scanner side of the project which is almost done

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

Here is the Scanner portion done by the team focus on it

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

Thank you for your time and have a nice day

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