Category Archives: CS-448

CS-448 Sprint 3 Retrospective

Files · jlee1999/check-documentation-and-39 · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / GenerateWCFBReportFrontend · GitLab

Since the last sprint my team was assigned to verify the pipeline tests and linters for this branch, I worked on looking over and adjusting the documentation in the repository to match any changes made. When I tried to run the frontend, however, it was not loading properly. After looking at the documentation, I worked on fixing the front-end functionality or at least making progress in it to set up the students next semester that will be working on it.

feat: merge branch ‘jlee1999/fix-documentation-in-guestinfobackend-126’ into ‘main’ (32d05a94) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / GuestInfoSystem / GuestInfoBackend · GitLab

Like GenerateWCFBReportFrontend, my team worked with GuestInfoBackend last sprint to implement nodemon into the repository so that developers can hot reload the servers whenever they adjust the code in the source folder. After making those changes, I worked on matching the documentation with the previous changes to make it easier for other people working in the repository to know how to run the backend in production mode versus development mode.

Files · implementing-nodemon · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / CheckInventoryFrontend · GitLab

Over the course of the semester, my team has been working in the CheckInventoryFrontend repository to work on different issues. One thing we were struggling with was getting the front end to load properly to see the layout. In this branch, I was able to fix the front end to load properly so that we as developers can see what the layout will look like to the client. I also worked on implementing nodemon in this repository to hot reload the backend servers to put it in development mode.

Files · jlee1999/fix-documentation-in-the-39 · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / CheckInventoryFrontend · GitLab

This issue dealt with fixing the documentation in the CheckInventoryFrontend repository to match all the changes my team has made throughout the semester. We worked on setting up the repository to look like GuestInfoFrontend which made the repository more organized and easier to navigate. With all those changes, however, the documentation that was previously there was now outdated. While it might not be as glamorous as other work, adjusting the documentation is important and will help future developers when they start working on this project.

This was the last sprint for the semester, and I believe that it went as well as the last sprint. Each team member was tasked to do specific issues that did not necessarily need work from multiple team members at once, which helped spread the issues throughout each of us. The one issue that required multiple team members at once was the overall updating of CheckInventoryFrontend but we were able to split up that big general issue into smaller problems that each member can focus on in their own time. I continue to feel confident in the gitlab setting and have had an easier time navigating through each repository and have improved in that aspect compared to the beginning of the semester.

I will say what changed from last sprint to this sprint was the decrease in communication throughout the team, but I do not think it hindered our progress as much as it would have previously. Since the issues could be worked on individually, we would still update each other through the stand-up meetings and were able to get enough progress through the sprint to reach our goal. There was sometimes confusion amongst us on what part of CheckInventoryFrontend to work on.

As previously mentioned, I think communication amongst the team could have improved which would have only increased our team’s production throughout the sprint. I am not sure why it dropped this sprint, but there were times where I would try to message the team to get something approved or ask for progress through their issue, the communication would be delayed. It did not completely hinder us since we still fixed enough issues to reach the weight requirement as a team. I started to get the hang of focusing more time and energy on one issue rather than multiple at once but also knew when it was time to stop before hitting a wall.

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

After finishing our last sprint I believe it went very well compared to our last two sprints. Our team did a great job of communicating, time management, and ensuring everyone’s ideas were heard. We also made sure that issues were assigned equally and that our issues weren’t sitting in needs review. I believe we didn’t have any issues for this sprint since the last two gave us a better idea of what we needed to do this time. As a group of 5, we needed a weight total of 25, we managed to complete over 75% of our issues. Since the last sprint, I believe we made a lot of progress as a team and managed to get through this sprint without any issues.

As a team, I believe we made a lot of progress in this sprint and didn’t have any issues to work on. We made sure to communicate with each other about how everyone’s progress was going on with their issue and if they needed any help with anything. The reason why we managed to get through this sprint is because of our communication and teamwork. Like I said earlier I believe that as a team for this sprint, we didn’t have anything that we needed to improve on. Our working agreement helped us get through these sprints by making sure we were straightforward with everyone and that we got to improve each time. Based on the last two sprints, we’ve grown improvement-wise. We made sure to stay on top of any work that needed to be reviewed, communicated with each other, assigned issues equally, and managed our time very well. I enjoyed working with my team members and was glad that we were able to complete this sprint without any issues.

