Category Archives: CS-448

CS-448 Sprint 2 Retrospective

Merge branch ‘verify-pipeline-tests’ into ‘main’ (490e4d29) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / General · GitLab

Last sprint teams were focused on changing the pipeline tests and extensions for certain repositories and so this sprint teams were assigned to verify the correct linters and extensions were added as well as running the correct tests when committing the changes to Gitlab. ReportingSystem General does not build a Docker image nor does it have release number. For this repository, we only need to run the linter pipeline tests and ensure that they all passed with no errors.

Merge branch ‘verifying-that-reportingsystem-10’ into ‘main’ (e7755051) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / Documentation · GitLab

Like ReportingSystem General, the Documentation repository did not need to run through all the pipeline tests in Gitlab such as the build, test, or release stages. This means that we only had the linter tests run through the pipeline when committing any changes to this repository.

Merge branch ‘jlee1999/verifying-that-generatewcfbreportfrontend-38’ into ‘main’ (6e5d198e) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / GenerateWCFBReportFrontend · GitLab

GenerateWCFBReportFrontend is different than the other two repositories that I worked on as it does require pipeline tests such as build, test, and release. Originally, the tests were passed with a warning, which was okay at the time, but our goal was to ensure all the tests passed with no warnings.

Files · jlee1999/research-functionality-122 · LibreFoodPantry / Client Solutions / Theas Pantry / GuestInfoSystem / GuestInfoBackend · GitLab

Once I completed the verification related issues in our sprint backlog, I shifted focus on the first steps of hot reloading GuestInfoBackend servers for development mode. First, I researched what the command “nodemon” is and how I can properly integrate it into the code. This command allows for the server to restart after any changes are made in the folders specified prior. I created a separate folder in this branch called “express-example” with a simple JavaScript file as well as the package.json file and any other required files needed. This allowed me to mess around with the functionality of the command without completely rearranging the main branch.

feat: merge branch ‘jlee1999/edit-scripts-to-allow-123’ into ‘main’ (f145cdc1) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / GuestInfoSystem / GuestInfoBackend · GitLab

After messing around with nodemon in the sample branch, I was ready to implement it to the main branch of GuestInfoBackend. I was having trouble making sure the nodemon command works while also ensuring the pipeline tests passed. If I was able to get the pipeline tests to pass then the functionality of nodemon was not working, and if nodemon was working then the pipeline tests would fail. I was struggling trying to figure out why this issue kept occurring, but after a while I was able to get both the functionality to work along with the pipeline tests to pass simultaneously. The cause of this problem was because the repository was using both npm and yarn when building the pipeline tests which caused problems. I decided to stick with strictly npm for the repository which then fixed the issue.

Files · update-checkinventory-29 · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / CheckInventoryFrontend · GitLab

I did not get to work too much on CheckInventoryFrontend this sprint but was able to get a general idea of some issues that could be arising. I noticed that this repository also has both npm and yarn together which has caused some issues with the pipeline tests. Hopefully the next sprint my team and I can solve this issue and provide a simple and working frontend for the InventorySystem.

This was the second sprint for the team, and I believe that it went better this time around compared to the first sprint. I felt more comfortable with the whole set-up of our sprints and the team was able to get the work done we needed to. Around half of the issues this sprint revolved around verifying pipeline tests and extensions in repositories that will help in the future to allow people to focus on bigger parts of the project with more ease. While I worked on 3 of the issues around verifying pipeline tests, our team had 5 overall which made it easy for us to communicate what worked for the other issues. The continued work in Gitpod/Gitlab has gotten me even more comfortable committing changes along with merging branches. There was only one issue that I messed up the commit message when squashing the commits for GuestInfoBackend, but it did not affect the overall functionality of the repository and the pipeline tests were still able to pass.

While I would like to say everything worked out perfectly during this sprint, it would be a lie. There were some small hiccups in progression through this sprint, but I would say it was less severe than the issues holding us back last sprint. I believe the higher level of comfort in the progress helped allow the team to get passed any hiccups. The biggest issue I was running into was during the GuestInfoBackend issue about hot reloading the servers. I touched on it earlier, but the combination of npm and yarn in the repository was causing me the most issues during this sprint, but I was able to solve it before the end of the sprint which was the goal.

