Category Archives: Sprint-3

CS 448-01 Team 3 Sprint 3 Retrospective (5/7)

Following the very close end to our 3rd and last sprint, I feel like we really put in the effort to finish AddInventoryFrontend. As a team, we completed all of the issues that we were assigned as a team and meet up together for many in-person meetings in order to finally finish up some loose-ends.

One of the biggest things that we finished from last sprint was that we were to got AddInventoryFrontend working. Last sprint was very difficult because the code that we were working on was messy and we had to change a few different approaches to the Frontend since our original approach to create a wireframe which would eventually become the UI did not come together. For this sprint, we had updated our code to be able to finally string together the Frontend with the Backend, like changing around our directory, adding in key files to run the Frontend, and then test through trial and error our Frontend. We used our current wireframe in order to build our Frontend to what we ended up with.

For AddInventoryFrontend, I had worked on updating the Documentation of AddInventoryFrontend since I wanted to be able to contribute more in this sprint. When I looked at the documentation in its original state, I was dumbfounded to find that there were almost nothing there to begin with. It must have looked liked a template since it specified that the linter being used was called test.sh instead of lint.sh. Because everyone on my team was doing so much work on the Frontend and its functionality, I wanted to be able to contribute more as a member of the team, so I decided to modify the documentation so that it would reflect the changes that we made as as a team.

Unfortunately, we were unable to completely fix some issue that we had with our Frontend before the end of the sprint. Our Frontend works great and loads properly now that we have fixed it. If we had another sprint left before the end of the semester, we would have worked on optimizing our Frontend so that the button could work so that you can add and remove units of food from the inventory, and also keep track of how much food is in the inventory through a viewable parameter that would check in the database for the inventory amount. With that being said, any issues that we had with AddInventoryFrontend will have to be resolved next year.

As a member of our team, I definitely could work on trying to practicing some code so that I would be able to make changes that they made with the Frontend. The Frontend was not impossible for me to read since I have played around with HTML before, but I was still trying to figure out all the formatting for our Frontend so I took a good look at our code. I could tell that at the very least that we did our best with creating the Frontend with the little time that we had following our previous sprint, but I would like to not forget about the things we did as a team to create our Frontend. I think that I better understand how AddInventoryFrontend works because I did run the environment on my own. For our presentation, I really hope that we can talk more about how we got our Frontend to work rather than just listing out the issues that we did in our sprint.

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

Sprint 3 Retrospective

Activity on Gitlab (from oldest to youngest)

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

  • Worked on verifying correct linters are present/used, pushed branch and was merged later

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

  • Helped team by commenting details in regards to issue worked on as a group

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

  • Deleted branch to do some clean up at the end of the sprint

In the dynamic realm of sprint cycles, our team of five individuals embarked on a journey of collaboration, growth, and shared accomplishments throughout Sprint Three. As the semester progressed, we evolved into a more cohesive and efficient unit, leveraging our collective strengths to overcome challenges and achieve our objectives with confidence.

From the beginning of this sprint, our experience was characterized by seamless workflow, effective time management, and a strong emphasis on teamwork dynamics. Through a combination of collaborative efforts, individual contributions, and paired work, we navigated our sprint objectives with precision and determination, exceeding expectations within the designated timeframe.

Reflecting on our previous sprints, we collectively identified areas for improvement and implemented strategies to enhance our performance. One notable shift in our approach for Sprint Three was the refinement of our task allocation process and the adoption of a more strategic approach to problem-solving. Recognizing the importance of leveraging diverse perspectives and skill sets, we allocated tasks based on complexity and urgency, ensuring optimal resource utilization and productivity.

Furthermore, we continued to prioritize inclusive code reviews, fostering a culture of knowledge sharing and continuous improvement within the team. By conducting comprehensive reviews as a team, we not only enhanced the quality of our work but also reinforced our commitment to collective success. Paired work remained instrumental in our strategy, facilitating better communication, collaboration, and task completion efficiency.

Despite the inherent challenges of a five-person team, we maintained a cohesive and supportive environment throughout Sprint Three. Each team member actively contributed to discussions, shared insights, and collaborated with others to overcome obstacles. Our shared dedication to excellence and mutual respect for one another’s contributions fostered a positive team dynamic, elevating our overall productivity and morale.

