This sprint was heavily focused on the InventoryBackend repository. One of the main goals of this sprint was to have made some meaningful refactorization to the backend that would take care of out of date code. This old code would turn out to cause a lot of confusion later on when we would attempt to write automated tests for the backend.

Our team met with members from OL Team 2 to discuss what resources they had to help us implement nodemon. This was then taken over by another member of the team as I mainly worked on designing the tests for the backend. Afterwards I would work with another team member who was working on researching and setting up mocha and chai in the backend. Together, we would take the tests I designed and attempt to develop working tests for each of the API calls. The biggest issue we ran into was that the test we were using as an example from the GuestInfoBackend seemed to be unit testing the endpoints rather than testing the API calls. This paired with the errors involving Gitpot and trying to connect to a local host left the team unable to get working tests by the end of the sprint. However, the information we have learned can still be documented so that the next team/developer who looks at this issue wont have to start from square one.

What Worked Well:

This sprint felt like we had a better understanding of the issues on our board before going to the sprint. This led to us having a good plan for the order in which the issues needed to be addressed. This also means that unless one of us ran into an issue, a lot of these issues could be handled individually. While this was great for cutting down on the lengthy meetings we were having in the past, it did also hinder the communication between the team.

What Didn’t Work Well:

Throughout this sprint, we had significantly less time in meetings. Although it feels like the same amount of team and individual effort was put into this sprint, the overall takeaway from the sprint feels less. With most of the work being done individually, there were a lot of opportunities for information to not be shared with the team. This made it hard to keep up with issues and what was going on outside of the standups. 

Team Improvements:

Moving forward, if we were to have another sprint together I would say that our biggest improvement can come from better documentation. Our first 2 sprints we were lucky enough to have a lot of time actually working together as a team. Having less verbal communication this sprint meant we were very reliant on our stand-ups and any documentation we created for issues. Creating better comments in the issues keeps everyone on the same page for what has been done to fix the issue. Especially if we are stuck and ask for help from another member of the team. 

Personal Improvements:

When it comes to working on sprints in the future, I plan to keep myself involved in what the rest of the team is doing throughout the sprint. While it was great knowing I could trust my team members to handle the issues on their own, it still felt like I was missing information or not keeping up with the collective knowledge. 

Issues:

Meet with OL team 2 to discuss implementation of Nodemon:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/100 

Design unit tests for InventoryBackend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/96 

Weight accepts the wrong type of input in the frontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/56 

Create removeInventory automated Test using Mocha and Chai:

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

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

The third sprint was uniquely challenging for our group, because each of our members were faced with personal challenges and setbacks while we worked to resolve our assigned issues. I was primarily concerned with writing a unit test for the ‘InventoryBackend’ microservice that would evaluate the operation for adding a weight value to the weight stored in the inventory. This test was supposed to ensure that responses were returned for either of the operation’s two outcomes – a ‘200’ HTTP status reflecting a successful addition to the Inventory’s weight, or a ‘401’ HTTP status, indicating that the HTTP request contained invalid values for one or both of the ‘weight’ and ‘Id’ fields.

While discussing the unit test design process with Professor Wurst, we realized that the HTTP ‘401’ error code was the incorrect choice for communicating the error to the user. According to the list of HTTP response codes hosted by Mozilla, the ‘401 Unauthorized’ error code from the server reflects an unauthorized or unauthenticated request from the client. In our situation, where there exist invalid values in our HTTP request, the error code ‘400 Bad Request’ would be more appropriate.

I was not able to get my unit test to a point where I felt that it was ready to be merged into the main ‘InventoryBackend’ branch. I was having difficulty getting the backend server to build in my Gitpod workspace with the ‘bin/up.sh’ command, which caused the portions of the test which checked for a valid HTTP response to fail. I also had doubts about the construction of my test, as one of my groupmates had pointed out that my test should be using the getInventory function to monitor the value of the Inventory’s weight as the operations are performed.

One of the things that was holding me back the most, in addition to the challenge of researching and learning unit test design, was that I got sick in the middle of the sprint. It wasn’t anything serious, but my energy levels and ability to concentrate were impacted, which ultimately had an effect on my work this sprint. I would have liked to contribute more than I was able to in this last sprint.