Overall, I believe the team can still improve on communications in some respects, but I would say we were all on the same page more often this sprint compared to last. I would make sure I would notify the team in Discord about any issues I was running into or if I needed a review on a merge request, and the team would be able to see it and help continue the progress of the sprint. I did a better job this sprint focusing on one issue at a time rather than trying to work on multiple issues at once.

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

During the course of this sprint, I spent most of my time looking at the ReportingBackend repository to figure out what was going wrong with the testing suite. I also had assigned myself to configuring the pipeline specifically in ReportingAPI with the linters, but unfortunately was unable to complete this issue because the team responsible for actually adding the linters to the repository was not able to push their changes before the sprint ended. I continued to act as the scrum master for the team, taking an active approach to making sure everyone is doing work, getting credit for their work, and setting up meetings when necessary. I had to help out a bit with other team member’s issues as well, providing some guidance.

Verify the Testing Suite works: Investigate the testing suite and see if I can get it to work, or at least figure out the magnitude of the problem. I applied a couple of fixes (one of which was in the build.sh script that I had a separate 0 weight issue created for, as I had already found the bug and fix prior to the sprint starting.), but it seems like the issue transcends the testing suite and is moreso an issue with the build process with the server.

This sprint was pretty rough, if I’m being honest. For what we did well, our communication overall improved, and the team was better able to utilize GitLab for their work. I think that everything on GitLab was better organized and most of the issues had better descriptions on them than what we had last sprint, and the weight assigned to issues seemed fairly accurate all things considered, aside from the testing issue (which I did spend a lot of time on). We also did work with each other more than we did on the last sprint.

Most of the issues that were assigned to our team were rushed together during the last week of the sprint (from my perspective at least, there may have been some confusion with pushing to GitLab). As such, we weren’t able to get to all of the issues, and only got 14 weight out of the 24 weight assigned to our team fully merged in. I was offering support during the whole sprint, but it seemed like team members were not able to coordinate into a meeting at the same time for most of the sprint. I don’t really have a great reasoning for this, it seems like things weren’t being done until the time was very short to were we couldn’t get everything done, taking all of our other schoolwork into account.

Ultimately, I think for next sprint our team really just needs to work on spreading work out during the entire sprint rather than getting things done last minute. We should also work on coordination and being more present, as when anyone asked if we wanted to do a meeting, the team would all say they were available and no one would take the initiative to actually begin the meeting. Part of that is on me as scrum master, but ultimately we should be willing to meet without having everyone on board if we are working on specific issues.

I was able to spread out my work fairly well as an individual, but I can’t say the same for other team members, and so as scrum master I should be more active in making sure everyone is doing their work not just so the project moves forward, but so everyone gets the credit they need for the course.

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

Draw Your Own Map

The draw-your-own-map pattern talks about how people should take control of their career paths and not rely on others to define their path. This pattern talks about identifying the next logical steps, visualizing how to achieve those steps, and continuing to evaluate their goals and values. Draw-your-own-map pattern suggests that getting help from like-minded people and being open to adjusting one’s map to any changes that came up. This pattern shows stories about people who go into programming despite challenges from employers and orginizational limits. Draw-your-own-map encourages people to set a specific goal rather than setting a goal that isnt reachable. That step not only helps provide feedback but it also makes you seek guidance from like-minded people, those people can give you resources and support when trying to achieve your goals. One of the key ideas of this pattern is flexibility, it supports the idea of one’s mind to keep reassuring themselves that it’s okay to make changes. This pattern promotes an approach to career development and make sure to empower people to find their way through there careers with a purpose.

I thought this pattern was interesting because it encourages people to be creative and not rely on other people to define our paths, it should be our decision. I also thought the steps that the pattern talks about was very helpful, it’s important to set realistic goals so that you don’t overwork yourself to reach that goal. Visualizing the steps to achieving those goals also help make sure you don’t rush through the process and able to have a set plan. Evaluating your goal and values are also important as you go on to make sure that you can still reach your goal and be okay with any changes that come. This pattern has changed the way I think about achieving my goals, I know now to set a more realistic goal for myself and not be scared to get help from people who think like me. I don’t disagree with this pattern because I feel like this will help a lot of people with reaching their goals and make them think more realistically while getting support from others.

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.

