Greetings everyone, I hope you all had a fantastic spring break. As we begin a new week, I wanted to take a moment to reflect on the recently concluded sprint 1. Undoubtedly, it was a unique experience for all of us as we delved into the real-world work environment. For many of us, including myself, it was a significant learning curve as we navigated the intricacies of our new job. However, I firmly believe that the challenges we faced during sprint 1 provided us with an excellent opportunity to develop our skills and learn from our mistakes.
Personally, I found myself drawing on the knowledge I gained from my computer architecture class in the fall of 2021. Although there was a long gap between that class and my current class, I was able to recap the essential concepts I learned in the CS-343 class, which proved to be incredibly helpful in my work. As we move forward with the next sprint, I am confident that we will continue to learn and grow, both as individuals and as a team. Let’s take the lessons we learned in sprint 1 and use them to make even greater strides in sprint 2.
As a team, we faced challenges during the first sprint, needing more time to learn how things work. However, we did our best to adapt and make progress. Moving forward, we will continue to improve our work process and complete tasks efficiently. During the first sprint, I faced an initial hurdle with getting visual studio code and docker to work on my new laptop. Fortunately, my Scrum Master and Professor were extremely helpful in guiding me through the process, and I was able to overcome the issue with their assistance.
After resolving the initial challenge, I was able to focus on other aspects of the work, and I quickly identified a pattern that required my attention. I noticed that the variables in the code were being declared with ‘var,’ even though they did not change throughout the program. Thanks to the previous team’s efforts, I was able to change these variables to ‘let’ or ‘const’, in a little amount of time. The second issue that I encountered during the sprint involved removing MongoID from guestinfoAPI. To accomplish this, I had to delete the MongoID schema from the schema folder and remove the schema from the Index.yaml file. With these changes implemented, the guestinfoAPI was updated and functioning as intended. To resolve the third issue, I updated the code in the Dockerfile to replace the existing Swagger CLI image with a multi-architecture version. This was done to ensure that there were no issues running the code on my M1 laptop and to ensure compatibility with other devices. By using a multi-architecture version, the code could run smoothly on different architectures and avoid any potential conflicts or errors.
To improve team performance in the next sprint, dividing the workload efficiently is crucial. This will ensure that tasks are assigned according to each team member’s skills and expertise, leading to a streamlined development process and successful outcomes.
Links to GitLab issues:
- https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/62 “Change ‘var’ variable declarations to ‘let’ [or to ‘const’ when they don’t ever change]”
- https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/merge_requests/92 “Remove MongoID schema for GuestInfoAPI”
- https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/merge_requests/93 “Replace swagger-cli image with multi-architecture version”