Category Archives: CS-448

Sprint Two Retrospective

This sprint went pretty well. There were a few more issues than with the prior sprint; however, those issues were out of our control for the most part. The first issue I worked on this sprint was issue 15 (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/15). This issue was very easy for me to complete; I only had to make minor corrections. The next issue I worked on for the first week was issue 46 (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/46). This issue was more challenging to complete, and I had to continue to work on it during the following week.

In trying to complete this issue, I had to revert the changes that I had made to issue 46 during the first meeting in order to make progress in completing this issue. Sadly, I was still unable to complete this issue during the second meeting period, but I was confident in the progress that I was making. I messaged Dr. Wurst at the time to see if he could help me solve the issue I was facing. During the third meeting, I found that I was unable to make more progress on issue 46, so I decided to begin working on issue 151 (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/issues/151 ). During the third meeting, I made some progress on issue 151, but the issue still needed more work to be done before it could be considered complete.

The fourth meeting went better than the prior two meetings for me. I was able to complete issue 151 and begin working on issue 72 (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/72). I started working on the first child element in this issue, which was researching how to implement nodemon into the inventory backend. I found one article detailing the implementation of nodemon and the documentation for nodemon, which I made a comment on under the child element for this issue.

Before the fifth meeting, Dr. Wurst released a fix for the problems that I was having with issue 46. After checking to make sure that nothing else needed to be fixed with the issue, I moved on to issue 37 (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/37). I was able to finish most of issue 37 during the fifth meeting. However, I still needed to complete a little more before being able to push it to the next stage of development.

The sixth meeting was going smoothly at first; while linting issue 37, I ran into a problem with the pipeline. I could not correct this issue independently, so I contacted Dr. Wurst for help. In the meantime, I continued to work on linting through the git pod instead of the git lab pipeline. I finished the sixth meeting by completing the linting as best as I could without being able to test the pipeline, so I had to wait for the next meeting to be able to continue with this issue.

During the seventh meeting, with the help of Dr. Wurst and Mike, I was able to overcome the issue I had from the prior meeting. After that, I was able to use the pipeline to finish linting, and I was able to get most of it done before the end of the meeting. However, there was a little more left to be done before the issue could be completed.

During the eighth meeting, I dedicated my time to reopening issues that were closed by mistake so we could accurately gauge how much we could complete during this sprint. I found a way to access which issues a user had closed, which made this process much easier for our group.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

CS448 Software Development Capstone – Sprint 2 Retrospective

Throughout Sprint 2, which began at the start of March and was divided by our week of Spring Break, our team tried to spread our work out across several of the repositories in Thea’s Pantry instead of focusing on just one. Our tasks in each repository were centered around making sure the linter extensions were configured correctly in the Gitpod workspace, and that these same extensions would be included in the Gitlab pipeline whenever a new push is made to the repository.

These tasks were more difficult in some repositories than others. Repositories that had received more attention in the recent past required little work or reconfiguration in order to run the ‘lint.sh’ shell script and have no errors reported in the Gitpod terminal. Most of the issues that I encountered were with the formatting of developer documents. These files were reviewed by the ‘markdownlint-cli2’ linter, which has a set of rules that it expects the markdown files written by the developer to follow. These rules include a limit on the character length of each line and a restriction on trailing spaces, which I found were the two most common issues I needed to address in the developer documents.

One prominent difficulty I had in configuring each linter was learning where in the repository each extension looked for exceptions to their built-in rules. The ‘markdownlint-cli2’ extension had its own file in the root of the directory, as did a few others including ‘alexJS’. Other linter extensions had more obscure locations; the frustratingly similarly named ‘markdown-link-check’ needed additional arguments to be added to its invocation within the ‘lint.sh’ script, and not written in a distinct file in the repository like most other linters. Each member of our group discovered the necessity of modifying the linting shell script after running our initial ‘npm install’ commands. This command creates a hidden directory in the root of our repository called ‘node_modules’, which contains files related to the extensions we have installed as project dependencies. However, if we attempted to run the ‘lint.sh’ script without explicitly ignoring the ‘node_modules’ directory, some of our linters, the ‘markdown-link-check’ especially, would run for a prohibitively long time reviewing files in the ‘node_modules’ directory. Since the ‘node_modules’ directory contains files written by developers outside of the Thea’s Pantry project, it isn’t our responsibility to lint these files.