As an Individual I believe I made a lot of improvements since the last sprint. I made sure that the work was even spread out between me and the team, I also made sure that we stayed on top of reviewing each other’s work. The issues I worked on were Update and Review Documentation GuestInfoSystem and a couple of group issues like Determining what needs to be done in GuestInfoFrontend. I made sure that the guestinfo system documentation had the right extensions, linters and that the pipelines were working. Then as a group, we worked on the GuestInfoFrontend and created a couple of issues that next year’s students can work on for their sprint. Some issues we created were moving “Other Assitance” attribute and moving receiving unemployment attribute to assistance. Those issues will help the GuestInfoFrontend look cleaner and see what is missing in the code that for some strange reason gave us a harder time to deal with. With this being our last sprint I can proudly say that our group did a great job in getting the work done and communicating with each other. By learning from our mistakes we were able to get through this sprint without any troubles and managed to get it done quickly.

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

Sprint Retrospective Blog #3

Hi everyone, my name is Abdullah Farouk, for those who don’t know me by now, 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 this semester. This sprint consisted of us getting more familiar with libre food pantry more and to see how this scrum framework actually go and went more in depth into the actual system. 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 team member 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 the we massively on was how we weighed the issues in the beginning. Compared to the first sprint, Some of the issues took less than what we had anticipated, and some took way longer, but this sprint we got it spot on and managed to finish all the issues on the board just in time. Another thing that we improved on was communicating outside of class time. I started privately messaging class mates for updates if they haven’t said anything in days. One thing we still didn’t do well was 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 that one issues, I think me, and the team did a great job going through these issues and completing them on a timely basis. I worked on multiple issues for this sprint that I will list at the ends, but mostly I was trying to clean up code and made sure anything that I had left unfinished, was either finished or deleted so the next class is not having a headache trying to figure out why it’s there. I also checked a couple of my classmate’s issues that needed to be reviewed in order to merge to main. I also worked on. I also learned a lot about nodemon function and have a basic understanding of how it works and how to properly integrate it.

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

  • Update CheckInventoryFrontend

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

  • Verifying that ReportingAPI has correct extensions and linters

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

  • Think and write down possible ways to further enhance the CheckInventoryFrontend

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

  • Examine GuestInfoFrontend with its wireframe to see if there is any helpful code that can be shared

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

A New Belt, A New Perspective

This week I chose to read “The White Belt” section under “Emptying the Cup”. This pattern calls for one to fully embrace the beginner mindset when faced with new learning opportunities. It encourages placing preconceived ways of thinking aside when tackling new situations to do so with a clean slate to allow for new perspectives to be formed. By subscribing to this mindset, one can increase their learning and understanding of different languages which in turn will aid them to progress their path as a craftsman forward.

This pattern highlights the importance of learning in professional growth because, in today’s rapidly evolving market, the ability to adapt and learn new skills is crucial for staying relevant and competitive prospects. Reaching a certain level of expertise may cause one to fall into complacency or build a reluctance to venture into unfamiliar territory.

What I find insightful about this pattern is its analogy to martial arts, where the white belt symbolizes a beginner’s journey toward mastery. Just as a martial artist must approach each new technique with a fresh perspective, a software craftsman must be willing to let go of their preconceptions and embrace the unknown. This pattern serves to remind readers that mastery is not a destination but a continuous journey of growth and self-improvement.

The pattern also highlights the discomfort that can accompany stepping outside of one’s comfort zone, especially for experienced craftsmen. As someone who takes pride in their expertise, it can be challenging to admit ignorance or make mistakes. However, the quote from George Leonard reminds us that embracing foolishness and spontaneity is often the key to unlocking creativity and innovation.

I appreciate the advice provided in the pattern, such as unlearning something familiar or exploring new programming paradigms. This encourages craftsmen to actively seek out opportunities for growth and challenge themselves to expand their horizons.