Expand Your Bandwidth, Expand Your Mind

In the fast paced Software Development field, staying ahead is not just advantageous but essential. Yet, many of us tend to find ourselves stuck in a rut, focused solely on the task at hand and neglecting the broader landscape of knowledge and innovation. The Expand Your Bandwidth pattern emphasizes the importance of continually expanding our knowledge and skills beyond just the day to day tasks we complete. Additionally, the importance of actively seeking out new information and participating in various learning opportunities to help accelerate our professional growth.

What I found particularly interesting regarding the pattern is the notion that we all want to achieve mastery following the long road, but achieving that mastery level is more than just mastering a specific technique or technology, but rather about cultivating a broad and adaptable skill set. The pattern also presents an analogy for learning through a straw and a fire hose. By immersing ourselves in a fire hose of information, while it may be overwhelming, is incredibly empowering. Therefore challenging the notion of compliance and encouraging us to continually learn, explore, and experiment.

After reading more about this pattern, it has changed the way I think about my approach to learning and professional growth. Previously, I tended to focus solely on completing immediate tasks, projects, and work, ignoring the broader landscape of knowledge and innovation. However, this pattern has inspired me to adopt a more expansive mindset and go out of the box to seek different opportunities for learning and growth. 

While I embrace the message from this pattern, I do think it is important to limit how much information we try taking in all at once. If we don’t manage all the information properly or carefully, it could lead to an information overload and overwhelm or stress us out.

With this being said, the Expand Your Bandwidth pattern helps serve as a powerful reminder of the always changing and evolving field and the importance of continually trying to learn more and more to increase our skillset. By embracing this pattern, I am confident that I will not only enhance my skills as a developer but also create a mindset of lifelong learning and adaptation, which is essential for success in our dynamic field.

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

“Expose Your Ignorance”: Transforming Vulnerability into Strength

Summary of the Pattern: “Expose Your Ignorance” is a pattern that challenges the common fear of appearing unknowledgeable in professional settings. It encourages individuals to openly acknowledge the areas in which they lack understanding or skill, rather than concealing their ignorance. This approach is presented as a method for accelerating learning and building genuine connections with colleagues who can provide support and knowledge. The pattern emphasizes that admitting ignorance is a step towards expertise, as it directly confronts what one needs to learn.

My Reaction: Encountering “Expose Your Ignorance” was both a relief and a revelation. It addresses a deep-seated fear many of us have: the fear of being judged for what we don’t know. This pattern not only normalizes but celebrates the act of admitting ignorance as a courageous step towards personal and professional growth. It has made me reconsider how I approach learning and collaboration, highlighting the value of vulnerability as a tool for building trust and fostering an environment where knowledge sharing is encouraged.

Insights and Changes in Perspective: This pattern has significantly shifted my perspective on learning and growth within professional contexts. Rather than viewing ignorance as a weakness, I now see it as an opportunity—an invitation to learn and to invite others into my learning journey. This change in mindset has encouraged me to be more proactive in asking questions and seeking out resources, knowing that each act of vulnerability brings me closer to the expertise I aspire to.

Disagreements and Critiques: While the ethos of “Expose Your Ignorance” is powerful, it’s important to acknowledge the varying degrees of safety within different workplace cultures for such vulnerability. In environments where admitting ignorance is not valued or might even be penalized, applying this pattern requires careful navigation. Thus, while I agree with the principle, its application must be adapted to the specific dynamics and culture of one’s workplace.

Conclusion: “Expose Your Ignorance” has profoundly influenced my approach to learning and professional development. It has taught me the strength in vulnerability and the importance of creating a culture that supports growth through openness and curiosity. I think that it is a very strong tool to learn new skills and to master old ones. I have used it many times in the past when feeling overwhelmed about a large task or a new topic. As I continue in my career, I am committed to living this pattern, fostering environments where ignorance is not a stigma but a starting point for collective learning and innovation.

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.

