Category Archives: CS-448

Sprint 1

During this sprint it was very much of a learning process there was a lot of things that we had to do to first get used to working with teamsters and also with figuring out the scrum since it was the officially first time we were working on it as a “professional “ setting. As we worked together, we learned what we could do better in the next sprint. One of the things that we changed how we reviewed and worked on things. During some of the issues, we would assign a review and then have the review, review it, mark it as done and then have the original person that worked on it merge. That we learned took more time and there was more margins for error, therefore we decided that the reviewer would review and then they would just merge it and mark the issue as done. Another thing that we talked about improving on the team is communication, over all we had good communication but here and there we would forgot to say something about what we did and we had someone work on it doubled. Another thing we decided to do during this spring is when issues arise about during something we are working on to send it in the group or keep it in writing so that when it is time to come up with issues we have those to go back too. Since this time around when we were done with the sprint and it was time to write new issues we spent a lot of time going back and refreshing especially for the things that were in the initial part of the sprint. As an individual, I am trying to work on your review the issues as soon as it gets tagged. Sometimes it is hard because of my work schedule but I am trying my best so that if something does need to get fixed, that can be done as soon as possible so that we do not get behind. I think that this sprint even though we have more issues it will run more smoothly since we now know how the structure is and how it is supposed to go. A lot of last spring was figuring if the structure was right and if what we were doing was right. But now I feel more comfortable.

This was the issue that was used to plan out the test to make sure that the front end is compatible with and user friendly for this I had to do some research.

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

Like the one above this was our non program ones, where we researched and came up with ways to enchance the checkInverotryfrontend

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

This issue was to move commands and make it bins, we had a few of these and we separated it to team mates, mine was the ReportingAPI

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

This issue was set up to work with VSCode in Gitpod, since before we used devContainers, this was to switch it to gitpod

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/issues/32

This was one we worked as in a group and thought that it was going be easier ended up being harder than we thought there for it carried on to the second sprint

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

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

Going into our first sprint, not only as a team together but as each of our first sprints individually, we were all on the same page with similar expectations. Those being that we would equally know just as little as each other. This mentality was good to have when we ran into issues that we knew ahead of time would take working as a team to solve. We had no idea what those issues would be, just that there were going to be plenty as this was a learning opportunity for each one of us.

Our team was tasked with setting up AlexJS linter and Gitpod extensions in select repositories in Thea’s Pantry. We tackled these tasks by dividing the work between us so that we would work primarily in one repository, with mine being the GuestInfoSytems/GuestInfoFrontend. This only worked for 3 of our members with the 4th having to work in a different repository for each issue. Looking back on this, only working in one repository makes working individually more organized but, as we found out later, would lead to less cross referencing and things being missed.

Other issues our team tackled during the sprint involved frontend testing. First we worked together to do research on open source frontend testing software that could be used in our project. This led us to understand how frontend testing works and what tests should be expected. With this knowledge, we investigated the frontends that were available to design the test that would need to be built in a later sprint.

What Worked Well:

Our team collaboration was by far our strongest feature. With all of us willing to work together and communicate, we were able to make sure that we all stayed on the same page throughout the sprint. Our team stayed in constant communication throughout, even in between meetings. This meant we could communicate times for meetings well ahead of when we wanted to have them, while still being flexible if something came up. When we were working together in a meeting it was either in person or over a discord call. These calls sometimes went on for hours. However, no one let that bother them when it came to getting the work done and sticking around to make sure we all understood what was going on.

What Didn’t Work Well:

The most notable issue we ran into was the weights of our issues. While on paper the issues seemed trivial, what we didn’t account for was the complexities of learning Gitpod and Gitlab. Navigating gitlab and handling pipeline commit message issues lead to the majority of the long nights and ultimately meant that none of our weights should have been a 0.

Team Improvements:

We were all working on the same or similar issues in different repositories meant we could do them together simultaneously. This led to all of our work this sprint being done during the calls with only minor issues being handled individually. While this made the work way more digestible at the start, it is important that we are able to handle issues individually in the future when we have to work on issues that don’t all align with each other’s. 

Person Improvements:

I noticed that a lot of, if not all, of my questions were answered in the documentation provided in the repository I was working in. Moving forward I am going to do better at fully looking through the documentation and files to get a better understanding of the project and how to approach issues.

Gitpod Issues:

Setup Gitpod environment and settings for GuestInfoFrontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/85

Issue to change commands to bin in GuestInfoFrontend was fixed prior to the sprint:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/82 

Worked on adding the AlexJS linter to the pipeline for GuestInfoFrontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/81 

Researched open source frontend testing software:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/86

Designed tests for GuestInfoSytems/GuestInfoFrontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/87

Designed tests for InventorySystem/CheckOutGuestFrontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/36 

From the blog CS@Worcester – CS Learning by kbourassa18 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective Blog

As the first sprint EVER, it went very well, and it provided significant learning opportunities.

Our team exhibited strong collaboration throughout this initial phase. Effective communication was a cornerstone of our approach, enabling us to schedule both online and face-to-face meetings efficiently. A testament to our collaborative spirit was achieving our target of completing more than 75% of the tasks by the sprint’s end. This success largely stemmed from our commitment to weekly in-person meetings, fostering a united team environment crucial for addressing new challenges and workflows.

Despite these positive aspects, our journey was not devoid of hurdles. We encountered several setbacks, primarily due to our collective inexperience with GitLab and its workflow processes. Initially, we struggled with navigation, issue postings, and branch creations, leading to confusion and delays. Our approach to merge requests and the subsequent review process also proved problematic, culminating in merge conflicts and pipeline failures due to our wait-until-the-end strategy.

In light of these challenges, we aim to refine our approach in the upcoming sprint. We plan to create a “Workflow tips” document, compiling our experiences and solutions from this sprint to circumvent similar obstacles in the future. We intend to adopt a more proactive review process for issues and streamline our approach to merge requests, ensuring they align with workflow requirements.

Reflecting on the obstacles I encountered this sprint, there are several areas for personal improvement:

Enhancing GitLab Skills: I recognize the importance of becoming more proficient with GitLab. I intend to invest effort into understanding its intricacies, especially concerning branch management, handling merge requests, and connecting issues. I plan to utilize online resources, seek guidance from tutorials, and lean on my peers for support to enhance my competency.

Strengthening Communication: Acknowledging the need for improvement, I aim to enhance my approach to communication. I will take initiative to seek out feedback more actively and clarify doubts promptly with team members and mentors, aiming to resolve issues before they escalate.

Boosting Organizational Capabilities: I understand that better organization is key to avoiding past mistakes. Therefore, I am committed to honing my organizational skills, particularly in keeping track of my tasks, associated merge requests, and issues. Employing project management tools or maintaining a personal task tracker will be instrumental in keeping me in sync with the team’s goals and deadlines.

Links to the issues covered in this sprint:

Create Integration and Pipeline

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/integration/-/issues/1

Settings and extensions previously located in the dev container should now be transferred to .vscode/settings.json and .vscode/extensions.json within the Gitpod environment, as outlined in the .gitpod.yml documentation. Furthermore, developer commands should be moved from the commands directory to bin to align with standard Linux conventions, necessitating updates in script paths and .gitlab-ci.yaml environment variables. Additionally, integrate the AlexJS linter into each project’s pipeline and the bin/lint.sh script, ensuring all documentation is checked and updated accordingly.

Familiarize ourselves with guestInfoFrontend to understand what goes into CheckoutGuestFrontend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/37

This activity served as an introduction to the primary objectives of sprint 2. During this phase, we collectively reviewed the current wireframe for the checkout guest front end to familiarize ourselves with the anticipated design layout.

Refactor commands folder to bin

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/gitlab-profile/-/issues/69