Another thing that was holding me back form designing the best unit tests that I could was that I need to spend more time studying and reading about HTTP backend operations. I’ve realized the importance of setting aside the time to read, absorb, and reflect on the material through writing and taking notes as part of the learning process. Over the summer after this semester, I want to take the time to read a book on software unit testing and take notes as I read. I’ve been considering taking the advice from the Apprenticeship Patterns textbook to build my own personal wiki as a way to organize my notes on all the subjects I’m interested in, like software development, information technology, and data science.

Despite the challenges in my own life during the sprint, my team was a tremendous support during the sprint and I’m really proud of all the things they were able to get done while I wasn’t feeling my best. We all did our best to communicate over text between meetings to coordinate our next moves, and we all still showed up for our scheduled voice calls to work on our assigned issues together. I would be happy to work with any or all of them again, and I’m hoping to keep in touch with all of them after graduation.

From the blog CS@Worcester – Michael's Programming Blog by mikesprogrammingblog and used with permission of the author. All other rights reserved by the author.

During this sprint, I worked on three issues that were assigned to me. As a group, we all did well in our first and second sprints and felt we had much to improve on during both of those sprints as well as this one. There was mainly one area where we could improve as a team. The first issue that I worked on this issue was issue #99 “Investigate InventoryFrontend to ensure hot-reloading the backend doesn’t affect functionality”(3).

When looking into this repository’s script files I was initially very concerned with the possibility of nodemon being able to be implemented without causing functionality issues. Within the script files there was code that would need to be refactored, and code that connected the backend to the frontend was also outdated and would need to be refactored, they were both using an outdated way of classifying inventory weight. They were using individual item objects instead of a weight integer. I met with Dr. Wurst to discuss what would need to be done in order to progress, thankfully I was mistaken in thinking that both repositories would need to be refactored before nodemon could be implemented, I was told to look into the inventoryFrontEnd to see how I should implement nodemon. The next issue I started working on was “Research nodemon as a way to run backend in ‘development mode’ “(1).

I spent a very long time on this issue looking through nodemon documentation, articles discussing implementing nodemon on pre-existing repositories, blog posts discussing the best ways to implement nodemon into pre-existing projects and only after all of that, I decided to look at the inventoryFrontEnd which had already implemented it. After looking at where it was implemented I was very confused as the solution seemed to be deceptively simple. The implementation of nodemon falls under issue #98 “Edit script files to accommodate hot-reloading for InventoryBackend”(2).

Only one line of code was needed to properly implement it. I was both relieved and very upset by this. I had spent hours researching and reading what needed to be done being very confused by conflicting information from different articles and blog posts only for one line of code to be written. While I did not need to do as much research as I had done, I did learn a lot about nodemon and how it works. The last thing that I will discuss in this blog post is how our group worked together and what we could improve upon for future sprints.

Our group learned a lot from the previous two sprints and this sprint we were able to improve upon our performance significantly. However, we definitely could improve with checking the calendar for when the meetings with Dr. Wurst are. When the sprint review came up I had completely forgotten that it was that day, thankfully we were able to reschedule for the next class to have the review. We got very lucky this sprint, but in future sprints we would have to be far more careful with deadlines and important dates.

Issues:
(1) Issue 97 : https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/97
(2) Issue 98 : https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/98
(3) Issue 99 : https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/99

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

This sprint, the bulk of my time was spent looking into ESLint and keeping up with the team to ensure that we are meeting our goals. I also made a tentative branch for how the pipeline should look like after the linters are added, as these changes were never pushed by the team that was in charge of actually putting the linters in the ReportingAPI repository. I also participated in a clean-up of previous issues that were completed, and reviewed some merge requests from team members.

ESLint Research and Configuration: I checked to see if ESLint could theoretically fulfill the needs for an active linter that shows JavaScript syntax errors in the editor, and it seems like with proper configuration it does fit that role. I found that the ESLint version we currently use is out of date, and the old style of configuration file (.eslintrc) was hard to get working properly. With the new format for ESLint configuration, I found that ESLint needs to probably be installed locally in order to have this take effect properly, and that we should update the ESLint version we use in LibreFoodPantry to adopt the new configuration standard.

Pipeline Configuration: I configured the pipeline based on the GuestInfoBackend repository, and it currently fails because there are no linters actually installed in the repository. The idea is that when the linters are merged into the main branch, this pipeline branch should fetch those changes, push them to the branch on GitLab, then check to see if the pipeline does work correctly with that. Theoretically it should.

