During the course of this sprint, I spent most of my time looking at the ReportingBackend repository to figure out what was going wrong with the testing suite. I also had assigned myself to configuring the pipeline specifically in ReportingAPI with the linters, but unfortunately was unable to complete this issue because the team responsible for actually adding the linters to the repository was not able to push their changes before the sprint ended. I continued to act as the scrum master for the team, taking an active approach to making sure everyone is doing work, getting credit for their work, and setting up meetings when necessary. I had to help out a bit with other team member’s issues as well, providing some guidance.

Verify the Testing Suite works: Investigate the testing suite and see if I can get it to work, or at least figure out the magnitude of the problem. I applied a couple of fixes (one of which was in the build.sh script that I had a separate 0 weight issue created for, as I had already found the bug and fix prior to the sprint starting.), but it seems like the issue transcends the testing suite and is moreso an issue with the build process with the server.

This sprint was pretty rough, if I’m being honest. For what we did well, our communication overall improved, and the team was better able to utilize GitLab for their work. I think that everything on GitLab was better organized and most of the issues had better descriptions on them than what we had last sprint, and the weight assigned to issues seemed fairly accurate all things considered, aside from the testing issue (which I did spend a lot of time on). We also did work with each other more than we did on the last sprint.

Most of the issues that were assigned to our team were rushed together during the last week of the sprint (from my perspective at least, there may have been some confusion with pushing to GitLab). As such, we weren’t able to get to all of the issues, and only got 14 weight out of the 24 weight assigned to our team fully merged in. I was offering support during the whole sprint, but it seemed like team members were not able to coordinate into a meeting at the same time for most of the sprint. I don’t really have a great reasoning for this, it seems like things weren’t being done until the time was very short to were we couldn’t get everything done, taking all of our other schoolwork into account.

Ultimately, I think for next sprint our team really just needs to work on spreading work out during the entire sprint rather than getting things done last minute. We should also work on coordination and being more present, as when anyone asked if we wanted to do a meeting, the team would all say they were available and no one would take the initiative to actually begin the meeting. Part of that is on me as scrum master, but ultimately we should be willing to meet without having everyone on board if we are working on specific issues.

I was able to spread out my work fairly well as an individual, but I can’t say the same for other team members, and so as scrum master I should be more active in making sure everyone is doing their work not just so the project moves forward, but so everyone gets the credit they need for the course.

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.

One issue our team was having during this sprint was that getting or deleting a guest, after creating the guest, was returning a 404 not found response. We were having a difficult time identifying the cause of this reversion of good behavior, so I learned how to use the git bisect subcommand to find the commit, found the change within the commit that caused the bug, and reverted that change. It ended up being that we could not refer specifically to the /guests endpoint token within the OpenAPI server URL value without other changes.

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

Continued existence in frontend (we just need to make sure the right API YAML file is being used in all the repos now): https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/57

Chai has very nice syntax, which together with chai-http lets you call should on an object, such as object.should.have.status(200), or to call chai.expect(object) when the object might or might not exist. I wrote some simple unit tests, such as verifying that the version string has a range in [5,8] — ('0.0.0' - '99.99.99') — for getting the API version. As with other tests, being able to call them quickly with cd src && npm run test while the server is running on localhost is a useful holdover until we get the CI pipeline working.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/70/diffs?commit_id=69a9d2299335066166b6379bbdb83bd4d5594bde

I did some pre-sprint-3 cleanup by removing the Chai (not Chai-HTTP) example testGuest.js file.

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

I cleaned up our set of unit tests, for the create guest endpoint, which I think is now the first to be in a really good state concerning test coverage not including the get API endpoint. This includes a cleanup step at the end (so tests can be run repeatedly without rebuilding the server), several HTTP requests: both valid and invalid, examining many of the properties of the returned responses. One trick I learned was to assign a const object to store guest data and then repeatedly copy it with the spread ... operator. Otherwise JavaScript would copy by reference and disrespect the const-ness of the object: it would otherwise mutate a const! What a lovely language feature.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/72/diffs?commit_id=9e3ee6ee2b4202c5971445ead7fc8a10fc727992

Overall, I think I did decently. I helped Kelvin a little with some of his issues. He individually, and our team as a whole, did a great job this sprint. We began and completed work on multiple epics. We ended in a state where now, 1 week from the end of sprint 3, we think we can finish up everything that we wanted and agreed to get to in our sprint 3 planning meeting.

One challenge I faced that I couldn’t resolve was an unfortunate technical difficulty. Despite multiple restarts, re-cloning the repos, and checking my installed program versions, my computer stopped being able to run the server. I eventually gave up after a few hours of trial and error, and moved to a different computer, but I suspect the problem was in an incompatibility involving the rolling-release software update model used by Arch Linux. I’ve now had 2 confirmed and 2 other suspected significant issues that might have been avoided by using LTS software.

Our team could probably improve our communication. It’s hard to find time after Thursday and before Tuesday to plan or collaborate on changes. Early this semester I supported working asynchronously, but in retrospect having an hour or two per week of planned collaboration probably would have led to more productivity and confidence without an unreasonable cost.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