This process entailed establishing a bin directory within the project and transferring three scripts from the template project into this new folder. Following this, I conducted tests on each of the three scripts to verify their functionality.

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

Building Skills with “Breakable Toys” Week-6

Cultivating Skills in a Safe Space:

“Breakable Toys,” a pattern from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, advocates for the creation of personal projects or ‘toys’ that can endure failures. These projects offer a sandbox for experimentation, where learning and mistakes occur without the high stakes of a professional environment. This pattern underlines the significance of having a personal space to apply and test new skills and knowledge in a tangible, yet forgiving, setting.

A Concept That Inspires:

While I am yet to embark on a professional career in software development, the idea of “Breakable Toys” strikes a chord with me. It appeals to the part of me that believes in the power of hands-on experience and learning through doing. The notion of constructing a personal project where the risk of failure is not only permissible but encouraged, is both liberating and exciting, especially for someone preparing to enter the tech industry.

The Freedom to Experiment:

What I find most intriguing about this pattern is the emphasis on the freedom to experiment, innovate, and yes, even fail. In the realm of these personal projects, the usual barriers and fears associated with failure are reduced, paving the way for creativity and exploration. This approach makes “Breakable Toys” not just a learning exercise, but a crucible for innovation and self-discovery.

Anticipating Its Impact on Learning:

The concept of “Breakable Toys” has already begun to shape how I envisage my approach to learning and development in software engineering. It reinforces my belief in the importance of engaging in personal projects as a fundamental part of my learning journey. This hands-on practice will be key to transforming theoretical knowledge into practical expertise.

A Balance Between Play and Purpose:

While I am enthusiastic about the potential of “Breakable Toys,” I also recognize the importance of balancing these personal explorations with goal-oriented learning. It’s essential that these projects are not just about exploration but also about advancing specific learning objectives or developing particular skills.

In conclusion, the “Breakable Toys” pattern presents a compelling approach for anyone aspiring to grow in software development. It highlights that mastering this field involves not just structured learning but also unstructured, creative experimentation. By building and experimenting with personal projects, one can cultivate a deeper understanding and a more versatile skill set, all within a context where failure becomes a stepping stone to innovation and mastery. This pattern celebrates the idea that sometimes, the most valuable learning experiences come from the freedom to break things and learn in the process.

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

Sprint Retrospective

Sprint 1 Retrospective

Introduction

  • In the first sprint we were mostly focused on learning the ropes of gitlab and getting familiarized with the sprint structure.
  • This sprint lasted for 5 stand ups which is equivalent to 2 and ½ weeks. This ended up feeling a bit cramped considering the amount of learning that was necessary for this process.

Links to Activity on GitLab

Reflections on the Sprint

What Worked Well?
  • In this sprint I found that communication as a group was key to our success. Any problems that we faced were made much easier when we tackled them as a group instead of alone. I think that our review process was good and we just need to make sure we keep logs of these reviews in the appropriate discord channel.
What Didn’t Work Well?
  • I think that the main thing that we struggled with was learning how to use this new environment and process. I think that this caused lots of issued especially with multiple people working in the same projects and all being confused about what to do, This lead to issues with people creating branches in the wrong issues as well as people accidentally doing issues for other teams. I personally struggled with making sure the right merge request was linked to the issue and will try to improve this for the next sprint.

Given the detailed account of your Sprint 1 Retrospective, let’s complete the remaining sections with reflective insights and forward-looking statements based on your experiences and observations.

Improvements for Team Performance

The team’s ability to communicate and tackle problems collectively was a strong point during this sprint. However, the transition to using new tools and processes highlighted several areas for improvement. To enhance our team performance in future sprints, we propose the following changes:

  1. Enhanced Onboarding for New Tools: Given the difficulties encountered with GitLab and related tools, a focused session or resource compilation on these tools at the sprint’s start could mitigate confusion. This could include tutorial links, common troubleshooting tips, and a Q&A session.
  2. Clarification of Roles and Tasks: To prevent overlap and confusion, especially in a multi-person project environment, clearly defining roles and tasks at the sprint planning meeting could ensure smoother operation. This might involve assigning specific issues to individuals or small groups and establishing clear ownership of tasks.
  3. Streamlined Communication Channels: While communication was strong, ensuring that all discussions, especially those related to problem-solving and decision-making, are logged in an accessible and organized manner (e.g., categorized Discord channels or a dedicated project management tool) would help maintain clarity and continuity.