One special responsibility that I had for this sprint was to research the Mocha testing framework and Chai assertion library for later use in Thea’s Pantry. The ‘GuestInfoBackend’ repository already had a functioning test framework, and I used that as a model for adding Mocha and Chai as dependencies to the ‘InventoryBackend’ repository. My first task in the ‘InventoryBackend’ repository was to create a ‘testing/test-runner’ directory which would hold the package files and unit tests utilized by Mocha and Chai. Then, I was able to install Mocha and Chai in this subdirectory through the npm utility. Once I had installed all the files, I needed to modify the ‘test.sh’ shell script to call the Mocha framework. I got caught in the weeds at one point because I thought that the ‘docker-compose-test-runner.yaml’ file would create the Dockerfile, and I didn’t know whether this Dockerfile was supposed to be manually created or edited by the developer. I resolved this issue with the help of Professor Wurst by copying the Dockerfile present in ‘GuestInfoBackend’ and modifying it to meet the needs of ‘InventoryBackend’.

There were a few more steps to go before successfully integrating Mocha and Chai into ‘InventoryBackend’, including adding an ‘entrypoint.sh’ into the ‘test-runner’ subdirectory, as well as installing Yarn as an additional dependency. After my ‘lint.sh’ was returning no errors, I had to add the ‘test’ stage to the Gitlab pipeline. In the previous sprint, I thought that adding pipeline components was something our group would need to ask permission for, and only realized near the end that we actually had that capability as developers through the ‘.gitlab-cli.yaml’ file. Armed with that knowledge in this sprint, I realized that all I needed to do to enable the ‘test’ stage in the ‘InventoryBackend’ pipeline, was to remove the ‘test’ argument from the ‘disabled stages’ field.

One thing that I think our group could improve on is our review process before pushing our work to the main branch. What we’ll usually do when one of us is ready to create a merge request for our branch, is pick another one of our group members that we haven’t asked to review our previous merge request and have them approve the changes and remove the ‘draft’ marking from the merge request. What I looked for as a reviewer was whether all the pipeline stages passed, primarily. In the future, if we are working on configuring linters again, I think it would be best to have an example of working linter configurations to compare our changes against. This way, I think we would spend less time untangling the proverbial knots that the linters are catching on, and we would also avoid the possibility of introducing breaking changes to the repository.

Work:

Reviewed Mocha and Chai documentation for integration into ‘InventoryBackend’ repository

Configuring linters and Gitlab pipeline in ‘InventoryIntegration’

Added Mocha test framework and Chai assertion library as developer dependencies to ‘InventoryBackend’

Add Yarn as developer dependency to ‘InventoryBackend’, in the process of integrating Mocha and Chai

Configuring linters and Gitlab pipeline in ‘ReportingBackend’

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

I felt like I went into this sprint confident that the tasks we planned to approach at the start would go well based off of what we learned from the first sprint. To start the sprint off our team met with Team 1 on Discord. We discussed what we learned about frontend testing, including vues and how to build a frontend in gitpod. This is where that confidence was immediately squashed when I began to realize the depth involved with setting up all the linters for a frontend and linting all of the files.

During the entirety of the sprint I was stuck tackling this one issue; setting up linters in GuestInfoFrontend. This issue was originally weighed by the team as a 2 based on everyone linting their repositories in the previous sprint. Come to find out, linting a fully built front end can take some time.

The initial Issue I ran into was understanding how to enable each linter in the pipeline. The main reason I failed to properly lint the GuestInfoFrontend in the previous sprint was that I never enabled the linters. To make sure I had every linter I needed I read the documentation for each linter and picked ones that linted any file that existed in the frontend. The linters I used were alexjs, cspell, hadolint, lint-package-json, markdown-link-check, markdownlint-cli2, shellcheck, spectral, eslint, htmlhint, and style lint. 

Eslint, htmlhint and style lint didn’t end up working with the pipeline and were removed. Issues were made under each of their respective repositories detailing the error message. Eslint still worked locally, so linting was still able to be done to the files.

