Category Archives: CS-448

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

Achievements & Challenges

Reflecting on what worked well, one aspect was our organization. From the start, we established a strong foundation with clear and well-defined issues, allowing us to hit the ground running. The team demonstrated a balance between offering assistance and providing constructive feedback on each other’s work, creating a collaborative and supportive environment.

However, GitLab presented a learning curve that took us a bit longer to fully grasp and navigate. This resulted in occasional roadblocks, such as instances where work had already been done or where components were missing, requiring further elaboration. Recognizing these challenges is the first step toward overcoming them in future sprints. Another issue we faced and have already solved was our Sprint planning meeting, creating a more team-balanced approach. Originally, we had only one member creating issues as we talked about them. However, we realized this was not the best approach. For Sprint 2, we had each member create issues that we originally defined as a team. Then, we gave each member a chance to talk about their issues, how they plan to work on them, and if any improvements/clarifications would be needed.

On the team improvement front, our collective strength shone, especially when tackling potential ideas for more challenging tasks ahead. Moving forward, we aim to enhance our coordination by implementing more frequent check-ins. This approach will ensure that no team member is too far ahead, behind, or engaged in incorrect work, establishing a system of checks and balances within the team dynamic. Another improvement that will benefit the team as these issues begin to become longer and more challenging is more team-based work. After reviewing other teams’ work in the first sprint, I noticed multiple issues where more than one team member was working on an issue. This step will allow more time and a second pair of eyes on an issue, improving our productivity and furthering our ability to tackle an issue simultaneously.

Individually, I’ve identified areas for improvement that will contribute to both personal and team success. Managing time more effectively is a key focus, acknowledging that optimizing productivity requires a strategic approach to time mangement. Additionally, recognizing the importance of communication, especially on off days, will be crucial in maintaining a good workflow. The goal is to avoid getting too ahead of myself and attempting to tackle everything simultaneously. This includes refraining from taking on multiple issues beyond what is required, ensuring a more measured and sustainable workflow.

GitLab Work

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

Description: In my individual assessment above, I recognized a mistake in attempting to tackle more than necessary. While working on issue #1, I unintentionally delved into other topics. In an effort to make the branch more user-friendly, I decided to combine these three separate issues into a single, comprehensive one. This new issue provides clear documentation for each step involved.

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

Description: This issue involved a straightforward review of the existing documentation. The focus was on ensuring the pipeline’s smooth operation by confirming the correct properties. Additionally, unnecessary extensions and linters were eliminated to simplify and optimize the documentation.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal 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.

Breakable Toys Individual Apprenticeship Pattern

This week for CS448 – Capstone, I read about the “Breakable Toys” Individual Apprenticeship Pattern; while I did not know it when I selected this pattern, it relates back to two other patterns I analyzed earlier in the semester: “The White Belt” and “Confront Your Ignorance”.

The “Breakable Toys” pattern encourages craftsmen working in high-risk environments intolerant of failure to create personal projects, referred to as ‘Breakable Toys’. These projects are typically smaller in scope but similar in toolset to work systems, providing a safe space for experimentation and learning through failure. The pattern advises building tools like wikis, calendars, or address books, which may be overengineered but allow for trying new ideas without significant consequences. Given the book’s original publishing in 2009 and the progression and advancement of technology/platforms since then, other tools and platforms may be more applicable and resources like Git make tracking and controlling versions easy.

The focus is on personal growth, skill development, and enjoying the learning process, ultimately fostering a deeper understanding of tools and encouraging continuous improvement. In this way, this pattern is similar to “The White Belt” and “Confront Your Ignorance”, but focuses on building off of prior knowledge in a low-stress environment rather than ignoring it.

I really enjoyed reading about this pattern and its benefits as it is one of my favorites to implement – actually, while reading it I realized how many skills I have picked up using this method. As an individual, when I learn new skills/tools I naturally want to practice them and their non-instructed limitations as well as just generally play around. While a lot of what I learn may not be directly related to my initial task, I usually pick up a few things that are unbelievably useful later on and give me an advantage in addressing challenges.