While I agree with the overall premise of “The White Belt,” I recognize that fully embracing a beginner’s mindset requires courage. It’s not easy to admit when we don’t know something or to let go of our old ways of thinking. However, as the pattern suggests, the benefits of adopting this mindset far outweigh the temporary discomfort one may feel.

In conclusion, this pattern serves as a powerful reminder of the importance of courage, curiosity, and continuous learning in the development of one’s craft. By embracing a beginner’s mindset, craftsmen can unlock new possibilities, foster innovation, and ultimately reach greater levels of mastery in their chosen fields.

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

Sprint Retrospective #3

Overall, I believe the second sprint went well. Like the previous sprint, we had meetings in person or over discord. All in all, I believe we all did a fantastic job of keeping each other updated and asking each other questions when we got stuck. I noticed that once we finished one issue, nobody hesitated to start another issue which really helped us with moving the project along. During this sprint, we worked on several of the issues as a group. We kept up the open-mindedness, accountability, honesty, and respect that were originally described as the culture we hoped to establish in the working agreement. Like in the previous sprints, we determined the maximum amount of work that each person should attempt to finish in order to split the work fairly and equally in regards to the issues we had, and we mostly adhered to it.

I worked on multiple issues that involved verifying that the pantry projects had the correct extensions, linters, and pipeline stages. Like the last sprint, I looked over the project’s file types, created a list of required linters based on the files, added any new linters, verified that the new linters passed, verified which stages were required, and adjusted the stages as necessary. For this type of issue, I worked on “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages – InventorySystem General” by myself and then worked on “Verifying that InventoryAPI has the correct extensions, linters, and pipeline stages” and “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages – Inventory Backend” with the group. When working on the issue for InventorySystem General, I realized that the build and test scripts weren’t needed so I also removed those files. I also worked on “Determine what needs to be done on GuestInfoFrontend” with the group. For this issue, we reviewed comments left in the code, wireframe, and documentation. Then if any work worthy of note needed to be done, we created new issues for them. We created these issues (“Moving “Other Assistance” attribute” and “Moving Receiving Unemployment Attribute to Assistance”) and linked them to the initial issue. 

I think we did really well as a team for this sprint. We did not get around to establishing a method that will guarantee that particular individuals are not examining the majority of issues, as we had originally intended when drafting our working agreement. For this sprint, we did not discuss how we would make sure to stay on top of issues that needed to be reviewed because many of the issues included us working together and we stayed on top of a lot of the issues. The time frame between finishing an issue, reviewing, and merging was a lot shorter than the last sprint. We made sure to constantly communicate with each other and the first one that could review an issue took the task. As a group, I can see that we improved a lot in that regard but I still think we could establish a method to make sure that reviewing code is not done mainly by a few individuals in the group. As an Individual, I showed a lot of improvement by checking on what needs to be done compared to the previous sprints but I think I can still improve when it comes to merging my issues as quickly as possible after they’ve been reviewed.

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.

Finding Your Different Road in Career

Introduction

In the journey of our careers, it’s not uncommon to reach a point where the road we’ve been traveling no longer feels right. Maybe it’s the urge for more time with family, the pursuit of a new passion, or simply a desire for change. Whatever the reason, it’s important to recognize that diverging from the familiar path doesn’t mean getting lost.

Sometimes, after diligently following the path laid out before us, we realize that it’s not leading where we want to go. The “Different Road” pattern acknowledges this pivotal moment, encouraging us to reflect on what truly matters to us.

Letting Go of the Long Road:

Embracing change often means bidding farewell to the familiar. Whether it’s stepping away from a successful career in software development or leaving behind a role we’ve invested years into, it can be daunting. However, the pattern reminds us that this departure doesn’t have to be permanent. Instead, it’s an opportunity to explore new horizons and grow in unexpected ways.

One of the most valuable aspects of taking a different road is recognizing that the journey doesn’t erase the experiences we’ve accumulated. Like Dave, who transitioned from family therapy back to technology, our skills and insights remain with us. Whether we’re teaching, parenting, or pursuing other passions, the problem-solving mindset and analytical skills we honed as software developers enrich our new endeavors.