As for the other linters, I was able to learn a decent amount about configuring rules for each one of them. This includes understanding what to name the config file, how to format the rules, and what rules exist. Unfortunately It turns out that the rules I created are only checked locally, which makes sense. So my files would still fail the pipeline without the proper lint ignore comments. This was something I tried to avoid at all cost, as it just feels like a cheap and easy fix. That being said I look forward to maybe taking my proposed rules further up the pipeline.

What Worked Well:

The team’s communication was again the best part of the sprint. There were times where one of us would get stuck or fall behind. Having them communicate what is going on allows the rest of the team to be aware of the situation and adjust accordingly. 

What Didn’t Work Well:

With me being stuck on one issue the whole time, I felt guilty as my team was responsible for the entire rest of the board. Because my one issue encapsulated other smaller issues, none of the progress on each of the smaller issues could be reflected on the issue board.

Team Improvements:

As a team we have noticed that there have been issues that essentially have child issues. These child issues get overlooked when we are weighing the issues before the start of the sprint. In my case where I was stuck on one issue, if it was originally built as the 9 separate issues I could have been easily divided up amongst the team. At the very least it would have reflected progress being made on the issue board.

Another improvement we can make is our documentation. Although we do a great job relaying information internally, it is important to remember that we are not the only team that will see these issues. Having comments explaining why we did what we did or sources for where we got our information can assist others who look at the issue.

Personal Improvements:

At some point during the sprint I installed at least one package in the wrong directory. There were times this was done because I didn’t know any better, and others by accident because I just forgot to move the working directory. This created many issues and a mess of unnecessary files. Moving forward I need to double check the working directory before installing. Not only this, but having better commits could help revert back to before the installation. Overall this has given me a better appreciation for the power of git commits and its record keeping. 

Issues:

Meet with Team 1 to discuss frontend testing:

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

Set up linters and lint the GuestInfoFrontend repository:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/95 

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

“Draw Your Own Map” Individual Apprenticeship Pattern

This week, I decided to focus on the “Draw Your Own Map” Individual Apprenticeship Pattern for CS448-Software Capstone. This is my final required apprenticeship pattern analysis post, and I chose this pattern because it feels applicable to me as I am about to graduate and enter the working environment, mapping out my intended career path from its starting point. 

The “Draw Your Own Map” individual apprenticeship pattern emphasizes the importance of taking control of one’s career development and learning journey. It encourages individuals to proactively chart their own course rather than relying solely on predefined paths or external guidance.

At its core, this pattern advocates for self-directed learning. It urges individuals to actively seek out opportunities to acquire new skills, knowledge, and experiences that align with their career aspirations. Setting personal goals is essential in this process, providing a roadmap for growth and development.

Identifying various learning opportunities, both formal and informal, is crucial for professional advancement. This could include attending workshops, pursuing certifications, participating in projects, or seeking mentorship. Adaptability and flexibility are also key, as career paths may require adaptation and adjustment over time.

Regular reflection on progress is encouraged to refine goals and adjust course as needed. By reflecting on past experiences and learning outcomes, individuals can iterate and improve their development strategies. Additionally, building a personal brand and reputation within the industry is essential for showcasing skills, expertise, and achievements.

In essence, the “Draw Your Own Map” pattern empowers individuals to navigate their professional journey with autonomy, self-reflection, and continuous learning. By embracing ownership of their career trajectories, individuals can pursue their long-term goals with purpose and resilience.

With such a competitive entry-level environment, it is possible that I may find myself (or at a later point in my career) choosing to take a position that may not fully align with my interests and career goals. Additionally, with all of the ongoing changes in the tech industry and world as a whole, what may have been a traditional and common career path is impractical today. So, it’s crucial that I can draw my own map to success and redraw it as necessary throughout my career. By following the strategies outlined in this apprenticeship pattern, it seems a lot more realistic to be able to take a starting position that may be less-than-ideal while still progressing toward my intended goal.

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.

Sprint Retrospective

Sprint 2 Retrospective

Introduction

  • In this sprint we were focused on scaling up our productivity and getting the UI underway.
  • This sprint lasted longer than sprint 1 but ended up feeling very back heavy because we were delayed on working on the front end until we had access to the new template.

Links to Activity on GitLab

Reflections on the Sprint

What Worked Well?
  • Like the last, 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 allowed us to effectively tackle our goals.