The clearest example of this which comes to mind immediately is learning Apache POI and PDFBox early in my Computer Science degree/education. I had a lot of experience with basic Microsoft Office applications and was beginning to understand the power of OOP through my Java learning, so the summer after my first semester I decided to learn how to connect the two. By the end of my project, I was confident in reading/manipulating data from Excel, generating new files or report generation, format text and images in PDF documents, and more. All of this was possible because I took it upon myself to research and create my own “breakable toy” environment to learn in.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

CS448 Software Development Capstone – Sprint #1 Retrospective

For our first sprint in the software development capstone course at Worcester State University, our team was tasked to investigate epics attached to multiple repositories within the Thea’s Pantry Gitlab page. We also needed to learn how to use Gitlab’s productivity and team management tools as we went along so we could appropriately divide up tasks among ourselves and monitor our progress. Most of our work was accomplished within the GuestInfoSystem repository and its component microsystems. We also spent time investigating the component InventorySystems in preparation for construction of test suites in the next sprint. I personally contributed to the issues attached to GuestInfoBackend, as well as contributed to sprint planning during team standup meetings and meetings outside of classroom hours.

The specific issues that our team was tasked with resolving were configuring the repositories within GuestInfoSystem for remote Gitpod development environments, renaming the ‘commands’ directory of each repository to ‘bin’ and modifying any scripts that reference the ‘commands’ directory to reflect the name change, and integrating the AlexJS linter into the Gitlab commit pipeline. After that work was finished, we would be responsible for investigating the GuestInfoSystem and InventorySystem repositories to prepare to build testing suites for the frontend and backend services during our next sprint.

Before we started work on the issues, we came together as a team to discuss how much time and effort would likely go into the completion of each task, using the weight system used by Gitlab as an estimate. The weight system is a scale from 0 to 3, with each increasing level of weight meant to represent a relative increase in time and effort necessary to resolve the issue. We attached a weight of 0 to some of our tasks while planning our sprint, which may have led us to expect that some of our work wouldn’t take as long as the task would end up requiring of us. The 0 weight in this system represents a task that shouldn’t take more than a few minutes. The only issue that we worked on this sprint that I would still argue would constitute zero weight would be the renaming of ‘commands’ to ‘bin’. Everything else required more investment of our time and concentration than we had anticipated, in part because we were still learning how to use Github’s tools to coordinate as a software development team.

Once we had agreed as a team on which weight values to assign to each of our issues, we decided to begin our sprint with preparing the repositories for development in Gitpod. Instead of cloning code from the Thea’s Pantry Gitlab page to our personal machines, we can open the repository files in a web browser based Visual Studio. This remote workspace is maintained by Gitpod for as long as we are working in it, and for 14 days of inactivity afterward. To create a workspace for the repository we want to work on, there are tools within Gitlab that allow for easy creation of a new development branch based on an issue, as well as the creation of a new Gitpod workspace based on that branch. I’ve been getting to enjoy using these remote development features, personally, and I appreciate how I can have access to all the functionality of Visual Studio without needing to install extensions on my machine.

To get each repository configured for development in Gitpod, we needed to copy the names of our desired settings from the existing ‘.devcontainer/devcontainer.json’ into ‘.vscode/settings.json’, and to copy the names of the extensions that each repository requires into ‘.gitpod.yml’, a file that can be created in the repository while working in Gitpod by using the terminal command ‘gp init’. However, we found that because of a part of the Gitlab pipeline that lints the files in the repository, we needed to change the formatting of some of the files created by that command so that no lines were longer than a certain character limit. In hindsight, I think it would have been better to try and include those files in the ignore files for the linter extensions. Ignore files are files that point to other files and directories within the repository that we don’t want the linter to review or raise any issues with. We began to recognize the utility of ignore files near the end of our sprint, but at the outset it hadn’t occurred to me to try and get around the linter errors by adding the newly created Gitpod files to an ignore list.

