Category Archives: Sprint-3

Sprint-3 Retrospective

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:

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:

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.

Retrospective Blog #3

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.

Sprint 3 Retrospective

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.

Sprint 3 Retrospective

 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.

Sprint 3 retrospective

As sprint 3 was a short cleanup sprint, we spent it doing some cleanup on the epics and issues board. During the sprint we were also trying to get a testing CI pipeline running. We ended up finally figuring that out after the technical end of the sprint, but I’ll be talking about that work here anyway.

As far as cleanup, I deleted a few remote branches in the GuestInfoBackend repo that had not been deleted when they were merged. I only deleted the branches that I knew had been merged, but now that I look at the other branches, GitLab indicates whether a branch has been merged into the main branch, so I will know which branches are clearly safe to delete this week in the backend, API, and frontend repositories.

I did some additional cleanup related to the status of features that remain in the product backlog. For example, I removed an indication that the upcoming Kubernetes conversion epic is blocked by the GuestInfoIntegration verification epic that we completed:

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

I helped Kelvin’s effort to get the GitLab test job to run our backend tests. For example, I made sure we were getting a copy of an openapi.yaml file that we knew would actually exist into the testing/test-runner/ directory while the test script is being executed:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/commit/4e869868f089f8eb1e1151759c656df5fd1bc248

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

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

It wound up being a bit harder than expected to get a value from bash into a YAML definition file being used to network the various docker containers. There seem to be a few more ways to do that when executing docker-run compared to docker-compose, so I figured out how to do that to get the right backend image name substituted into the docker composition for both the GitLab CI test job and when executing test.sh in a dev container:

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

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

I also verified that the test job is doing all the right docker stuff by making sure that broken unit tests and broken endpoints both result in failed tests in the test job:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/commit/3a8e84cb4e2a8571b8cbd52f02a4c801c95f1189

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

I think our team did a good job getting the tests to run in the CI pipeline this sprint. At the same time, putting a bunch of energy into a different branch than main may hive divided our energy a bit. Probably more important was that this was a short sprint with lower goals than the first two. Given the fact that during sprint 1 we didn’t really know what we were doing or how most of the architecture worked together, it might have been nice to have a shorter first sprint and then more time to work on this one, where maybe half or a third of the goals were cleaning things up.

Honestly, I don’t think it’s bad that trying to gradually wrap your head around a codebase is a big part of this class, as that’s going to be one of the challenges that people face in new working environments. The software construction & architecture prerequisite class does use the same architecture, but it’s easy in that class to build better understanding of how some of the individual parts work and an understanding of microservices and REST APIs. However, the devil is in the details, and understanding small integration details enough to be confident that contributions are correct is not easy.

One other thing I wish I did differently to help our team as a whole this sprint is trying to collaborate a bit with everyone. I feel a bit like I locked myself in the test-runner branch and wasn’t very present to help with other things.

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

Sprint Retrospective 3

I think this last sprint was a fitting end to the semester and at large a great CS course. The way we organized really resolved a lot of the personal issues that I discussed in my last retrospective. We all put our heads together and tackled these issues as a team.

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

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

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

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

After working on my own for a good bit of the last sprint, I was a bit concerned going into the next sprint working on testing as I felt I had some catching up to do. Fortunately, I had a great team that was able to fill me in on what I was missing and in addition to that reading up on documentation about chai testing and trying out the manual test on my own. I was in a position where I felt I could contribute to the team. Not only did we have great teamwork within the group we were also in a position where we could collaborate with another group as well which brought back a sense of contributing to something greater. I would say a big theme of this short sprint is that the sum of its parts builds something much greater. Another theme that emerged from this sprint is that everyone should be at the same level of understanding by the end. I feel as though I now have much more comfort with the workflow and even the projects themselves.

There were often many little feelings of accomplishments being made. Being able to share those accomplishments with the team just made it that much better and contributed to the good feelings. This sprint was a refreshing sense of reality and brought the joys of working on such a project even while things outside may feel a bit hectic. It even brought some joys to writing code that I have experienced before, the attention to detail is a greater skill that I have developed thanks to programming.