What Didn’t Work Well?
  • I think that the main thing that we struggled with was managing the time of this sprint, considering that we were halted in our efforts to make the front end until we had a working template to base ours off of. In the end we got it done after a busy end of sprint.

Improvements for Team Performance

The team’s ability to communicate and tackle problems collectively was a strong point during this sprint. It was an effective carry over from the last sprint and will hopefully be reflected in the next sprint as well with some of the following improvements:

  1. Keep a consistent schedule: In hopes to avoid a repeat of the last sprint where everything was stacked at the back of the sprint, It would be beneficial to manage our time better as a group with a more consistent meeting time.
  2. Division of Labor: we continue to ensure that one person does not get stacked with to much to do while others get left with little to work on.
  3. Streamlined Communication Channels: Same as the last sprint, ensuring that all discussions, especially those related to problem-solving and decision-making, are logged in an accessible and organized manner 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 Use: I still struggle with some aspects of gitlab and hope to improve that for sprint 3.
  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.

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.

CS448 – Sprint 2 Retrospective

Our second of three sprints for CS448 – Software Development Capstone concluded and was reviewed last Tuesday (4/7/2024). My team worked very well together this sprint and we helped each other as we stayed flexible and adaptable as changes were rolled out that affected our repo and issues. Additionally, most of our issues focused on FrontEnd tasks including the design, development,  and integration of a user interface for the CheckoutGuestFrontend repo. UI design and particularly implementing Vue.js framework was mostly unfamiliar for our group, so we learned a lot from what we accomplished this sprint.

While we didn’t quite finish all of our initially planned tasks, we did successfully reorganize issues into smaller/more manageable and defined issues mid-sprint and we completed all of our issues up to testing the front-end we built:

“Get in touch with Team: 01-2 and discuss Frontend Tests and their findings” – When we took on the task of developing the CheckoutGuestFrontend repo, we found Team 2 had already taken on some responsibilities and begun researching front-end testing. So our first order of business was holding a meeting with them to decide on a starting point for our group. Our notes from the meeting are recorded here.

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

“Review GUI Mockup” – For this task, we all met as a group to go over a basic on-paper mockup of what we envisioned and had in mind for the CheckoutGuestFrontend GUI and break down the task of coding the GUI into smaller, more manageable and well-defined issues. In the issue, we document our hand-written mock-up as well as our meeting notes and the smaller issues we refactored to. The “Consider Interaction Boundaries” and “Modify/Improve GUI Framework” issues were encompassed in the preparation and execution of this Review task.

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

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

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

Main issue:

“Coding UI to place components on the screen where we want them (“layout”)” – This task encompasses the overall processes of creating the Vue.js, integration, and other resource files and code to actually implement our mock-up. This was our first time working with Vue.js, and we are also less experienced with JavaScript as compared to other languages like Java and Python, so we hit some setbacks and delays as we explored and learned more about using these. There were also some minor steps involving communication protocols that were learning experiences.

Another obstacle we traversed involving this issue is the rollout of the new frontend model by Dr. Wurst. When we first tackled this problem, it was not yet released so we struggled to get a working baseline/framework to edit and build off of.

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

“General – Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages” – This was a task from last sprint which we did not quite complete. This sprint we finished it up by verifying the necessary components. Once the working model was rolled out, we managed to build ours out to a stable state with an attractive UI by holding several full-team code reviews. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/12 

In review, our second sprint for CS448 – Software Development Capstone was driven by patience, teamwork and adaptability. Despite encountering challenges, particularly in navigating unfamiliar territory with UI design and Vue.js implementation, we emerged stronger and more knowledgeable. While we didn’t fully complete all initially planned tasks, our ability to reorganize issues mid-sprint into smaller, more manageable ones allowed us to focus on essential aspects. Key achievements included productive collaborations with Team 01-2 on frontend testing, thorough review and refinement of GUI mockups, and overcoming hurdles in coding the UI with Vue.js. We also successfully addressed pending tasks from the previous sprint, ensuring all projects within Thea’s Pantry ecosystem met required standards.

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