Cleanup ReportingIntegration: I checked over the work I did in this repository and it looked fine. I also adjusted Hieu’s branch where he cleaned up some of the documentation.

Cleanup ReportingBackend: I checked over the work I did in this repository and it looked fine.

We had some logistical issues again this sprint, but ended up completing nearly all of the work that we set out to do, thankfully. The problem was that there was a kind of rush during the last few days leading up to the sprint review, which led to me having to take charge as scrum master and keep up with each group member actively in the days leading up to the review to make sure everything was completed. That being said, our communication was the best that it has been this semester during this sprint, the one issue I was consistently having is that we should be sharing communication with each other, but team members were direct messaging me personally for issues they were having.

On my part, I do think I could’ve spent more time with the ESLint issue and also looked into other solutions, but I definitely was feeling crunch from other courses and ended up putting the work for this course on the backlog while other courses were piling work on me. I’m happy I got to a relatively satisfying conclusion with the issue, but I feel like I could’ve done more. On the part of being scrum master, I performed much better at keeping everyone on task by checking in every week, though I could’ve been a little more strict so there was less crunch at the end of the sprint.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

Tasks/Issues that I worked on in Sprint-3:

1. Cleanup and Enhancement (Reporting Backend) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/79):

Assigned alongside Isaac, Victor, and Andi, I undertook the task of consolidating enhancements made to the reporting backend during earlier sprints. My role involved conducting a thorough review to ensure clarity and accessibility for future developers. While I completed the task successfully, I acknowledged the need for additional time to refine code cleanliness further.

2. Documentation Review (Documentation Repository under Reporting System) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/documentation/-/issues/11):

Independently assigned, I reviewed the reportingsystem documentation repository to identify any inaccuracies. After a comprehensive review, I found the repository to be accurate and well-structured, requiring no immediate changes. However, I recognized the importance of ongoing documentation maintenance to keep information up-to-date.

3. ReportingIntegration Documentation Update (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/merge_requests/10/diffs?commit_id=c972ae9723af3eefcf3d2f09b4827c9c942b368c):

In another individual task, I updated the reportingintegration documentation to reflect recent changes. This included updating the lint.sh file to ensure proper linting functionality and modifying file paths for improved readability. Despite encountering an issue with dead links, which I consulted with our professor about, the documentation updates were otherwise successful.

4. Code Cleanup and Refactoring (Reporting Integration) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/commit/ece7535bbd6e9c5901083e541fb450dcbb9466b8):

Collaborating with Victor, I worked on cleaning up and refactoring code within the Reporting Integration module. This involved rewording, rephrasing, and highlighting phrases in documentation files to enhance readability. While completing this task without issues, I acknowledged the need to dedicate more time to code cleanliness for improved team collaboration and understanding.

Reflection on what worked well:

Improved Docker Pipeline Configuration: We successfully configured Docker pipelines, addressing path issues and ensuring smooth file copying into containers, enhancing our development workflow.
Effective Scripting: Our development efforts were streamlined with the implementation of scripts like bin build and push.sh, contributing to efficient Docker operations and backend development processes.
Communication and Task Management: Clear communication through GitLab issues and effective task management ensured that team members were aligned, contributing to productivity and progress tracking.

Reflection on what didn’t work well:

Linter Configuration Challenges: We faced difficulties in setting up linters, particularly with es.lint configuration files and syntax checking, impacting code quality validation.
Docker-compose Issues: Challenges arose in creating Docker Compose files that adequately handled starting MongoDB, RabbitMQ, and backend services, causing complexities in deployment.
Dependency Management: Struggles with dependency management led to inconsistencies in development environments across team members, hindering collaboration and code compatibility.

Reflection on changes to improve as a team:

Enhanced Teamwork and Collaboration: We aim to foster a stronger collaborative environment where team members assist each other with tasks and share knowledge effectively, improving productivity and problem-solving capabilities.
Improved Documentation and Knowledge Sharing: Documenting processes, configurations, and troubleshooting steps will facilitate smoother workflows, onboarding for new team members, and better understanding of project intricacies.
Streamlined Development Processes: Automating repetitive tasks like linting and formatting will reduce manual effort, enhance code quality, and ensure consistent development standards across the team.

From the blog CS@Worcester – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