The issue that challenged me the most was adding the AlexJS linter to the GuestInfoBackend and to the Gitlab commit pipeline. I wasn’t anticipating that I would struggle with a task like this, because I thought I would just need to type ‘AlexJS’ into a few files and I would be done with it. While that was part of the process, I also needed to add certain files like licenses and the Code of Conduct to an ignore file. The linting process would have returned a failure status otherwise because those files contained text that would be flagged by the linter. I also spent more time I would like to admit waiting for the linting process to finish while it was iterating through the lengthy ‘node_modules’ directory. That directory needed to be added to this repository’s linter ignore files to avoid an unbearably long (and doomed to fail) linting process. I also realized by the end of the sprint that I had misunderstood the task to add AlexJS to to the Gitlab pipeline, and I had only added AlexJS to the lint shell script within the development environment. In the future I’m going to make sure I review a linter’s ignore file when newly installing it into a repository.

My most significant takeaway from this first sprint is that I shouldn’t underestimate the effort I’ll need to invest into issues that sound like they’re well within my comfort zone. We’re working as part of a cooperative effort on a complex software project, and that requires an advanced degree of communication and attention to detail. I’m not going to be able to go into tasks assuming that they will be easy just because they sound similar to problems I’ve solved before.

Gitlab issues:

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

Sprint 1

Sprint 1 Retrospective

What worked well this sprint

Because this sprint was our first working together as a group, learning how each of us felt about working in a team in general was important. One thing we all mentioned was how in our previous experiences, group work tended to be inconsistent in terms of communication and deliverables. This meaning that sometimes a group member would not communicate throughout the duration of the project, and would not have any work to show they have been actively working towards the end project goal. In order to combat this, we decided to have weekly in-class meetings (specifically on Thursdays). Having weekly in-class meetings worked well because there was consist communication throughout the sprint. If any group members had any questions, weekly meetings also gave opportunity for those questions to be answered in a timely manner, if not addressed between meetings. Something else that worked well was having a separate text group chat, rather than only having Discord as our main form of communication. Having a text group chat seemed to be a more reliable form of communication for the team.

What did not work well

As briefly mentioned above, having Discord be our main mode of communication did not work well. In the beginning of the sprint, some of us did not have the Discord app installed on our phones which led to not receiving notifications. This became problematic because there would be missed messages. What also did not work out well was leaving completed issues and merge requests to be reviewed at the end of the sprint. Leaving code reviews to the end of the sprint led to many merge conflicts and extra work that could have been avoided.

Changes to make as a team

One change that could be made as a team is to review merge requests as they are completed, rather than waiting until the end of the sprint. Resolving an issue and completing merge requests as they are finished is a more efficient workflow because the number of merge conflicts is dramatically reduced. When numerous merge requests are made on the same repository, some merge requests will have changes that others do not which is what led to the merge conflicts. Another change that should be made is being more clear as to when we are having meetings. Although stated above that having weekly meetings worked well, there were times where we had to reschedule to meet during the Tuesday class time rather than the Thursday class time. Normally this would not be an issue; however, there were a few instances where some would be there for the meeting, while some would not be due to confusion on when we were actually meeting that week.

Changes to make as an individual

A change that could be made as an individual is responding more promptly. Delayed responses from myself, mainly came from the beginning of the sprint when the team/I were having some communication problems when only using Discord which led to the suggestion of a separate text group chat.

Activity on GitLab

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

Sprint Retrospective Blog #1

Hi everyone, my name is Abdullah Farouk, for those who didn’t know, 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 the first sprint. This sprint consisted of us getting familiar with libre food pantry more and to see how this scrum framework actually go. 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 teammates 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 didn’t work out well was how we weighed the issues in the beginning. Some of the issues took less than what we had anticipated, and some took way longer, to the point that we finished only half of the last issue left for the sprint and therefor had to leave the issue to next sprint. Another thing that we were struggling with was communicating outside of class time. I take some of the blame myself as I do not have discord installed on my phone and therefore, I only check it at night time or when I get home from work. 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 those minor issues, I think me, and the team did a great job going through these issues and completing them on a timely basis. To improve as an individual, I will try to check discord more often to communicate better with my team. To improve as a team, I think we should start adding a description of the issue under the title just so we don’t get confused and be more organized I would say.

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

  • Moved “commands” to “bin” and added a cspell folder to make sure the spelling are right. Merged and pushed the issue.

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

  • I sat up to work with VS code in Gitpod rather than devcontainer which was a little bit tricky because I didn’t know what gitpod was until that moment.

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

  • Me and one other classmate looked at the check inventory frontend and examined the code to see what it was missing and what it could get better at.

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