Our team hit the ground running in the second sprint to deliver a much better result than the first sprint in the end. I ended up working on three issues, with two being completed in the end, and the last one being saved for the next sprint. The links to all three issues can be found below. The first issue was an issue that had been unresolved in the last sprint. What happened was that I had finished the issue, but there was a problem with the commit. I received help from Scott on fixing the commit problem, and the issue was resolved. The second issue was another one that came from the first sprint. I had many troubles with updating the pipeline in the first sprint, and I really needed help with it in the second one. Sam jumped in and did an amazing job getting it to work, and we could not have completed it without him. The third issue I had started in this sprint was creating the test.sh file in the command folder. It took a lot of trial and error, but I just was not able to finish it completely, and I am looking forward to finishing it up in the next sprint. This blog will go over my retrospective thoughts now that the second sprint is over.

Many things worked really well throughout this sprint. One thing that was huge was how much we had learned from the first sprint. In the first sprint we started off slow as we were still inexperienced, but this time we just flew through the beginning, and hit a roll. This can be seen in the nearly 10 point weight difference at the end of each sprint. Another thing that worked well was how cohesive we worked as a group. Now that we had more experience working together, I felt that we talked with each other more, and worked together to finish issues more as well.

There were also some things that did not work well throughout the sprint. One thing that comes to mind is how even though we are better, our weight scaling is still a little off. An example of this is with the pipeline issue where we put it as a weight of two, and it ended up being a weight of five or six. Something else that comes to mind that did not work well is our understanding of new information. It has taken us way longer than we thought to understand Chai, and we are still entering the final sprint trying to fully figure it out.

When thinking about what we can do to improve our group, a couple of ideas come to mind. One thing is that we can try to fix our issue with weights. We could try to improve this by giving some issues more weight than we think it needs so that we can account for actually learning what to do. A lot of times we have overestimated our knowledge, and it led to us taking longer on sprints than the listed weight. Another thing we can try to improve is our communication with outside groups. I feel like we think that we can only communicate with each other, but we can also reach out to our friends in other groups for help as well, and I think we have not taken advantage of that as much as we should.

I think that I can improve in many ways from this sprint. One way is by getting more familiar with Git itself, and prevent small mistakes, like with the first linked issue, from happening again. This will allow for us to not waste time on issues that do not require it, and get our work done faster. Another way I can improve is by reaching out to the GuestInfoSystem team for help with creating the test.sh file as they have done a ton of work with that in sprint two, and have got it up and running on their system. This will help us in getting that issue resolved for the last sprint. This sprint felt like night and day compared to the last one, and our group will only improve more with this experience.

Issue Links

1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/issues/8
2. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/98
3. 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.

For this sprint we decided to split up the work a little differently, as a group we agreed that we should switch what projects we were working on to get a better holistic understanding of the inventory system. This somehow led me to wanting to work on creating the entire inventory integration project here.

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

which completes this issue

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/79

I learned a lot during this sprint about the intricacies of each file and how they work with each other to create a working project and, at large, a system. I remember early on wanting to work on the frontend for the purpose of being able to work with visual design and UI but from working on the integration project I learned the skeleton and bare bones nature of what we are working on, even considered vaporware. Piecing this project together allowed me to realize what kind of work is required to have things up and running so I then realized I might have to hold off on wanting to work on that aspect of the front end, at least for now. What made it even more challenging was that I had to figure out how having multiple frontends changed creating the project as it was a bit different from other guest info and reporting. Even though I was able to use most of what other groups had, it required some time that was spent looking into the contents of the docker compose file.

Before I worked on creating the integration project I updated to the modern java script within the check out guest front end project, this issue was pretty straight forward and only required finding the right lines to change. Thinking that I was going to be working with the design and presentation I was mildly disappointed. I actually think that this issue and the integration project issue could have switched weight as making sure the integration project worked ended up taking much more time and research. The only thing that I think we can improve on is properly assigning weights to issues.

I think what is good is that a group member and I traded the scrum master position for the sprint, he did good and kept the team working well even through some struggles. It led me to wonder a little more about how other groups or even in the industry how people approach the scrum master position, even wonder how well a team functioned based on the certain characteristics of the scrum master. During this sprint we played around a little more with the projects that we were working on and even the structure of the class, which ultimately made working through the struggles that much more enjoyable.

This last sprint was a whirlwind of emotions and struggles for a variety of different reasons. While reflecting for some reason it appears to me that I felt the need to do individual work during this sprint, which probably isn’t the most productive idea while working with a team. There is a lot that can be taken from this;  I have a strong tendency to often go out and explore myself, that I should be a bit more cognizant of my own impulses, and that there’s always a good time for some play. I think I could’ve changed what I was doing so that I could help my group members with what they happen to be struggling with at the time, and that was something that was taken into the next sprint. Overall, this was a very enlightening and insightful sprint that helped me understand the work that it takes to develop software.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

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

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

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

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

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

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