Moreover, we remained focused on maximizing our time and resources by prioritizing tasks based on importance and feasibility. Setting ambitious yet attainable goals, we remained committed to completing at least 75 percent of our sprint backlog, ensuring progress towards our objectives while allowing flexibility for unforeseen challenges or revisions.

As we look towards future sprints, we are confident in our ability to build upon the successes of Sprint Three while addressing any identified areas for improvement. By continuing to prioritize collaboration, effective communication, and adaptive problem-solving, we are poised to further enhance our team’s performance and achieve even greater success in the upcoming iterations.

In conclusion, Sprint Three was a testament to our team’s resilience, growth, and unwavering commitment to excellence. Through strategic task allocation, inclusive code reviews, and increased paired work, we navigated our sprint backlog with confidence and cohesion, emerging stronger and more united than ever before. As we continue to iterate and refine our processes, we remain dedicated to driving innovation, fostering teamwork, and delivering exceptional results in all our endeavors.

From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.

Retrospective – Sprint #3

During this sprint, I contributed to 3 issues:

  1. Determine what needs to be done on GuestInfoFrontend – GuestInfoFrontend/issues/88
    (As a whole team, we explored the GuestInfoFrontend for any improvements, and created tickets for teams next semester)
  2. Verifying that InventoryAPI has the correct extensions, linters, and pipeline stages – InventoryAPI/issues/25
    (As a whole team, we reviewed and made changes to files in the InventoryAPI to ensure extensions, linters, and pipeline were all set for next semester)
  3. Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages – Inventory Backend – InventoryBackend/issues/101
    (3 of us reviewed and made changes to files in the InventoryBackend to ensure extensions, linters, and pipeline are all set for next semester)

Again, this sprint I also assisted in reviewing some issues for the team

This sprint was a breeze, all of us were comfortable working with most systems at this point and we were able to complete almost every one of the issues we set out to do. We did have a little hiccup with the GuestInfoFrontend as we were unsure of the process to start a backend and frontend hot reload instance after moving from Docker to Gitpod but after some direction from Professor Wurst, we were able to continue with our Determine what needs to be done on GuestInfoFrontend issue. Other than that we didn’t run into any problems over the duration of the sprint and we completed >75% very fast this time around too.

I don’t think that there is much or anything for us to improve on this sprint since most of the issues we worked on this sprint were team-collaborated issues we spent less time working on issues than in prior sprints since we were able to collaborate and fix any bugs with ease. Any of the issues that our team members did take on themselves, such were done without much if any assistance past peer reviewing, and overall the team worked like a “well-oiled machine” this sprint.

As a team, we killed it this sprint. We improved on our weak areas from our last two sprints and further solidified what we did well. I feel like communication can always be improved as we had made strides from our first sprint but I feel as if it had stagnated to an acceptable level for sprints #2 and #3. Other than that I can say there was anything that we should have done differently as we were on point this time around. Our in-person communication was a lot better than our discord communication but in the end, both weren’t bad at all, we just could have done better in some areas.

As an individual, I felt as if I could have worked more spreading the load of work since I feel that compared to our other sprints I had taken the least amount of burden of work this time around but if I look back to sprint #1 I feel that maybe it balanced out over the whole year since I felt as if I took on a large burden of work the first sprint so overall I think it evens out. I also could have been better at communicating when I will be on for calls as I had just joined when I could due to school and life just being busy so sometimes I joined Discord later than our usual time without explicitly communicating I would be doing so.

In the end, I feel as if this sprint had been our best yet since we had completed almost all issues (1 wasn’t completed), spread our burden of work, and communicated the best we had the entire semester. While there is always going to be room for some improvement, I feel that we had found our rhythm as a team this time around and we operated at our maximum efficacy.

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective Blog #3