Navigating Challenges

Leaving the Long Road might come with its own set of challenges. Some may fear judgment or difficulty reentering the software development field after a hiatus. However, as Larry’s journey illustrates, the skills acquired in one domain are often highly transferable. Additionally, the experiences gained from pursuing other interests can bring fresh perspectives and creativity to our work when we return.

If you find yourself considering a different road, start by exploring what else you might enjoy doing. List potential jobs or pursuits that intrigue you and speak to people who are already on those paths. Hearing about their experiences and comparing them with what you love about software development can provide valuable insights.

Conclusion

Embracing change in our careers can be both exhilarating and challenging. However, by recognizing when the Long Road is no longer the right path for us and bravely venturing onto a different road, we open ourselves up to new possibilities and opportunities for growth. So, if you’re feeling the pull of a different road, remember, it’s okay to take that leap. Your journey is yours to define, and the experiences you gain along the way will shape you in ways you never imagined possible.

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.

Drawing Your Own Career Map

Have you ever felt like your career path doesn’t quite fit the mold provided by your employer or the traditional trajectory laid out by society? You’re not alone. In fact, many professionals find themselves in this position, yearning for something more but unsure of how to break free from the constraints imposed by their current roles.

Enter the concept of “Drawing Your Own Map.” This pattern, inspired by real-life stories and experiences, encourages individuals to take the reins of their career paths and chart a course that aligns with their aspirations, interests, and values.

Imagine this: you’re at a crossroads in your career, feeling dissatisfied with the options presented to you. You realize that your employer’s idea of your career path doesn’t quite match your own vision. What do you do? You draw your own map.

This concept urges you to identify an ambitious yet logical next step for your career, irrespective of what your employer or career counselor may suggest. It’s about taking ownership of your professional journey and understanding that you have the power to shape it.

But how do you go about it? Start by visualizing the smaller, interim steps needed to move forward. These steps may seem insignificant at first, but they generate the momentum necessary to propel you toward your goals. It’s about taking that first terrifying step, even without a perfect plan, and trusting that you’ll figure it out along the way.

One of the most thought-provoking aspects of this pattern is its emphasis on defining small, achievable goals. By breaking down your aspirations into manageable tasks, you not only make progress but also gain valuable feedback that informs your journey.

Perhaps what’s most inspiring about this approach is its recognition that there’s no one-size-fits-all path to success. Each individual’s career map is unique, shaped by personal values, interests, and circumstances. It’s about finding your own route through the wilderness, even if it means deviating from the norm.

Now, you might be thinking, “But what about external constraints? What if economic conditions or family responsibilities limit my options?” Valid concerns indeed. The pattern acknowledges these challenges but encourages you to find creative solutions and challenge accepted norms.

In conclusion, drawing your own career map is about embracing personal agency, taking calculated risks, and continuously adapting to change. It’s about recognizing that your professional journey is yours and yours alone, and you have the power to redefine it at any time. So, grab a pen and start drawing your map. Who knows where it might take you?

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.

Retreat into Competence

Summary:

Retreat into competence is a pattern that involves taking a break from a challenging task to work on something you are more comfortable or confident in. This helps a developer reflect on how far they have come and can keep them motivated to move forward. Patterns may emerge that show how you got proficient in that task. These patterns can then be used to advance your current tasks. Motivation can also be a problem if someone is constantly getting stuck on a task, or just not being able to progress a project forward. Being able to step back and complete a more familiar task can help keep up the drive during the long road.

Reflection:

This pattern really popped out at me originally for the “Context” and “Problem” sections, as I have felt very overwhelmed many times finishing up my college degree. There have been countless times that I have questioned if I have learned enough for my degree. Each semester felt like it only introduced me to a whole new branch of computer science that I didn’t know. Even the classes that had focused on more advanced topics still felt like it was only just the tip of the iceberg.