Nothing really comes to mind in terms of improvements that could have been made during this sprint. Maybe more comments on git lab could have been made but communication outside of git lab was pretty good so it wasn’t too much of a necessity. I could say that we could have documented the work we did so that people in the future could better understand the work that was completed. We might have relied a little bit too much on letting the next semester take on the problems but that is honestly a nitpick considering the work that was completed. If I had only this project to work on like how it may be in a professional setting, I’m sure that we could that much closer to a fully up and running usable software.

Even though a lot of personal improvements were made for the last sprint I think there is always some room for improvement. In the context of the Apprenticeship Patterns, I think it’s important to always work on self-improvement. Due to my last blog post and the nature of the last two sprints I have put some consideration in to working in a team setting. I don’t have any specific improvements that can be made but I’m sure with more thought that I can find something to work on and be that much better of a team player.

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.

Sprint Retrospective – 3

For our last and final Sprint Retrospective, we had a much shorter sprint, which made things quite a bit different from the previous two sprints! For one, it made things feel like much more of a time crunch, but at the same time, there was much less to do during the sprint.

Overall, despite only have about four issues, we still had a slight misweighting of one of them! But at least, we still had about a 75% accuracy in terms of our judgment! It could be much better at 100%, but it’s still much better than our sub 50% weighting of our first sprint.

Our biggest issues was working with making a testing suite in Chai. This was mostly the work of Andrew over the past few sprints, but since our last sprint had only a few issues, we were all able to jump on board. Sam jumped on first, since he was the most open, while Moses, Anesti, and I worked on more pipeline stuff! With a bit of luck, Moses cleaned out the pipeline issues, and so we all jumped on the Chai testing and… Boy, did it take a while to figure out. The main thing we realized was that our earlier sprints led to our downfall! Because we were less experience during our first sprint, we made mistakes to the Reporting System that made it so that our whole system was broken! But thankfully, we managed to figure things out by the skin of our teeth and get things resolve on the literal final day of our sprint! It was a close call, and to be honest, I think despite our mishap, it was within reason since we simply couldn’t have known what we did not know yet!

Overall, I think that our group did as well as could be expected, and as we developed as a team for the final sprint, we still were able to expand upon our abilities despite the short amount of time we had left. I think that our communication was at a high for the final portion, and if we could have kept going, I think we could have really done even more for the Reporting System. Regardless, I think we did well! Individually, we all steps up, and as a team, we all came together to help one another.

If I had to point to one thing that could have been done better, was to make sure that we verified our system before moving further on. Maybe as a side issue, someone could have checked over that the things we did in the past Sprints would not negative affected our future progress, but that would be a bit hard to do since we were still learning the ins and outs of the Reporting System. There might even need to be some sort of oversight, but I would consider this more of a nitpick than a real problem as we were still able to identify our problem thanks to our version history.

Since we didn’t have many issues, the only issues I had was This and then These were the collaborative issues.

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

Sprint-3

This is my final blog for the university, where I work hard for four years, hoping to become a software developer. The team and I finished most of the tasks for the project “Reporting. System”; it was challenging for our learning experience. There are struggles and realizations from mistakes and trials of multiple attempts that help and benefit understanding for further the learning experiences. Those learning experiences from the tasks were interesting and challenging to complete becoming more difficult than others for unexpected.

I am currently making a presentation and adding details from looking back at the tasks that the group and myself for how much we accomplished. Also, looking forward to graduation. After the team and I adjusted to the issue board required for the work and practice. I have done these issues over the semester for weight assignments that have been changed with a total weight of 2-3 is reasonable and practicable. Some are easy to do and understand, but others are challenging.

The Issue:

  • Remove MongoID leftover – Backend (changes). There are still MongoIDs available, and I will investigate this further. After I asked for feedback or assisted in making certain adjustments, the result seemed to be an improvement, and the team concurred.
  • backend — Write a test suite for API (changes); This activity writes tests in Chai, ensuring that the backend works with the API while ensuring you get a file back in .xls format (get the simple tests working).

My still challenge concerning one of these tasks is researching the topic of “Chai.” the topic is still questioning the existence of a library written in JavaScript with different test frameworks. It provides that your code continues to work as intended by attaching to the assertions set up. Like npm install chai, chai-HTTP, chai-as-promise, etc. Those additions make the process simpler, but it doesn’t look good. It has already gone through the potentially functional aspects, even after the review, code addition/construction, and code comparison phases.