Going into Sprint 3, we completed a majority of the issues that we wanted to get out of the way except for backend testing. We had already put in a lot of time and effort trying to get the test-runner to work but it was still facing some issues. 

It was having some issues running on other computers and sometimes the test would fail because it would start too early for the backend server thus we had to implement a way to delay the test-runner container so that the backend server could finish processing.

Despite the goal of the sprint is to clean up any loose ends, it was still important for us to finish any issues started and close off any issues that we couldn’t get to. Stepping back from backend testing I decided that it was best for me to finish the “Set up GuestInfoIntegration” Epic this meant I had to:

• Create any documentation in the GuestInfoIntegration
•  Verify the GuestInfoIntegration repo to see if I was missing anything

After getting those finished it was time for me to get back to working on some testing. The test-runner was still having issues, and it was difficult for me to find a solution so that the test-runner script wouldn’t start too early while the backed server was loading, but eventually, the team thought it was best for both docker-compose files to be put together. Doing this, I can insert a health check on the test-runner container so that it can check if the backend or the Mongodb was completed before running. Before we had inserted a “sleep” right between the docker-compose running the backend server and the docker-compose running the test-runner container. This was in the test. sh. I decided to work on some tests as well, In the test-runner remote branch that we merged in the main, I made sure that the test will return the right status code and error messages. It’s worth noting that the test was implemented when working on the issue “Add HTTP request testing using npm test script”. But have been revised in the test-runner branch to better fit our designs list on the issues below:

• Add Unit Test for deleteGuest
•  Add Unit Test for createGuest
•  Add Unit Test for listGuest
•  Add Unit Test for getAPIVersion
•  Add Unit Test for replacingGuest
•  Add Unit Test for retrieveGuest

The listed issues also have been designed so that when the next group picks up the project then they will be able to see what we as a team were planning when looking at our test.

The test-runner merge is also modified to work with the pipeline and the test stage will react if something is wrong with the test. 

When it comes to clean-up we went ahead and finished up all the issues that were working and closed off any other issues that weren’t going to get into. Any branches that were left over have been deleted and merged and all the finished epics are closed off while the unfinished ones have been moved to open.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

The third sprint was the shortest, but I feel like it led to some of our best work. I only worked on one issue this sprint, as we had less weight than the others. The issue was to create the test.sh file, which was being continued from the last sprint. The issue got completed with the help of Scott and Moses to clean up the queue, and the link can be found below. This blog will go over my retrospective thoughts now that the final sprint is complete.

There were many things that went well throughout the final sprint. One thing that went well was our communication. Our team has had this positive throughout all of the sprints, and it continued here. We talked to each other all the time whether on Discord or by call. Another positive for our group was how we never deterred from the goal, and from the very beginning, we were determined to finish this sprint strong. This sprint more than the others, I feel like we knew what to do and immediately got to work. The experience surely helped with that.

There were also some other aspects of the sprint that I think we can still get better at in the future. One thing that I think we can still improve on is our weights as a lot of these issues we worked on were carry-ons from the last sprint. We can still improve on that, but I think we got better throughout the semester. Another aspect that I think we can still improve on is our experience. We did not have experience with short sprints like this one, and so I feel like that put a lot of stress on us that would go away with more short sprints. The more experience we get with shorter sprints will only make us better.

There were also some things that I feel that I personally can improve on. One thing was that I was sick for most of the sprint, so I was not able to put in the work that I wanted at times. I know that being sick is uncontrollable, but I wish I would have helped more than I did. That is the great part about a group though, as everyone helped me through that time. Another thing that I could improve on is my knowledge of software development. I do not think that I had zero knowledge, but I feel like I can always get better. The more I can learn, and the more experience I get, the better I will get at this in the future.

With this third sprint over, all the sprints have finished. I really enjoyed working through all three sprints, and I am thankful for the experience this has given me. In the beginning, I was really worried about how this would all go, and I can safely say that I do not regret a single day throughout all three sprints. I love the group that I was assigned to, and I think we did a great job teaching each other aspects of the work we did not know. I feel like we all made each other better, and that is all you can ask for.

Issue Links

1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/48

From the blog CS@Worcester – Anesti Blog's by Anesti Lara and used with permission of the author. All other rights reserved by the author.