This was our second sprint of the semester and I would say we definitely did better in some aspects as a team while we still need to work on other aspects. I personally worked on one issue on my own while we did all the other issues completed during the sprint as a team during our meetings. These issues included ensuring the proper linters and pipeline stages in a repo, researching how to write vue code and implementing said code as well as developing the frontend with buttons and input fields to prepare for a confirmation page next sprint. Our group issue that we completed included researching vue as well as redesigning the wireframe for the addInventory frontend.

Overall I did not have any trouble with my individual issue during this sprint. My issue I worked on regarding the addition of linters and pipeline stages was straightforward and I was able to complete it without much delay as there were not many issues in any of the files after implementation of the necessary linters. The first issue that we worked on as a team regarding the research of vue code and making an example button also went well and did not take us long during our meeting. The second issue we worked on as a team included working on the frontend which was rather challenging as we do not have much experience with the frontend between us but we were able to add two buttons along with input fields in order to have a displayable frontend. Our last issue as a team was to redesign the wireframe for the frontend in order to prepare for sprint 3 which went very well as we are planning on adding a second page to the frontend which confirms the addition to the inventory.

We did not have many problems during this sprint but I still feel as though there are things we could work on to improve as a team. One thing we can improve on is everyone making it to scheduled meetings, during the sprint we had meetings where we were not all in attendance and the team members in attendance did not know that others would not be making it to the meeting so I believe we need to work on communicating more when it comes to having to be absent from a meeting so the team knows what to expect. Another problem we had during the sprint was being willing to ask for help when needed, although we all have little experience when it comes to frontend coding we still can bounce ideas off of each other in order to work through issues faster as it is more useful to the team if we all understand what we are working on and we all agreed when writing our working agreement that we would all be available and willing to help eachother or answer questions as needed. In my opinion we worked well together during our second sprint and I hope we are able to work together even better during our final sprint of the semester.

Issues worked on:

Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages – CheckInventoryFrontend

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

Research code for `button` implementation in Vue and HTML

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

Develop `Submit` button Vue and HTML files

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

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

Overall I think the second sprint went well. Like the last sprint, I think we all did a good job of keeping each other updated and asking each other questions if we became stuck. For this sprint, we worked on a lot of the issues as a group. We also were open enough to communicate with each other when we realized that issues may not have been merged for a long period after being reviewed. Unfortunately, there were a couple of times when we didn’t keep up with issues that were in the “Needs Review” column. This resulted in a lot of merge conflicts that need to be resolved for those issues. We continued to display aspects of the original description of the culture we wanted in the working agreement: open-mindedness, honesty, respect, and accountability. We decided how much weight everyone should try to complete to divide the work evenly and fairly before the sprint started and we kept to it for the most part.

I worked on multiple issues that involved verifying that the pantry projects had the correct extensions, linters, and pipeline stages. For this issue, we examined the file types on the project, made a list of linters that were needed based on the files, added any linters, made sure the new linters passed, checked which stages were needed, and fixed the stages accordingly. I worked on verification for GuestInfoBackend, GuestInfoAPI, and GuestInfoSystem/General. I worked on the first two issues with the group and worked on verifying GuestInfoSystem/General by myself. We also had an issue for talking to group 3 about InventoryFrontend and InventoryBackend because they decided to work on some issues for it. Towards the end of the sprint, I realized they didn’t reach out so our group initiated a conversation to confirm if they were all set. Once that conversation finished I moved that issue to the done column. I also worked on reviewing the issue for getting InventoryBackend test working and getting the InventorySystem General test and build working. The issue for getting the InventoryBackend working was an issue that was left in the  “Needs Review” column for an extended amount of time and needed an extensive amount of work to resolve merge conflicts.

As a team, I think we did fairly well but we needed to keep up with the issues that need review more. We also did not rotate reviewing issues as we originally planned when creating our working agreement and or set up a system that will ensure that there aren’t certain people who are reviewing the majority of issues. Because a lot of the issues involved us working together, we didn’t address how we would make sure to stay on track of issues that needed review. As an individual, I need to make sure I can review issues as soon as possible to prevent the possibility of having a team member work through multiple merge conflicts. I think as a group we could benefit from a specific plan for keeping up with completed issues. For the next sprint, I plan on picking a schedule to check on the needs review column.

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.

CS-448: Sprint 2 Retrospective

Sprint 2

What worked well this sprint