Hi everyone, my name is Abdullah Farouk, for those who don’t know me by now, and this is going to be my first sprint retrospective of the semester. First, I will start out by saying, considering this whole thing is brand new to us, we did a great job working with this new style and adapted quickly to all the changes. Don’t get me wrong, there is still a lot of room for improvement from everyone in the team, but we successfully passed through this semester. This sprint consisted of us getting more familiar with libre food pantry more and to see how this scrum framework actually go and went more in depth into the actual system. The first thing we did in the beginning of the semester was weighing the different issues and breaking some epics into smaller issues and assigning it to our team. We then organized the issues on which one we wanted to do first and so on. I worked on most of the issues during class time, which worked out nicely because I had my team member there to help me with things just in case, I got stuck, which I did sometimes. I liked meeting in person instead of virtual meetings, as I think we do more work when we see each other instead of behind a computer screen.

One thing that I would say the we massively on was how we weighed the issues in the beginning. Compared to the first sprint, Some of the issues took less than what we had anticipated, and some took way longer, but this sprint we got it spot on and managed to finish all the issues on the board just in time. Another thing that we improved on was communicating outside of class time. I started privately messaging class mates for updates if they haven’t said anything in days. One thing we still didn’t do well was Some of the issues we had made, we didn’t add a description to it, so it was a little harder for me to figure out what they want me to do just from the title, so I had to ask classmate to double check.

Other than that one issues, I think me, and the team did a great job going through these issues and completing them on a timely basis. I worked on multiple issues for this sprint that I will list at the ends, but mostly I was trying to clean up code and made sure anything that I had left unfinished, was either finished or deleted so the next class is not having a headache trying to figure out why it’s there. I also checked a couple of my classmate’s issues that needed to be reviewed in order to merge to main. I also worked on. I also learned a lot about nodemon function and have a basic understanding of how it works and how to properly integrate it.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/29

  • Update CheckInventoryFrontend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/issues/25

  • Verifying that ReportingAPI has correct extensions and linters

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/27

  • Think and write down possible ways to further enhance the CheckInventoryFrontend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/26

  • Examine GuestInfoFrontend with its wireframe to see if there is any helpful code that can be shared

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

Sprint Retrospective #3

Overall, I believe the second sprint went well. Like the previous sprint, we had meetings in person or over discord. All in all, I believe we all did a fantastic job of keeping each other updated and asking each other questions when we got stuck. I noticed that once we finished one issue, nobody hesitated to start another issue which really helped us with moving the project along. During this sprint, we worked on several of the issues as a group. We kept up the open-mindedness, accountability, honesty, and respect that were originally described as the culture we hoped to establish in the working agreement. Like in the previous sprints, we determined the maximum amount of work that each person should attempt to finish in order to split the work fairly and equally in regards to the issues we had, and we mostly adhered to it.

I worked on multiple issues that involved verifying that the pantry projects had the correct extensions, linters, and pipeline stages. Like the last sprint, I looked over the project’s file types, created a list of required linters based on the files, added any new linters, verified that the new linters passed, verified which stages were required, and adjusted the stages as necessary. For this type of issue, I worked on “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages – InventorySystem General” by myself and then worked on “Verifying that InventoryAPI has the correct extensions, linters, and pipeline stages” and “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages – Inventory Backend” with the group. When working on the issue for InventorySystem General, I realized that the build and test scripts weren’t needed so I also removed those files. I also worked on “Determine what needs to be done on GuestInfoFrontend” with the group. For this issue, we reviewed comments left in the code, wireframe, and documentation. Then if any work worthy of note needed to be done, we created new issues for them. We created these issues (“Moving “Other Assistance” attribute” and “Moving Receiving Unemployment Attribute to Assistance”) and linked them to the initial issue. 

I think we did really well as a team for this sprint. We did not get around to establishing a method that will guarantee that particular individuals are not examining the majority of issues, as we had originally intended when drafting our working agreement. For this sprint, we did not discuss how we would make sure to stay on top of issues that needed to be reviewed because many of the issues included us working together and we stayed on top of a lot of the issues. The time frame between finishing an issue, reviewing, and merging was a lot shorter than the last sprint. We made sure to constantly communicate with each other and the first one that could review an issue took the task. As a group, I can see that we improved a lot in that regard but I still think we could establish a method to make sure that reviewing code is not done mainly by a few individuals in the group. As an Individual, I showed a lot of improvement by checking on what needs to be done compared to the previous sprints but I think I can still improve when it comes to merging my issues as quickly as possible after they’ve been reviewed.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

