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.

During sprint 2, our team set a clear goal to maximize our production and efficiency. We aimed to complete more issues than we did in the previous sprint and were highly motivated to achieve this target. As a team, we analyzed our previous sprint’s performance and identified areas where we could improve. We realized that we needed a more effective approach to tackling our workload to achieve our goal of maximum productivity. To ensure that we were working efficiently, we focused on prioritizing our tasks. We spent time looking over all the current and new issues, and we carefully ordered them based on their urgency and complexity. Our strategy was to tackle the easier and more pressing epics first, before moving on to those that would take longer to complete. This approach helped us work through our tasks systematically and efficiently, ensuring that we did not waste time on issues that could be dealt with later. We also made a concerted effort to communicate better as a team. We set up regular meetings to discuss our progress and brainstorm ways to overcome any challenges we encountered.

During the second sprint, the first issue I was tasked with was, removing the openapi.yml file from the project’s documentation folder and deleting the build.sh command as they were no longer necessary. To ensure that my work was aligned with the team’s goals, I communicated with them before proceeding with the deletion and tested the project to confirm that everything was functioning properly. Streamlining the project’s structure in this way improved its efficiency and reduced the likelihood of errors occurring. The second issue was a small issue that we had inadvertently created during sprint 1. The issue involved adding a missing opening bracket to a call.http command. Although it was a minor fix, it was important to ensure the proper functionality of the command. After reviewing and addressing the issue, we ran tests to confirm that the command was working correctly. The third issue that I worked on was to make sure the correct types were used and to accomplish that I reviewed the codebase to ensure the correct types were being used to maintain the project’s high standards of quality and performance. The Forth one was to make sure API is complete and to accomplish that I had to go through the code again sure it’s good. The fifth issue I worked on is to design a comprehensive unit test for the guest retrieval process. The test was designed in a way that it returns code 200 for successful retrievals and a code 400 for non-existent guests. During the Third sprint we will be working on cleaning up and make tests better that were done during second sprint. As an individual I am happy with how much issues we were able to fix during second sprint.

During sprint 2, our team made significant progress and successfully resolved multiple epics. We identified which epics we plan to complete by sprint 3 and decided to leave the frontend issues to a subsequent team. Our teamwork and commitment to quality were evident throughout the sprint.

Links:

1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/issues/108 (Deleted openapi.yaml and build.sh files)
2. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/85 (Added “{“ to calls.http file)
3. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/issues/101 (Determine if correct types are used)
4. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/issues/98 (Determine if API is complete)
5. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/78 (Design Unit test for retrieve guest)

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.

Now that sprint 2 is completed it is time for another retrospective. My team implemented some of the changes mentioned in our sprint 1 retrospective and I believe they were good for us. After completing sprint 2 we found some things we could improve in order for sprint 3 to be more successful.

Something that worked well for us was changing up who worked on what. We took the problem we identified in our first sprint and came up with a solution. In sprint 1 each team member only worked on a single project within our front end for all the issues. Doing this did not allow our team to become diverse and adaptable when we only stuck to one thing. For this sprint, we made sure to change our roles which was a positive for the team. Everyone got to work on something new instead of sticking with the same project they worked on in sprint 1.

Something that our team could improve on is how we break down issues. I actually think we did not do quite as well with breaking down issues as we did on our first sprint. Our sprint started off strong and the first few issues were broken down and weighed well but later we had a problem. For our testing issues, we did not break it down nearly enough. We thought creating the test would be simple enough but creating the test turned out to be more difficult. We split the issue by which test it was for instead of the steps needed to complete the testing. This was a mistake because as individuals it was a lot to try to take on at once. We ran into a lot of issues and then trying to share what we did to get past each issue and play catch up with each other still made things difficult. For our next sprint, we need to either work as a team to tackle a large problem or break down these larger problems into smaller chunks.

Since we switched up jobs for this sprint I mostly worked on the backend of the inventory system. The issues I worked on are the following:

My first issue was updating the JavaScript in the backend to modern JavaScript

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

My next issue was creating the test for getInventory

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

As an individual, I believe I could improve by getting a better understanding of how the project works as a whole. While working on my tasks, I only looked into the pieces of the project that needed to be worked on. I think going through the project more thoroughly and understanding what does what could have made fixing some of the issues easier. 

Overall I think sprint 2 was a good experience for the team. We took our changes from sprint 1 and implemented them for sprint 2 which was a good change for the team. We found some more weaknesses that can easily be adjusted for sprint 3. With multiple chances to update our strategy, I expect that sprint 3 will be even more successful than our previous two sprints.

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

For this sprint, overall, the team work significantly better. Not only did we continue to communicate well with one another, but there was a lot of improvement because we were much more experienced with the project. Not only were we more familiar with the coding side of things, but since we had a much firmer understanding of SCRUM as a whole, it allowed us to skip through a lot of the learning process that happened in the first sprint and get right to work instead.

For one, we had accurate weights for almost all of our issues. This is a huge contrast with Sprint 1, as Sprint 1 was littered with issues that should have been weights of 2-3, but instead they were 1s. With this more correct weights, we were able to delegate a lot better, and we also were just more aware of the types of problems we were facing. In Sprint 1 for example, I had moments where I picked up a ‘1’ weight issue, only to be stuck on it for almost a whole week or more because I had to learning about how things worked. Now in Sprint 2, because I can skip a bit of the learning, since I had already did it during Sprint 1, many of the ‘1’ weight issues were actually ‘1s,’ thankfully!

On top of being more familiar with the code and the SCRUM process, we realized that we as a team, did not focus on the issues as heavily as we should have. Although we worked as a group somewhat in Sprint 1, Sprint 2 was much much more collaborative. We realized that the system is a lot more interlocked than we realized, and because of that, if Sam was working on one portion of the API, Moses might have insights, or vice versa. Many instances of issues being tackled was one of us starting it, and another member jumping in and finishing it together.

Other than the improvements in understand and our teamwork, I tackled setting up the Reporting Integrations repo. I figured that since everyone was working on the API, Backend, or a mix of the two, it would be a bit easier for me to tackle the creation of a whole separate part of the Reporting Systems. I think, this was for the best because although help might have useful at times, overall, I was worried that since the Reporting Integrations was going to be made from the ground up essentially, it would become a situation of too many cooks ruin the pot. I am glad I did this because once I set up Reporting Integrations, I had a very solid understanding of the different tools that we used such as the Pipeline, and with that understanding, I was able to help much of the team with some issues.

Pipeline updates
Reporting Integrations
Multi-Architecture Conversion Backend, Frontend, Swagger CLI

After that, things became much smoother as people collectively got a hold on the issues, and though we are still lacking experience in many areas, it feels like we have a better grasp on everything as a whole. I think that moving forward, we should keep our pacing, and improve our communication even more potentially. I do really enjoy how we are much more collaborative on the different issues, and though sometimes we have to focus on our own task, the team work aspect is very refreshing and helpful. We are almost like each other’s rubber ducks.

Somethings that still aren’t too good is that we still only focus on working together when we are face to face, but I think that is overall fine. It could be better if we paired up, or had meetings outside of class and would make things smoother, but things are passable. Also, this isn’t exactly our whole responsibility either!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

The goal for sprint 2 was to maximize our production. The team and I wanted to get more issues done, at least more issues done than the last sprint. Compared to the previous sprint, we got way more issues and weight done this time. What worked well for us this time was to look over any current and new issues and order them so that the easier/urgent epics were done first, and then we set aside the epics that would take a little bit longer. 

The first issue I started to work on was refactoring the API file directory structure and infrastructure. So the first issue I tackled was collapsing all “YAML contents in /specification to a single/specification/open API.yaml file.” After that, I worked on disabling the build stage in the .gitlab-ci.yaml, which was pretty easy for me because I did a similar issue while working on the guestinfointegration, and I also worked on modifying the test.sh to validate the open API.yaml.

The second epic I worked on was to “Convert all Docker images to build multiarchitecture images” To complete this, I had to:

• Modify the build.sh to specify which image to build.
•  Use the variable PIPELINE_IMAGE_PLATFORMS in the “GitLab-ci.yaml” variable to identify the platforms for which images must be made.

 I worked on the front end while my other team member did this to the backend. We could quickly get this done using the information in multi-platform.md.

After getting these two epics done, the remaining epics we had were ones that we could only complete partially in sprint 1. The next epic we wanted to achieve was the Evaluate and Improve API epic. The work I did for this epic included the following:

• Making sure the values of the API were used correctly.
•  Determining the HTTP methods was correct.
•  Making sure the endpoint to return the correct API version was correct.

Finally, we could get back to backend testing after evaluating the API. A big problem we faced was how to test HTTP methods in the first place, so while doing some research, I found a plugin called “Chai-HTTP,” which allowed us to test HTTP requests using the npm test script that Liam provided in the first sprint. While we still needed to figure out how to get the test runner to work with Docker, having the ability to work on the test without having the test runner was an excellent way to get everyone involved in this epic. I was able to work on designing a test to create guests and list guests. And the test runner that will allow us to run these issues is currently being worked on with help from Noelan from the Inventory system since they are also trying to get it up and running. While developing the test runner allowed me to get more familiar with Docker.

As an individual, I am delighted with how I did this sprint and hope to ride this wave onto sprint 3. I planned to get two or more weights done weekly and ensured a specific timeframe to finish most epics in the team. Unfortunately, we didn’t get backend testing done, but I’m more confident that in sprint three we will complete it now that the test runner is almost done. 

As a team, we need to figure out a system so that everyone can lend a hand. Especially towards the end, we only had a few issues, or sometimes we would have to stop production because of one issue. In this case, it was the test runner for the backend. I’m hoping this will be avoided in sprint 3. 

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

Hello blog!

Sprint 2 has come to an end and it is now round 2 of sprint retrospectives. This sprint was a little different from the first sprint, where our issues were similar amongst the five projects and we all took one project. Instead of one person having to take on all issues for InventoryAPI, they were able to take on frontend work, or whatever was available. This was a change based on what we discussed during the first sprint retrospective–that we should rotate around what we’re working on rather than being stuck in one project. 

The first two issues I worked on were for AddInventoryFrontend:

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/merge_requests/12. I added code to .gitlab-ci.yml and build.sh to convert Docker images we are building into multi-architecture images.

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/merge_requests/13. I went through the JavaScript files updating them to modern JavaScript by applying “use strict” and checking if there were any variable declarations I could change from var to let or const.

The following issue is what resulted in the greatest struggle:

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/merge_requests/26. I tried to get the manual test done for getApiVersion so I could write the automated testing in Chai for it but ran into countless problems.

I think what worked well was that in the previous sprint there was the suggestion of changing projects for teammates since they did not want to stick to one of the five projects the whole time, and teammates did swap where they were working. We were also able to help each other out well for a few issues since we all had similar things to change.

What didn’t work well was that we did not gauge well enough how to weigh the tests. We did believe that it would give us issues, but not to the extent that it did. The backend tests should have been split into manual testing and automated testing in Chai since just the manual testing was giving issues that took a long time to address. It was also an issue that almost all of us were making changes to InventoryBackend at once and getting errors from different sections that were fixed by one person but another person was not informed. 

To improve as a team, we could definitely communicate more on errors we have received and what we’ve done to fix them–as soon as we reach them. There are times when some teammates further ahead have gotten errors and fixed them somehow, but forgot what they have changed or updated. Doing so would be of great help for reference and also just good practice. We could also improve as a team by finding more time to work together, like the testing issues for example, since we were all in a similar position, and everyone collaborating on one test first would definitely push us forward. We all have busy and differing schedules so it has been difficult lately, but it can be an improvement.

On the topic of improving as an individual, I still have a fear of breaking things, so I should work on being less afraid of making changes. This sprint I’ve experimented a lot with trying to fix the errors I received trying to get my manual getApiVersion test to work. There were countless changes I made that ended up not making a difference, or would trigger the same error under different conditions. So while I did make efforts to be more “daring”, I could still use some more work on that. I think what scares me more is entering commands I’m not familiar with at all in the terminal, but that can just be an instance of reading more into them.

This sprint felt like a call to be more communicative with my team and also a call to communicate outside of the team with those who have worked on similar issues.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.