CS-448 Week 9 Be the Worst

The “Be the Worst” pattern encourages you to surround yourself with individuals who excel in their craft, even if it means being the least skilled person in the group. By doing this, you engage yourself in an environment that fosters continuous learning and growth, as it exposes individuals to new perspectives, challenges, and techniques that may not occur otherwise.

I find this pattern both interesting and thought-provoking because it challenges the traditional notion of seeking out environments where one is the most skilled or experienced. Instead, it encourages the embracement of discomfort and for individuals to seek out opportunities for improvement, even if it means initially feeling inadequate or out of place.

Embracing this pattern has caused me to reconsider how I approach my career and professional development. I have been inclined to seek out roles or teams where I felt confident in my abilities in the past, always fearing the possibility of struggling or being overshadowed by more experienced peers. However, I can see the value in seeking out environments where I am the weakest member after my reflection on this pattern. This will give me the chance to push myself to learn and grow at a faster pace, ultimately becoming a stronger and more versatile developer.

While I generally agree with the principles outlined in this pattern, I do acknowledge that it may not be suitable for everyone or in every situation. Some individuals may thrive in environments where they are the most skilled, finding comfort and confidence in their expertise. Additionally, constantly being the least skilled member of a team can be emotionally challenging and may require a certain level of resilience and self-confidence to navigate successfully.

Overall, the “Be the Worst” pattern serves as a reminder of the importance of humility, curiosity, and continuous learning in one’s professional journey. By seeking out opportunities to surround oneself with individuals who are better than them, individuals can unlock their full potential and achieve greater success in their chosen field.

4. Accurate Self-Assessment | Apprenticeship Patterns (oreilly.com)

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.

Retreat into Competence

This week I decided to write about the pattern called “Retreat into Competence”. This pattern discusses the common occurrence of feeling out of your depth and what you should do about it. In the past couple of months,  I have been confronted with the depths of my lack of knowledge and realized just how overwhelming it can be. It is for this reason that I chose to read about the suggested solutions for this pattern.

The solution provided for this issue is to retreat into your knowledge to regain composure and then “then launch forward like a stone from a catapult”. This method will allow you to realize how far you’ve come and recognize what you are capable of. You need to overcome your fear of incompetence to grow. I agree with the statement that “sometimes you need to take one step back in order to take two steps forward” and how it is important to focus on moving forward as quickly as possible. It took me some time to reflect on this solution but I think this is because if you don’t force yourself to focus on moving forward you can get stuck by being too comfortable. 

For the most part, I agree with the text. It is definitely a risky solution because it is important that you recognize that it is only a temporary fix. You need to be honest with yourself and have discipline to stick to a time limit as suggested in the last paragraph. Although this is a good solution for certain situations and/or certain types of people, sometimes I think you just need to throw yourself into learning the new material. In the recent projects I worked on where I realized the extent of my ignorance, I decided to dive right into some resources to help me learn. I was working with tight deadlines and had to learn as much as I could to be a useful team member. Regardless of this fact, the core of this section gets one thing right, to do anything you must first tackle your fear of incompetence and inadequacy. Although my first solution is to dive into new material, I may come across a situation where it will be more helpful to take 2 steps back. This solution was definitely interesting to read about because it is very different from my usual approach.

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.

‘Sweeping the Floor’ Pattern

The ‘sweeping the floor’ pattern in chapter four pertains directly to the beginnings of an apprenticeship or just work in software in general. This pattern explains that when you first begin the process of working in software while you will not be nearly as knowledgeable or efficient as the other members of your team with more experience you will still be able to contribute in smaller or more simple ways in order to still provide assistance and work with your team as you learn how to do more technical tasks. This strategy can be applied in every field as when you start your career or even when you start a part time job in high school you first have to be taught how to do certain tasks in the correct way but while you learn how to do the more complicated tasks correctly you will still be able to put effort into making tasks easier for others who are already able to do the more complicated tasks that come with your job.