Sprint #3 Retrospective

What Worked Well:

Sprint #3 was our last sprint as a team and appeared to be one of our easier sprints since we were all familiar with our team workflow, who was doing what, and reviewing processes. In Sprint #3, we were tasked with completing seven different issues for a total weight of 25 points. As a whole, we completed six out of our seven issues for a total weight of 24 out of 25 points. We managed to complete many issues as a team, which was extremely helpful. By combining five minds, we could work in an efficient manner. Something worth noting was our communication this sprint. In all three Sprints, we conducted weekly meetings either in person or over Discord. Additionally, we had weekly standup meetings informing the group with what everyone was currently working on, doing next, or needs help with. I noticed that once we finished one issue, nobody hesitated to start another issue. This helped propel the project forward. Connecting all three sprints, Sprint #1 was a learning process, Sprint #2 was learning how to efficiently work with each other and complete tasks in an effective manner, and Sprint #3 was combining everything we have learned and putting it together. Sprint #3, whether it was our workflow, completing issue process, review process, or communication, we were able to combine everything and find success. One thing I particularly enjoyed was the comments we made on issues. Everyone on the team wrote comments informing the team what was going on within an issue, what the issue needed for completion, and any changes made to contribute.

Improvements As A Team:

We made some drastic improvements from the previous sprints in regards to how we took on work, the time we worked on it, our review process, and much more. Considering this is our final sprint as a team, I believe we are more than capable of bringing what we have learned into the workforce. To continue growing individually on our own teams, I believe it would be important to continuously build on communication. Regardless of the group or team we are on, it’s important to always provide updates, feedback, and details upon what we are working on, completing, any problems, any help needed, and so on. By continuously building on communication, asking questions, and continuing to refine and develop our skillset, we can set ourselves up for success in the future regardless of the team we are on. 

Improvements As An Individual:

During Sprint #3, I was able to work on four different issues. My first issue I completed individually and it was Update and Review InventorySystem/Documentation. This issue required me to go through the different files and add any files, comments, or updates, so that everything was corrected for future sprints. My other three issues I completed with my team included, Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the InventorySystem/InventoryAPI, Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the InventorySystem/InventoryBackend, and Determine what needs to be done for GuestInfoFrontend. For the Verifying issues, these involved adding and enabling the different linters in our system and testing their respective pipelines to ensure they passed. If they didn’t pass, we needed to go into their specific files to make changes to correct them. For the Determine what needs to be done for GuestInfoFrontend, involved the team building the frontend to view its contents and code. Here we created new issues for future sprints in regards to what needs to be completed, what can be changed or implemented better, and how we can improve the GuestInfoFrontend. For individual improvements, I’d like to continue being more of a team player where I’m open to help and support anyone on my team and voice my thoughts and opinions. Even if it’s just reviewing work and mentioning some tips or ideas, it can be extremely valuable. Additionally, when writing code or fixing documents, I’d like to add more comments. By doing so can allow anyone to understand my thought process while I’m working on issues. It would also allow other people to understand my work and not get lost or confused, allowing for anyone to contribute, add on, or provide feedback on what I’ve completed. Keeping that in mind, I believe it’ll help me grow as an individual and a teammate, and help me in numerous ways with my professional career.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective

Sprint 3 Retrospective

Introduction

  • In this sprint, our primary focus was on rigorously testing the frontend developed during sprint 2, applying the insights and frameworks we had discussed with team 2. This sprint appeared significantly shorter than the extensive sprint 2, partly due to the lighter workload with a target of only 16 points. This more manageable workload allowed us some capacity to address and rectify lingering issues from the previous sprint.
  • The brevity of this sprint highlighted the importance of continuous integration and testing, which enabled us to quickly identify and resolve issues. Our collaborative efforts with team 2 proved invaluable, as their feedback directly influenced our troubleshooting and refining processes. Moving forward, maintaining this synergy and applying these practices consistently will be crucial for smoothing out any future bumps in our development process and enhancing the overall quality of our project.

Links to Activity on GitLab