Sprint 1 was a good opportunity for the team to become familiar with each other, how we like to work individually, and the general workflow that we were to follow. After Sprint 1, Sprint 2 was much easier in terms of knowing what the team wanted to accomplish and how to accomplish it. During this sprint, we continued our weekly meetings because it was a good way for everyone to go over what was done the past week, and what needed to be done for the current week. Last sprint, we ended up leaving all of our merge requests open until the end of Sprint 1 which resulted in many conflicts which created extra work to resolve those conflicts. This sprint we decided to review and merge as issues are completed rather than leaving them until the end of the sprint. Reviewing as issues are completed helped the team to avoid merge conflicts.

What did not work well

Throughout the sprint, the team had issues that were dependent on the completion of other issues. An example of these issues were when the team were adding to the AddInventoryFrontend. The goal of the issue was to implement the functionality of actually adding inventory to the database which required multiple components to be added such as text fields, buttons, etc. Because the team as a whole had limited experience with frontend work, we spent time together researching implementation. When spending time together for research, we realized that implementation would be easier with the approach of mob programming. Utilizing mob programming rather than each of us being assigned an issue and completing individually helped save time. This is because if we were all assigned an individual issue then we would have to wait until the first person finishes their issue, then the next person could start their issue, and so on. Each of us would also have to pull the changes the previous person made. This process seemed inefficient, so the team decided to group the issues together and do them at once in one meeting where everyone was present.

Last sprint we also came across problems where there was miscommunication about when we would be meeting, which we aimed to resolve this sprint. However we still faced attendance issues regarding the team’s weekly meetings.

Changes to make as a team

One change that we tried to resolve last sprint was the issue of some team members not attending the weekly meetings. Unfortunately this issue was not fully rectified. In hopes to settle this issue for the next sprint, the team should have a discussion to clearly restate expectations which were initially defined at the beginning of the semester.

Changes to make as an individual

A change that could be made as an individual is having a better grasp of what needs to be done. Mainly due to having spring break in the middle of the sprint, there were a couple instances where I would forget a standup message to inform my team on the progress I have made individually. Although this sprint was longer than the previous, it actually felt shorter to me because of spring break and canceled classes which contributed to me having to rush at the end of the sprint to get my work completed in time. I plan to manage my time better, so this does not happen for Sprint 3.

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.

Nurturing Software Craftsmanship

Hey everyone! In “Apprenticeship Patterns,” the authors present the pattern “Nurture Your Passion.” This defines preserving and growing one’s passion for software craftsmanship, even in unique work environments.
The authors acknowledge that as a software developer, your true passion lies in the craft itself. Unfortunately, the daily grind can decrease this passion, with factors like crushing hierarchies, “death marches,” abusive managers, and colleagues ruining your enthusiasm. The pattern suggests strategies to protect and add on to your passion. One is to focus on aspects you genuinely enjoy and dedicate time, even outside work, to pursuing these interests. The authors cite Paul Graham’s advice to “work on what you like.”
Another strategy is to seek out “kindred spirits” – joining user groups, participating in forums, and starting a blog to connect with others who share your passion. These interactions can renovate your thought process and provide a supportive community. The pattern also encourages studying the “classics” of software development literature, as you involve yourself in the great works can open your eyes to a more inspiring world.
Finally, the authors emphasize the importance of drawing your own map – being willing to move to an organization that better aligns with your goals, even if it means leaving a comfortable job. They warn about going against the “hero mentality” that leads to “death marches.”
As an aspiring software developer, I found this pattern insightful. The idea of caring one’s passion, even among adversity, resonates deeply. I appreciate the authors’ acknowledgment of the challenges and their suggestions for proactively addressing them. The priority on seeking kindred spirits and studying the classics is crucial. These activities can help renew my enthusiasm and provide a sense of purpose, even for future career challenges.
Additionally, the authors’ caution against the “hero mentality” and the importance of setting boundaries to protect one’s passion is a valuable lesson. I will be thinking of maintaining a sustainable pace and refusing to compromise my standards.
Overall, the “Nurture Your Passion” pattern provides a compelling framework for approaching my future career as a software developer. By actively protecting and growing my love for the craft, I believe I can navigate the profession’s ups and downs and maintain a granting, fulfilling, and consistent career. Thanks for tuning in!

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.