This pattern stood out to me as I believe that this is especially important to remember when you are entering any job or looking to start your career after college as the thought of ‘not knowing’ how to do the more technical tasks can be daunting for people at times as they see it as a massive obstacle you must overcome when in reality you are not expected to be able to do every task that more experienced team members are able to do. You are expected to contribute in any way you can to help your team work and provide insight while also remembering to continuously learn along the way in order to enable yourself to do these tasks in the future so that one day you are the ‘more experienced team member’ that someone looks to for guidance. Advice like this is important for college graduates that are just starting their careers as in most cases our first jobs will be learning experiences that we need to embrace and make the best of in order to further our understanding of both the field and our colleagues. 

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.

Breakable Toys

Breakable toys are small programs you can develop and alter freely, without repercussions if something goes wrong. Often expecting something to go wrong as we learn more from our mistakes and successes. This freedom allows you to experiment and push your limits, creating an opportunity to further develop your knowledge in whatever program or system you are working with.

Reading this pattern has made me realize that almost everything I know about programming has been learned through breakable toys. I have always treated school assignments as breakable toys, with a deadline for no longer being broken. Trying to add features to the project that would force me to learn something new. Through trial and error and not just learning what works and what doesn’t but understanding why they do or don’t. Sometimes, revisiting old projects well past their due date to add features. My go-to breakable toy when learning a new language syntax has always been a decimal-to-binary calculator that can eventually support other bases.

Understanding how big of an impact breakable toys have had on my programming skills, I realize the importance of revisiting them along with making new ones to grow my toolbox. The reading provided a lot of good examples of breakable toys that I can work on and develop in the future. As someone who uses a wiki daily, I have never thought about developing my own until now, and as the reading suggests it would provide a lot of opportunities to develop new features as I go. Other important breakable toys will continue to appear as I learn more

Moving forward I am going to make sure I always have a breakable toy that I am working on and developing. To have many breakable toys at my disposal when it comes to solving problems in projects that do not have the luxury of being breakable. Getting ideas and inspiration for new breakable toys is going to be based on what skills I need to focus on. With those required for my profession at the forefront of the list of breakable toys I need to work on.

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

CS448 Software Development Capstone: Apprenticeship Patterns – “Reading List”

After my week of spring break, I’m looking to get back to building constructive habits and reinforcing my software development fundamentals. I was inspired to return to this chapter of the “Apprenticeship Patterns” textbook because I recently learned about a computer science problem called the Circle-Ellipse problem.

This hypothetical problem is meant to highlight the limitations of the object-oriented programming paradigm, specifically when using subtype polymorphism in your class design. In the Circle-Ellipse problem, two classes are defined, Circle and Ellipse, with the Circle class inheriting from the Ellipse class. The Ellipse class includes two member methods, stretchX() and stretchY() which can modify, or mutate, two private member variables of Ellipse each representing an X and Y coordinate. The programming language understands all instances of the Circle class as also being instances of the Ellipse class with this inheritance relation. The problem arises when considering the requirements of a subclass. A subclass needs to implement all the member variables and methods of its parent. The Circle class needs to implement stretchX() and stretchY() as a subclass of Ellipse. Using either of these methods to change the dimensions of the Circle would consequently make that object no longer represent a mathematically correct circle.

As this problem was explained to me, the Liskov Substitution Principle was mentioned. I remember reading about this principle as one of the 5 SOLID software design patterns. The Liskov Substitution Principle essentially states that in a program using subtype polymorphism, an object ought to be able to be substituted by one of its subclasses without breaking the program. The Circle-Ellipse problem represents a violation of this principle because an Ellipse cannot be substituted for a Circle except in one very specific case.

I hadn’t considered the limitations of inheritance relationships in software design before learning about this problem. I decided that after the lecture where I learned about the Circle-Ellipse problem, and after seeing so many titles and authors name dropped in “Apprenticeship Patterns”, that I should start compiling a reading list and start more intentionally defining my daily schedule, including time for reading about software design and computer science. I started with a summary of the Circle-Ellipse problem, and then went through the appendix in “Apprenticeship Patterns” to choose a few books that the authors cited the most often.

The pattern introduces the possibilities of making your reading list public on the internet or using an existing list to source further reading material. The reader is also prompted to look ahead to the future and maintain the reading list to use for reflection on their learning journey.

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.