There have been a few times this semester that I have been stuck on an issue and just could not figure out where to start looking for a solution. It can be really demotivating when you are unable to complete a task that other people are relying on you to complete. Taking the time to work on another issue helped me in both ways mentioned above. Solving an issue that I was confident I could do made me realize what steps I needed to follow to work on the other issue. Not only this, but being able to actually complete an issue kept my motivation up as I felt like I was contributing to the team.

When I first read through this pattern I originally thought mostly about the motivation and satisfaction aspects of being able to complete a task that is familiar to you. However, as I read through it and began to understand more about what you could learn from working on more approachable projects. Paying attention to and understanding the patterns and steps one takes to solve familiar problems can be used to solve new or challenging issues.

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

Stay in the Trenches

The “Stay in the Trenches” pattern is a reflection of the temptation to prioritize promotions and managerial roles over staying engaged in programming, which is usually a developer’s passion. This pattern draws attention to the societal pressure to achieve success with upward mobility, highlighting the importance of sustainable motivations and the long-term commitment required for mastering software development. The pattern begins by addressing the common idea of being offered a promotion away from programming due to someone’s proven track record of delivering amazing work. While promotions are usually seen as signs of success this pattern challenges that notion. It emphasizes the risk of losing touch with the craft and the journey toward mastering when you step away from programming roles. The solution is to resist the given promotions that take you away from programming. Instead, it encourages people to negotiate with their employers for alternative forms of recognition and rewards that allow them to stay in programming. These alternatives may include increased pay or non-traditional technical leadership roles that still involve hands-on coding.

The main message of the “Stay in the Trenches” pattern is about keeping the passion for software development. Its about staying true to one’s love for coding and finding ways to balance career growth with meaningful work in programming. By rejecting promotions that lead away from programming, individuals can maintain their passion and commitment to the craft. This pattern challenges the usual idea of success and encourages to rethink of what truly motivates us in our careers. It helps remind us that staying connected to our passion and purpose is important for long-term fulfillment and excellence in software development. This pattern has made me rethink the usual idea of career advancement and success. It shows the importance of staying grounded in what I love to do and finding ways to align my career growth with my passion for programming even though the idea of the promotion maybe. This pattern has changes the idea that true success lies in finding joy and fulfillment in the work we do, even if it means resisting the loads of promotions that might take us away from our passion. The “Stay in the Trenches” pattern is a important pattern that reminds us to nurture our passion for software development by staying engaged in programming roles. It challenges us to focus on meaningful work over success and encourages us to negotiate for rewards that relate with our motivations and values.

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

CS-448: Week 14

Retreat into Competence

This pattern is about how it is easy to get caught up in constantly learning new technologies due to the fast pace of software development, and how to manage the intense pace of learning. The pattern highlights the importance of taking a step back from the fast paced learning and to focus on honing existing skills. Trying to learn the latest tools, frameworks, and methodologies can be overwhelming. Along with the overwhelming feeling of trying to learn many skills at once, there is also a risk of never fully mastering the fundamentals. Therefore it is important to take a step back, and take time to practice fundamental skills.

According to the pattern, being an apprentice is a rollercoaster ride. This is because there is the thrill using newly learned skills to deliver value to the customer, but there is also the terror of realizing how little is known compared to more experienced craftsman and experts. However both are normal and inevitable experiences.

Although the pattern encourages developers to take a break from learning new skills, it also emphasizes how retreating back to competence is to not get stuck in the realm of competence. It is important to be intentional when retreating, as this pattern is only a short term fix. Spending too much time on this pattern can lead to halted learning. Being able to learn something new is a skill in itself; therefore, learning should be practiced unlike any other skill.

In order to prevent the pattern being used, setting a time limit for honing new skills is useful. This is so one does not focus too much on retreating, and helps them stay in the habit of learning new skills. A strategy the pattern suggests is to pick a well understood topic that is self contained, and to reimplement it. This can help regain confidence to propel learning.

Conclusion

I found this pattern to be interesting as constantly learning new technologies can be tiring, so having a strategy to regain confidence is helpful for the future. I particularly enjoyed the analogy of a catapult to represent this pattern. The analogy being that the skill of learning new topics can be launched forward by taking a step back. The pattern has changed the way I view learning new skills, and maintaining old ones.

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.