Greetings readers, and a warm welcome to final sprint blog! As we find ourselves drawing near to the end of this semester, it is an opportune moment to embark on a thoughtful reflection of the path we have done throughout the three sprints and revel in the remarkable accomplishments of our team. Through tireless collaboration and concerted efforts, we have truly excelled, leaving an indelible mark on this semester. It fills me with great pride to acknowledge the incredible work we have accomplished together, making this academic period truly exceptional.

Sprint 1 served as a foundation for us to understand how things work and familiarize ourselves with the project. We spent time getting to know the intricacies of the task at hand, gathering information, and learning the necessary skills to tackle the challenges ahead. Building upon our initial knowledge, we dove into sprint 2 with enthusiasm and determination. This sprint allowed us to make significant progress, and we were able to complete most of the assigned work. It was a time of productivity and accomplishment, as we applied our newly acquired skills and worked seamlessly as a team. However, sprint 3 presented us with a different set of circumstances. Although we didn’t have as much work to do, the time allotted for this sprint was relatively short. Nonetheless, we utilized this time effectively by focusing on specific tasks. Our primary objectives during this sprint were to fix pipelines, implement automated testing, and tidy up any loose ends from the previous work completed throughout the semester. We dedicated our efforts to ensuring that issues were resolved promptly and documented carefully. We paid close attention to detail, understanding the importance of thorough documentation. Additionally, we took the opportunity to refine our unit tests and incorporate any necessary conditions or improvements during the final sprint.

As we approach the end of the semester, I am currently working on the final presentation. As this sprint was relatively shorter than the last two, we were mostly able to just clean up the codes mostly and get this organized. Looking back as a whole, I am genuinely impressed and satisfied with how much we have accomplished as a team. Our collaborative spirit, combined with our hard work, has brought us this far, and I am confident that our final presentation will reflect the excellence we have demonstrated throughout the semester. Let’s take a moment to acknowledge the growth we have experienced individually and as a team. We have not only expanded our technical knowledge but also honed our communication and teamwork skills. I am proud to be a part of this incredible group, and I look forward to showcasing our accomplishments during the final presentation. As we conclude this semester, let’s celebrate the milestones we have achieved and the lessons we have learned. I am grateful for the opportunity to work alongside such talented individuals, and I am confident that our future endeavors will be equally successful. Together, we have proven that teamwork, dedication, and a shared vision can lead to remarkable outcomes.

From the blog CS@Worcester – Mausam Mishra's Blog by mousammishra21 and used with permission of the author. All other rights reserved by the author.

 Hello and welcome to my last sprint retrospective blog post for CS-448, my capstone class. 

This sprint was a lot less shorter and was more focused on sprint cleanup. Luckily, our team cleaned up pretty well at the end of each sprint so there was not much cleanup left. Instead, we decided to keep working on creating tests for the backend and get the test-runner branch working. Instead of branching out and having everyone writing separate tests, we decided to come together and figure out how to write one test which was a great decision. In the end with some help from Team 1, we ended up getting 2 tests working in the end.

Links to issues:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/60. 

For this issue, we fixed a bug where GET inventory was returning an id value instead of a number.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/52. 

For this issue, we created the manual addInventory test for the addInventory endpoint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/59. 

For this issue, we created the addInventory test in chai.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/53. 

For this issue, we created both the manual test and the chai test for the getAPIVersion endpoint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryapi/-/issues/8. 

For this issue, we reviewed the current API as well as checked and made sure if everything was correct.

For what worked well, our cross-team communication worked really well this sprint. We would ask Team 1 questions and they were more than happy to answer any questions and help us with our tests. Our scrum master worked together with Team 1 to create a working test-runner branch. Communication between team members has improved a lot. We were all viewing the code together expressing ideas on what to add to make the tests work. We also made sure any guesses on what may be the problem were checked to hopefully get the tests running. In the end, the test runner branch and 2 tests were working.

For what did not work well this sprint, I cannot think of anything that did not work well since we all communicated well. I also cannot think of anything that the team could do to improve since we worked together more this sprint. I guess one thing I could have done better was to work on it more at home like how committed Team 1 worked on their issues.

For any improvements I could have done as an individual, the first thing I could improve on would be to read up on more of the Chai plugins. A plugin that I have not read up on may have made writing the tests easier and more efficient. It was also near the end of the semester and I was juggling a bunch of other assignments, so it was difficult to have enough time to complete issues at home. So a second thing to improve on would be my time management skills.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.