Personal Improvements

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

  1. GitLab Proficiency: I will dedicate time to deepen my understanding of GitLab’s workflow, focusing on branch management, merge requests, and issue linking. Online resources, tutorials, and peer assistance will be valuable in this learning process.
  2. 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 and mentors.

Organizational Skills: I will improve my organizational skills, particularly in tracking my tasks and their related merge requests and issues. Using project management tools or personal task trackers could help ensure that I am always aligned with the team’s objectives and timelines.

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-1 Retrospective

 I didn’t manage to achieve a whole lot in my 1st sprint, I mostly looked at the guest frontend and poked around Thea’s pantry. I’m going to make sure next sprint I actively work on the issues my team has in the backlog. 

The only change I made to the pantry was a branch in guestinfofrontend named add-linters that I was planning on adding the Alexjs linter to. Unfortunately I never got around to actually adding it, and it seems that the other teams have already handled the adding of linters to the project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/tree/add-linters?ref_type=heads

Next sprint I plan on focusing on the inventory frontend and actually making and commiting changes. I do not want to let my team members do all the work.

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-1 Retrospective

 I didn’t manage to achieve a whole lot in my 1st sprint, I mostly looked at the guest frontend and poked around Thea’s pantry. I’m going to make sure next sprint I actively work on the issues my team has in the backlog. 

The only change I made to the pantry was a branch in guestinfofrontend named add-linters that I was planning on adding the Alexjs linter to. Unfortunately I never got around to actually adding it, and it seems that the other teams have already handled the adding of linters to the project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/tree/add-linters?ref_type=heads

Next sprint I plan on focusing on the inventory frontend and actually making and commiting changes. I do not want to let my team members do all the work.

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-1 Retrospective

 I didn’t manage to achieve a whole lot in my 1st sprint, I mostly looked at the guest frontend and poked around Thea’s pantry. I’m going to make sure next sprint I actively work on the issues my team has in the backlog. 

The only change I made to the pantry was a branch in guestinfofrontend named add-linters that I was planning on adding the Alexjs linter to. Unfortunately I never got around to actually adding it, and it seems that the other teams have already handled the adding of linters to the project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/tree/add-linters?ref_type=heads

Next sprint I plan on focusing on the inventory frontend and actually making and commiting changes. I do not want to let my team members do all the work.

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-1 Retrospective

 I didn’t manage to achieve a whole lot in my 1st sprint, I mostly looked at the guest frontend and poked around Thea’s pantry. I’m going to make sure next sprint I actively work on the issues my team has in the backlog. 

The only change I made to the pantry was a branch in guestinfofrontend named add-linters that I was planning on adding the Alexjs linter to. Unfortunately I never got around to actually adding it, and it seems that the other teams have already handled the adding of linters to the project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/tree/add-linters?ref_type=heads

Next sprint I plan on focusing on the inventory frontend and actually making and commiting changes. I do not want to let my team members do all the work.

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-1 Retrospective

 I didn’t manage to achieve a whole lot in my 1st sprint, I mostly looked at the guest frontend and poked around Thea’s pantry. I’m going to make sure next sprint I actively work on the issues my team has in the backlog. 

The only change I made to the pantry was a branch in guestinfofrontend named add-linters that I was planning on adding the Alexjs linter to. Unfortunately I never got around to actually adding it, and it seems that the other teams have already handled the adding of linters to the project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/tree/add-linters?ref_type=heads

Next sprint I plan on focusing on the inventory frontend and actually making and commiting changes. I do not want to let my team members do all the work.

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