Category Archives: CS-448

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.

Mastering “The Deep End”: Thriving Through Challenge

Summary of the Pattern: “The Deep End” pattern is about deliberately taking on roles or projects that stretch your abilities beyond your current comfort zone. It’s predicated on the idea that significant professional growth often comes from tackling challenges that seem slightly beyond our reach. This pattern encourages individuals to seek out opportunities that demand a rapid acquisition of new skills and adaptation, thereby accelerating their learning curve and enhancing their resilience in the face of complex problems.

My Reaction: Upon first reading about “The Deep End,” I was both excited and intimidated. The idea of purposefully putting oneself in challenging situations as a strategy for growth is as daunting as it is inspiring. This pattern speaks to a deeper truth within professional and personal development: growth is not found in the comfort zone. My reaction is a mix of eagerness to apply this pattern in my own career trajectory and a cautious awareness of the balance required to avoid being overwhelmed by challenges.

Insights and Changes in Perspective: Reflecting on “The Deep End” has led me to reassess my own career path and the opportunities I’ve chosen to pursue. It made me realize that some of my most rewarding experiences came from times when I was out of my depth, forced to learn, adapt, and grow in ways I hadn’t anticipated. This pattern has shifted my perspective towards seeing high-pressure situations not as threats but as opportunities to push my boundaries and accelerate my growth. It’s a mindset shift that encourages embracing challenges as catalysts for development.

Disagreements and Critiques: A possible critique of “The Deep End” is the risk of burnout or failure when taking on too much, too soon. The balance between challenging oneself and knowing one’s limits is delicate. While I agree with the core premise of the pattern, it’s crucial to approach such situations with a clear understanding of personal and professional support systems and a realistic assessment of the risks involved. It’s about finding the right challenges that push you without pushing you over the edge.

Conclusion: “The Deep End” pattern offers a powerful framework for thinking about professional growth and development. It challenges us to redefine our relationship with discomfort and uncertainty, viewing them as necessary elements of meaningful progress. As I look to the future, I’m more open to opportunities that may initially seem daunting, with the understanding that these experiences are invaluable for developing the skills, confidence, and resilience needed to succeed in an ever-changing professional landscape.

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.

‘Find Your Mentors’ Pattern

The ‘Find Your Mentors’ pattern is about the idea of “apprenticing” yourself to someone who is more experienced than you are within your field of expertise. While this pattern should be considered for many different professions it should especially be considered for software development as having a mentor can be very helpful especially when you are trying to find your place in the huge world of software. One of the main ideas attached to this pattern is that you will have the realization that you are not the first person to start out being a software developer with little experience professionally as everyone that is currently in the field had to start at the same spot you are currently at and their knowledge can be beneficial to you in order to shape your own career and practices. The solution provided for this pattern is finding a master craftsmen in order to be supervised by them and have the proposed master shape your understanding of the field and your career, but it is also said that with computer science being a relatively ‘young’ field it is hard to find a true master as their are not many people that have ‘mastered’ all of computer science but that there are many people who may have mastered parts of computer science and you should seek out different people in order to increase your understanding of what each mentor you obtain has mastered in their time in the field.

I feel as though this pattern is very important because computer science is younger than many other fields and mentors can be hard to come by in fields which have many ‘masters’ nevermind fields which have very few like computer science. Explaining that it is ok and completely acceptable for a software developer to have many mentors throughout their professional journey in the different disciplines of computer science helps students such as myself realize that you can continue to explore further and further into the field without having to necessarily pick a specific discipline and settle to work on only that discipline for our entire careers but instead that we should feel encouraged to gain more knowledge as knowledge on other disciplines can help us to gain understanding within whichever discipline we are currently working within.

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.

CS448 Sprint 1 – Retrospective

This past Tuesday 2/27/2024 marked the conclusion of Sprint 1 for CS448 – Capstone. My team worked generally well together and we managed to complete all of our assigned tasks as well as some extra we added during the Sprint.

During this Sprint, I was involved in addressing a few different tasks and issues:

Issue spent most time on – “Create General and Pipeline” https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/10. This issue was in the “General” (#gitlab-profile) repository and consisted of three separate parts: 

  1. Moving settings from configuration files set up for integration with Dev Containers to .gitpod.yml extensions for GitPod integration.
  2. Refactoring the ‘commands’ folder to ‘bin’ to keep up with industry standard file naming. This includes updating script paths and .gitlab-ci.yaml environment variables to refer to bin.
  3. Adding the AlexJS linter to pipelines as well as the bin/lint.sh test script file.

Also, as a part of this issue I also implemented some minor typo and similar fixes so that all linters pass for a successful integration pipeline. Originally, these were three separate issues that were combined during the Sprint.

Issue #2 – “Familiarize ourselves with GuestInfoFrontend to Understand What Goes into CheckoutGuestFrontend”

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/37. This issue included all team members and was intended to prepare each of us for Sprint 2, during which we intend on tackling some front-end Epics/issues in CheckoutGuestFrontend. So, I reviewed the GuestInfoFrontend repository structure and began to strategize a possible plan of action for building out CheckoutGuestFrontend.

As mentioned, my Team added additional tasks to our Sprint Backlog during the sprint as we found we would have extra time leftover after completing our original tasks. We chose to take on “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages” for the Documentation and General repositories as we had already set up the settings and thereby familiarity with these repos. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/10

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

I created our new issues; we were able to complete the task for the Documentation repo as it was relatively simple in terms of not needing to make many changes/add linters, and make some progress in the General repo but pushed the issue into Sprint 2.

Reflecting back on the sprint, there were a few things that come to mind which worked really well – as a team we scheduled out our tasks well between standups and managed to have full attendance at each. Also, when we needed to add tasks we elected to stay within the repositories we had already been working in and were somewhat familiar with, which was a good choice as switching would have likely wasted time getting familiar with the new repo, as well as wasted time for another team who would have needed to become familiar with ours. 

However, we struggled somewhat with getting used to navigating the GitLab issue board, merges, child issues etc. and sometimes it felt like some team members were in different places where a solution may not have been fully communicated to all teammates. As a team, I feel we can improve on some of our internal communication and do a better job planning out our sprints and creating something of a road map, especially as we prepare for Sprint 2 which is considerably longer than the first. Personally, I think I can improve my time management and also be a bit more involved in the process of planning out our next Sprint and creating issues with relevant descriptions and linking to organize our tasks and get a better feel of how to use GitLab to its maximum potential.

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.

Sprint #1 Retrospective Blog

Upon completing our first sprint and gathering for our retrospective meeting, it’s essential to reflect on what went well and identify areas where we can improve moving forward. Here’s a breakdown of our observations:

Reflection on what worked well:

  • We successfully completed most of the small issues, achieving a completion rate of around 75%, which demonstrates our ability to tackle tasks effectively.
  • Our meetings, though limited in frequency, were productive and provided valuable opportunities for discussion and collaboration.
  • The quality of communication within the team was commendable, fostering a supportive and transparent environment for sharing progress and addressing challenges.

Reflection on what didn’t work well:

  • We encountered challenges with Docker-compose issues and documentation, which impacted our ability to complete tasks efficiently.
  • Despite aiming for a total weight of 20, we only managed to achieve 15, indicating a discrepancy between the assigned weights and the actual difficulty of the tasks.
  • Details for issues were not easily accessible, as they were only located within the epics, leading to confusion and inefficiency.
  • Issue distribution was uneven, with some team members shouldering heavier workloads than others.
  • All GitLab logistics were handled by one person, potentially causing bottlenecks and hindering collaboration.
  • Individuals tended to work on issues independently, lacking assistance or support from other group members.

What changes could be made to improve as a team:

Better teamwork should be our top priority if we want to grow as a group. To do this, we should encourage teammates to help one another out when necessary and promote cooperation and knowledge exchange. Furthermore, by more precisely allocating weights in light of the lessons we learned from the previous sprint, we can guarantee that activities are appropriately scoped and assigned, averting disparities in workload allocation. Cooperation and efficiency will be enhanced by improving our knowledge of using GitLab and proactively supporting team members when necessary. Furthermore, it can facilitate communication and task execution to make issue details directly accessible from the issue itself, as opposed to only from the epic. Lastly, delegating tasks to one another instead of having one person do them all helps spread responsibilities fairly and encourage a sense of ownership among team members.

Works that I was assigned for and what changes could be made to improve as an individual:
During the previous sprint, I tackled two tasks within the ReportingBackend and ReportingIntegration projects for our LibreFoodPantry endeavor. For the first task, I was assigned with renaming the “commands” folder to “bin” (https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/-/epics/19) for both Reporting Backend and Reporting Integration. This involved not only simply renaming the folder but also ensuring that any references to “commands” within the codebase were updated to “bin” to maintain consistency. Although I successfully made the necessary changes to the scripts paths and ensured the projects ran smoothly, I overlooked updating all related documentation, which remained referencing the old paths.

For the second issue, I took on the challenge of integrating the AlexJS linter into the ReportingIntegration project’s pipelines (https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/-/epics/16). While initially encountering difficulties due to missing scripts, I leveraged external resources provided by our professor to overcome these obstacles. However, my decision to ignore certain files in the AlexJS test led to later feedback about refining this approach.

Moving forward, I recognize the importance of meticulous attention to detail and thoroughness in my work to avoid similar oversights and prioritize spending ample time on each task.

From the blog CS@Worcester – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

Walking The Long Road To Mastery

In our modern world, the journey to mastery is often overlooked in the software development field. Traditional notions of career advancement can cloud our vision as aspiring programmers, leading us away from the path of true craftsmanship. The Long Road pattern is a reflection on our journey of becoming masters in the field and emphasizes the importance of lifelong learning and growth. 

Reflecting on The Long Road pattern, I found myself in agreement with its core message, while also grappling with the implications it holds for my own career path. The pattern’s emphasis on mastery as a lifelong journey stood out to me, serving as a reminder of the importance of patience and persistence in the pursuit of excellence and success. 

The pattern also presents an analogy to martial artists attempting to receive the black belt and connecting it to software development. This highlighted the discipline, patience, and perseverance required to master any craft. Additionally, we should embrace our path, rather than just fixating on the destination. This reminded me that we should appreciate the process of learning and growth, rather than being solely focused on achieving immediate success. 

The Long Road has challenged me to essentially reassess my approach in the field. Instead of chasing after quick promotions or higher paying positions, I now see value in prioritizing long-term growth and development, and measuring progress based on understanding and my quality of work. Therefore, encouraging me to adopt a more patient and deliberate approach to my career, knowing that mastery is a process that’ll unfold over time. 

While I agree with the message expressed in the pattern, I couldn’t help but wrestle its implications with our rapidly changing industry. Today, new languages, methodologies, and frameworks evolve and emerge by the daily. The notion of dedicating a lifetime to master a single craft could seem unreasonable. While I value the importance of patience in honing my skills, I believe there is merit in adaptability and versatility. As developers, we must remain agile and responsive to change, continuously evolving our skill set to meet the demands of the evolving industry. Therefore, while I understand the message, I believe it’s equally important to embrace flexibility in our journey. 

This pattern has left a mark on my perspective as an aspiring craftsman. It has challenged me to embrace this journey of mastery with patience and perseverance, even when faced with uncertainty. As I continue to grow and walk down this path, I am committed to the principles of lifelong learning and growth, knowing that eventually reaching true mastery is a destination worth striving for. 

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

What Worked Well And What Didn’t:
After completing our first sprint and conducting our retrospective meeting, I would say that sprint #1 went really well. As a group, we were given three weeks to complete a total of thirteen different tasks for a total weight of 25, and only fell short of one for a total weight of 20 out of 25. What worked well with the team was that we all knew each other, allowing us to be comfortable with asking different questions or for assistance. Additionally, we were able to schedule weekly meetings whether virtually through Discord or in person. These meetings allowed everyone to be informed about project progress, issues, and next steps. Communication was a major successor for this sprint, further accelerating our knowledge within the project. For what didn’t work well, our timing of working on the project was slightly off. We gradually contributed but didn’t get the ball moving until the end of our sprint. I could understand this as some of us were unfamiliar with the functionality of GitLab and GitPod, and what was completed in the project. For the next sprint, working on the project little by little right when we start and understanding what we are dealing with, will provide us time to discover issues, figure out how to handle them, and complete our tasks in a timely fashion. Additionally, we should consider having a better review process to ensure everyone gets to review work.

Improvements As A Team:
To improve as a team, it would be great to further improve our communication. On days that we don’t have scheduled meetings, possibly posting an update on what everyone is currently completing, any problems they have, if someone needs something reviewed, and if they need help from another person on the team that may have knowledge on what they are working on could be beneficial. Also I believe we should begin working on our issues from the start rather than stressing and cramming everything all at once at the end of the sprint. We should also implement a better reviewing process.

Improvements As An Individual:
As someone who had just stepped into the project, I was unfamiliar with navigating through GitLab to find different things, what was completed within the project, and what needs to be worked on. After researching different things and searching through various repositories, I was able to figure this out. I was able to complete three issues individually and one issue as a group particularly working within the InventorySystem of the Theas Pantry project. My first issue was GitPod Dev Environment in InventorySystem/General. This involved having the Theas Pantry project work with VSCode in GitPod, rather than devcontainers. The second issue I completed was also GitPod Dev Environment in InventorySystem/InventoryAPI. I completed the same work to have VSCode work in GitPod rather than in devcontainers. My third issue was Move From ‘commands’ to ‘bin’ in InventorySystem/InventoryBackend. This issue involved changing the file name from commands to bin, updating all script paths to use bin, and ensuring pipeline stages like build, test, and release all functioned properly. I ran into an issue with the test pipeline for this specific task as files were missing. To correct this, I had to disable the test pipeline and plan on fixing this in the next sprint. The last issue I worked on was with my group, GitPod Dev Environment in InventorySystem/Documentation. We completed the same work to have VSCode work in GitPod rather than in devcontainers. To improve as an individual in future sprints, I would like to complete a little bit of work each day, rather than trying to just complete as much as I possibly can all at once. I spent a lot of time working on my issues and when something didn’t work, I’d burn myself out trying to figure out what the problem was. In future sprints, completing issues piece by piece can allow me to have a fresh mindset each time I work on the project and complete tasks in a faster, more efficient manner. Additionally, by completing a little bit each day, it can take away stress from time constraints and allow me to ask questions, get reviews, make changes, and improve the quality of my work.

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