Reflections on the Sprint

What Worked Well:

The standout success of this sprint was our group communication. Facing challenges as a team, rather than individually, significantly eased our problem-solving process. Our review procedures were effective, facilitating a focused approach towards achieving our objectives.

Areas for Improvement:

The primary challenge we encountered was time management, particularly as progress on the front end depended on having a working template. This dependency delayed our efforts, resulting in a hectic sprint conclusion. Better planning or earlier template availability might mitigate similar issues in future sprints.

Improvements for Team Performance

The team’s collaborative communication and problem-solving were key strengths this sprint, continuing a positive trend from the previous sprint. It’s crucial to sustain this momentum into the next sprint, incorporating some strategic improvements:

Improvements for the Next Sprint:

  1. Consistent Scheduling: To avoid the congestion experienced towards the end of the last sprint, establishing a more consistent schedule for meetings could help in better time management and distribute tasks more evenly throughout the sprint.
  2. Balanced Division of Labor: We should continue to monitor and adjust the workload among team members to ensure tasks are evenly distributed, preventing any team member from being overwhelmed while others have less to do.
  3. Streamlined Communication Channels: Building on our previous success, maintaining all critical communications in a centralized, organized, and easily accessible system will enhance clarity and continuity, aiding in more effective decision-making and problem-solving.

Personal Improvements

Reflecting on my personal challenges during this sprint, specifically around managing merge requests correctly, I see valuable opportunities for growth:

  1. Proactive Communication: To prevent and swiftly address any uncertainties or errors in my work, I commit to being more proactive in seeking feedback and clarifications from team members.

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

Sprint 3 Retrospective

This was our third and final sprint for the semester and I believe we improved greatly when it came to working as a team compared to our previous sprints.We completed all of our issues during this sprint as a team during our various meetings which allowed us to collaborate more and learn about the project together. These issues included getting our frontend properly running in gitpod, figuring out which files were needed from guest info frontend and changing the existing scripts as well as updating documentation in order to leave the frontend in a good state for the next team to work on it.

Overall I did not have any trouble with working on any of the issues this sprint and I feel as though our collaboration on the issues helped us complete them more efficiently. The issue we worked on regarding getting the frontend to run in gitpod was straightforward and we were able to complete it without much delay as we were able to effectively reference the guest info frontend as it was already able to run in gitpod. The second issue that we worked on as a team regarding the addition of more frontend files/file structure and changing the scripts also went well and we were able to complete that as a team without any major issues.. The final issue we worked on as a team included updating the documentation which was rather easy to complete as a team as we had good references and experience with documentation between all of us. We had two other issues regarding making a confirm page but we were not able to finish those during the sprint as we did not want to leave unfinished work for the next team to have to deal with.

We did not have many problems during this sprint and I feel as though we all improved and worked together efficiently as a team. We all attended every meeting that we had scheduled and we all contributed directly to the project through code, documentation etc. The more collaborative nature of the work we did this sprint with each issue relying on the previous issues being completed first allowed collaboration to be a vital part of the process as we were able to finish issues in a timely manner when having all of our ideas going towards the completion of each issue. I feel as though we were all able to draw on one another’s strengths when working during this sprint which is something we were lacking slightly in the previous sprints. We also improved even more when it came to usage of Gitlab as we are all more experienced in both gitlab and gitpod now and able to understand the processes used as well as the workflow. The two issues we were unable to complete regarding a confirmation page are set up so that the next team can work on them when they begin their first sprint and we made sure to update the wireframe along with the documentation to provide the best start possible for the next team.

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

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/12

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/48

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/51

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

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/49

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

Sprint 3 Retrospective

 


In Sprint 3 I worked on finishing the checkinventoryfrontend. With the
shorter time of the sprint, I went to work on fixing an issue I encountered
in the previous sprint where the frontend would only display an error
message saying that there was some problem in the html. At the same time I
was trying to figure out how to get npm to work in the new file structure,
since when I try calling npm in the terminal it kept failing. For the
longest time I couldn’t figure out how to get the frontend to display
correctly, trying all sorts of solutions from moving the package.json file
around to deleting the deprecated yarnlock file. Eventually, I settled on
figuring out how to change the npm files to allow npm to reach the new
frontend folder I made. At some point, Jason asked if there was anything the
rest of the team could work on in checkinventoryfrontend, and I said the
documentation needed to be updated and that nodemon needed to be
implemented. Jason then created a separate branch based on mine called implementing-nodemon, where he changed the package.json and gitpod.yaml files to have nodemon
and other dependencies. 

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/tree/implementing-nodemon?ref_type=heads