After I got the chai working correctly, I learned the backend server kept shutting down due to missing files, leading to some codes not passing. The team and I backed up the system by going back to find those files and running for testing; the first half is working (the version number), and the second half won’t. (missing data from the database). 

For improvement, I prepare to find information about this issue from my group members and others by asking others who have had this experience issue before. Even though the team and myself ran into more mixed technical problems during the development process, like missing files, which resulted in more delays that shifted the focus on the specific problem. Even that problem can help us better comprehend and learn new specialties to avoid misleading and repeated attempts. 

In conclusion, in the third and last university sprint, our team had a good time discussing and executing the tasks, though we tried to do some things to perform wildly well after the second-Sprint. We still faced some obstacles that became a fun learning experience for new topics.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective #3

Hello Blog!

It’s time for my final sprint retrospective for Thea’s Pantry! 

For this third and final sprint, we were focusing on closing up issues related to the previous sprint and closing epics. My team was having issues with the automated testing and the test runner docker container. We were all previously working on our own tests, but because of everyone having errors with theirs, it was decided that we should all take the time to work on testing together to try to get at least one test working. And that we did.

The following are links for issues worked on, in collaboration with my team:

My team also tried putting our heads together to handle issues with the automated testing with test-runner, searching for any typos or missing components in the code that could be causing issues, and this work was also done in collaboration with another team.

What worked well was that we were able to spend this sprint working together more on issues and get through them instead of continuing to be stuck on several different issues at the same time like the last sprint. It also worked well communicating with another team working on similar issues especially when trying to handle errors they also faced so we could progress faster and get closer to tackling the issue.

I don’t think I have anything to say about what didn’t work well. I think communication was better this sprint than before and we all tried to look for things we missed in the code when trying to handle errors. I also don’t think I have anything to say for improving as a team. 

To improve as an individual, I think I could have spent some more time outside of class experimenting with the issues. Burnout and the buildup of outside commitments really hit me this sprint and the last, but I can work to improve my time and work management. Not too much time has passed since the last sprint retrospective where I said I hope to be more daring. I still believe that I need to work on being less afraid of breaking things when I make changes, but I do find security with how Visual Studio code shows some changes we made or displays some code before and after the change we just made. I also make notes of things I change to help keep track of what might mess things up, so I’m building my confidence with those.

This may be my last blog post, so “Good morning, and in case I don’t see ya, good afternoon, good evening, and good night!”

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.

Sprint 3 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/59 – This issue consisted of fixing up our tests and ensuring they worked.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/52 – We realized that we needed manual calls to be able to make sure that the call would actually be able to work before we tried to create the chai tests.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/54 – Same issue as issue 52

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/62 – Same as issue 59

This sprint was much shorter than most of our other sprints. We only had about a week and a half to actually work on the code within class, so this led us into working on the project outside of class more. This sprint there was also a lot more teamwork between the different groups, as we all were running into the same issues. The GuestInfo group were extremely helpful in helping us finally fix our test-runner docker container, as well as helping us fix some of the glaring issues that were riddling our tests. We did not go back to our old ways in the previous sprint, and we all tackled each issue as a whole group, which allowed all of us to have input and give possible solutions to issues. This worked well as it made the whole group feel like they were involved in the process and no one was left out.

I do not think I can point out anything that we could do better if there were to be another sprint. We all worked together well, we were in constant communication through out the whole sprint. This ensured that no one was lost on any of the issues we were working on, and everyone was on the same page as to what path we were taking to fix an issue.

I assumed my role as scrum master again this sprint, and I felt I did a good job at managing the whole group, communicating with the other teams to be on the same page when working in groups and working on a singular issue together. We did not have a discussion on who was going to be the new scrum master, but everyone just assumed I would take back over as the sprint was very short and we were not working on any new issues, just fixing the ones that we working on from last sprint. One thing that I could have improved upon is my time management skills. In class I felt I did a pretty good job at managing how long it would take to work on certain tasks, but when I am at home those skills seem to vanish. This is probably due to the many distractions while I am at home on my personal computer and my pets. The remedy this I could starting doing most of my outside work at my job, where I am left alone and kind of forced to work on my homework with no distractions.

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