Somehow, over the course of these dependencies being added, the frontend
started working again. The error must have been rooted in one of the
dependencies not working properly, or something to that effect. I looked int
o the changes Jason made, and he added a section to the gitpod.yaml that
would of implemented certain npm dependencies.


https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/commit/997bd2bd2197def31c8ae29efea071f9d07e077f


 Either way I’m just happy to be able to finish up the work in the
frontend. I went into Jason’s branch and cleaned up some of the shell files
so that they work as intended. The frontend-dev-up.sh file needed to use
frontend-dev instead of dev since that is what npm recognises in this repo.
Also, frontend restart needed to use the proper name of frontend-prod-down
and up.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/commit/480596810546e3286f8821d24cafe68bcd0fc1df

Then I started on cleaning up my own work for the next semester. I removed
the branches I had created since they either were redundant or straight up
didn’t work. Then I cleaned some deprecated files out of the implementing
nodemon branch while I was fixing the shell files, like an extra package
json file that was created in the base repo. 

I learned a lot about working with the frontend throughout this sprint, and
the entirety of the semester for that matter. I definitely want to brush up
on how npm works and functions, because I feel like most of my problems stem
from a lack of understanding. I also want to give credit to my team, who
have helped me out more than they realize, especially since I have been
balancing my work and school life. Hopefully the final presentation
represents all of our efforts over the semester.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

 


In Sprint 3 I worked on finishing the checkinventoryfrontend. With the
shorter time of the sprint, I went to work on fixing an issue I encountered
in the previous sprint where the frontend would only display an error
message saying that there was some problem in the html. At the same time I
was trying to figure out how to get npm to work in the new file structure,
since when I try calling npm in the terminal it kept failing. For the
longest time I couldn’t figure out how to get the frontend to display
correctly, trying all sorts of solutions from moving the package.json file
around to deleting the deprecated yarnlock file. Eventually, I settled on
figuring out how to change the npm files to allow npm to reach the new
frontend folder I made. At some point, Jason asked if there was anything the
rest of the team could work on in checkinventoryfrontend, and I said the
documentation needed to be updated and that nodemon needed to be
implemented. Jason then created a separate branch based on mine called implementing-nodemon, where he changed the package.json and gitpod.yaml files to have nodemon
and other dependencies. 

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/tree/implementing-nodemon?ref_type=heads


Somehow, over the course of these dependencies being added, the frontend
started working again. The error must have been rooted in one of the
dependencies not working properly, or something to that effect. I looked int
o the changes Jason made, and he added a section to the gitpod.yaml that
would of implemented certain npm dependencies.


https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/commit/997bd2bd2197def31c8ae29efea071f9d07e077f


 Either way I’m just happy to be able to finish up the work in the
frontend. I went into Jason’s branch and cleaned up some of the shell files
so that they work as intended. The frontend-dev-up.sh file needed to use
frontend-dev instead of dev since that is what npm recognises in this repo.
Also, frontend restart needed to use the proper name of frontend-prod-down
and up.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/commit/480596810546e3286f8821d24cafe68bcd0fc1df

Then I started on cleaning up my own work for the next semester. I removed
the branches I had created since they either were redundant or straight up
didn’t work. Then I cleaned some deprecated files out of the implementing
nodemon branch while I was fixing the shell files, like an extra package
json file that was created in the base repo. 

I learned a lot about working with the frontend throughout this sprint, and
the entirety of the semester for that matter. I definitely want to brush up
on how npm works and functions, because I feel like most of my problems stem
from a lack of understanding. I also want to give credit to my team, who
have helped me out more than they realize, especially since I have been
balancing my work and school life. Hopefully the final presentation
represents all of our efforts over the semester.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.