Category Archives: CS@Worcester

Apprenticeship Patterns – What I Learned

For my capstone course this semester, I was assigned to read and review a book from authors Dave Hoover and Adewale Oshineye, known as Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by our professor, Karl Wurst. The intention of reading this was to ready and prepare myself for the challenge within this course, specifically about my skills in a field and how to cultivate and grow within said field, or “craft” as the book puts it.

To me, the most interesting part about this reading is how they attributed software development to craftsmanship. When I first thought about it initially when it discusses it in the first chapter, I immediately went “yeah that makes sense” but upon reading further and it digging at specific concepts like “what is craft” and “what makes an apprentice an apprentice”, it made me think a lot more about what a “craft” really is. Being an art minor, this definition was one that was important to me, as art in it of itself is synonymous to craft. Being able to compare my work when coding things and my work when I physically create artwork was an interesting turn of events and an epiphany I wasn’t expecting when dropping into this book. The individual breakdowns of each part of what makes craftsmanship what it is was very impressive and made me able to stand in the shoes of the authors.

When reading, I also felt a bit called out on bad habits that I definitely do on a daily basis. For example, the story told in Chapter 2’s introduction, discussing a cup already full, it reminded me of how I tend to get carried away when it comes to discussing what I know and want to share. This comes at, unfortunately, a disregard for the new information I would be trying to learn, much like how the analogy of the story goes. Another thing I felt was important and reflected on my own actions was Chapter 5, discussing how it is important to not use the internet as your only source of learning and information. Initially, I was quick to disagree with this point, as I do NOT enjoy reading in the first place (a.e. look at how long it took me to write this up) but then I sat down and realized that was another bad habit kicking in, as well as my ADHD. While yes, its true that written works contain many important informations regarding to one’s craft, especially in software development, one must also remember that “reading” isn’t the only way to absorb this information, you could find an audio transcript, as an example. Thus did I realize that this point was actually one that was really strong and heavily agreed with.

Overall, I feel further reading may be necessary for me, as this has changed a lot about the way I am thinking not only about this class and working on a development team, but also about myself and habits that I could be working on and improving. If you also would like to read the book, it is hosted here, for free: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch06.html

Until next time! (Which is, soon, because Ill be writing up another post right after this, haha)

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Sprint 1

GitLab Activity

Install npm JWT Library and handle validation on Mock FE/BE issue – created a file called checkRole.js that as of moment takes a token and decodes it, however since Keycloak is not configured yet with the backend, checkRole.js is still not setup for the verification of tokens.

Reflection on What Worked Well

This sprint, I found that my ability to collaborate effectively with my team improved. We established a structured workflow using GitLab issues and merge requests, ensuring everyone was aligned. Team meetings and project reviews were also particularly helpful in maintaining quality and catching potential issues early. Additionally, I felt more comfortable with our tech stack, which allowed me to contribute more efficiently to the project.

Reflection on What Didn’t Work Well

One of the biggest challenges during this sprint was time management and managing expectations of fellow team members. Balancing multiple tasks while delivering high-quality work proved difficult, especially when unexpected issues arose. There were also moments when communication gaps led to duplicated efforts or confusion regarding task ownership.

Additionally, an unexpected bug related to the jsonwebtoken library took longer to resolve than anticipated, impacting our overall sprint velocity. I underestimated the complexity of debugging the issue, and this resulted in delays. Moving forward, I want to improve my debugging strategies by breaking down issues systematically and identifying potential causes earlier in the process.

Another challenge was that some tasks took longer than expected due to unclear requirements. There were times when I started working on a feature only to realize later that I had misunderstood part of the implementation. This led to rework and inefficiencies that could have been avoided with better clarification upfront.

Reflection on Changes to Improve as a Team

To improve as a team, we need to refine our communication and task allocation strategies. One possible improvement is assigning issues to members with clear deadlines and deliverables. This would help eliminate the need to check in constantly about each other’s progress and give everyone enough space to focus on their designated tasks.

Additionally, we could establish clearer guidelines on documentation and issue tracking. Proper documentation would minimize misunderstandings and ensure that we have a reference point if any team member forgets certain project details. This could be as simple as maintaining a shared document with important technical decisions, dependencies, and any issues we encounter.

Reflection on Changes to Improve as an Individual

On a personal level, I need to deepen my knowledge of the technologies we are using and strengthen my overall web development skills. Additionally, I must improve my time management and prioritization strategies to ensure more efficient task completion. Allocating time for debugging and testing earlier in the sprint would help reduce last-minute stress and improve the stability of our work. I also plan to dedicate time outside of sprint tasks to learn best practices and gain a more comprehensive understanding of our tech stack. Finally, I recognize the importance of seeking help sooner when I encounter challenges, as doing so will allow me to work more efficiently and avoid unnecessary delays.

Apprenticeship Pattern: “Be the Worst”

Summary of the Pattern

The “Be the Worst” pattern suggests deliberately placing yourself in an environment where you are the least experienced or skilled person. By doing so, you expose yourself to opportunities for rapid learning and growth by observing and working with more skilled individuals. While this can be uncomfortable, it forces you to improve and challenge yourself continuously.

Why I Selected This Pattern

I chose this pattern because, during this sprint, I often felt like I was struggling to keep up with some of my teammates who had more experience with certain technologies. Instead of being discouraged, I realized that this was an opportunity to learn from them and elevate my own skills. Their feedback and insights helped me refine my practices and problem-solving approach.

How This Pattern Could Have Changed My Behavior

Had I fully embraced this pattern earlier in the sprint, I would have proactively sought out mentorship and learning opportunities rather than hesitating to ask questions. Additionally, I would have taken more initiative in tackling challenging tasks instead of sticking to what I was comfortable with. Moving forward, I plan to embrace this mindset and view my inexperience as an advantage rather than a limitation.

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

Sprint 1 Blog Retrospective

GitLab Issues

SSH Keys:

https://gitlab.com/Libre

FoodPantry/client-solutions/theas-pantry/deployment/gitlab-profile/-/issues/17

I research how to make ssh keys to make logging into the server easier. I created documentation on how and what commands to run to create the keys. Now everyone in the future can create keys to access the server in a safer manner. 

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

Researched into how git pipelines work. I looked into the gitlab_ci.yaml files because that is what I thought we would need. But it seems we’re living in the direction of cron jobs for CI.

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

Tested nginx serving the basic webpage on my browser from the server.

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

Worked on trying to solve the SSL certificate problem with everyone else. 

Reflection

One of the things I think we did well as a team is making use of work class time. Often for our project we hit many roadblocks. We used the class time as a way to put all of our heads together to tackle a problem that was holding us all up. Especially in the first few weeks since I think we are all pretty new to this side of computer science. We would convene and help each understand things like docker-compose or port-mapping. Another aspect that I think we did well was our general attitude and teamwork. I think we were all willing to participate in the conversation and contribute. Though I will admit I was the quietest one. 

One thing I think we need to work on is gitlab issues. First, I think we need to split them up or maybe name them better. I think all of our issues are very broad so it’s hard to talk about what we did because there are so many layers to the issue. For instance, the SSL certificate implementation. It covers a lot of work and troubleshooting so it can be hard to talk about since work can change quickly. Maybe that’s the nature of our project, but I think it’s something we could improve on. On the same note for gitlab issues, you mention commenting on the issue so that it describes what we’ve done. I’m not sure if any of us have done that. And I’m not sure where to do it either. Some of the things I could work on for myself as an individual. I think I need to ask for help more often, either from my team or you. For when I’m stuck or I just need some direction on what to work on next. Sometimes it feels like I’m not doing enough

Pattern

The software pattern that I often talked about during the period of our spring was “Exposing Your Ignorance”. To summarize, in the software industry it is expected that we are professionals and are experienced in our area. However, that is not always the case. Especially for new apprentices like ourselves. It is important to accept that you do not know everything. So ask questions and swallow your pride to allow yourself to learn something new. I chose this pattern because I think we all were a bit inexperienced in this area, but for me especially this was very new. It felt some of this stuff I should have known or I wasn’t really all too familiar with it. Definitely never worked with it before. So very early on I had to accept that didnt much have much to learn as I went along. I read this pattern before the sprint, but I think it’s something I least thought subconsciously. I think it’s just something I incorporate into all aspects of my life. Skill and experience come from time and work. It’s impossible to know everything or understand everything at first. 

.

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

In my CS-448 class, we are working with the Thea’s Pantry system. I was placed on the team that looks at the automated reporting system and we have just finished our first month long sprint. During this sprint one, the first issue I worked on was the Reporting Integration set up issue which was in the backlog from the last team that worked on it (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/issues/27). Then, after finishing with that, I took the next available issue that we had planned for this sprint and fixed that as well (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/issues/29). After testing and requesting a merge for both of my issues, there wasn’t anything else that we had planned for the current sprint and I didn’t want to start on another month long sprint issue, so instead I helped my other teammates troubleshoot, checked their work, and looked into things such as how the final report file is formatted, what information it has, and how we would go about creating a file like that within the code.

I think what worked the best for us was our original plan at the start of the month so that we all knew what we needed to do and could focus on that. For the most part with most problems being from the project backlog, we didn’t work collaboratively that much as the issues were largely separate but during meetings, we would be able to teach each other about the different systems we were working on. We also were able to get all of our issues done with a little time to spare at the end that we used to further develop some of the small things we would have needed to do eventually anyways. As far as what didn’t work well, when starting to help my other teammates, I felt behind in understanding on the system they have been learning for a few weeks and had to catch me up. Fortunately, with the extra time we had, I and others were able to follow along with other’s progress and quickly gained at least a basic understanding of all parts of the system.

During the next sprint, an improvement that I hope we make as a team is to work more collaboratively, even if the problems we are working on are not directly related to development. We didn’t have much of a chance to work on direct collaboration, but for the next sprint given the opportunity now, I hope that we can progress as a team more so that specialized individual programmers. For myself individually, something that I aim to improve on is my workflow. Last sprint I would try to implement code and get it in a semi working state but then would have to go back and reference other parts of the project or research some other system that was involved. In the future I plan to approach the problems first with getting a full understanding of how the system will work when fully operational and then writing the code, rather than going back and forth between coding and learning.

For this sprint, I feel that the apprenticeship pattern that was most applicable to me was Chapter 2’s pattern of emptying the cup. The book’s author talks about this in the context of learning a new language which is somewhat true for myself as I am not very experienced in all the intricacies of how javascript coding works when developing a website. I felt that this pattern described my experience because I had to learn a lot of new systems that I hadn’t used much before. This is my first time working with RabbitMQ or MongoDB and to a lesser extent the workflow of docker and gitlab. Over time, I got better at using these applications but I had to spend time learning them without “working on” the project.

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

Sprint #1: Retrospective

Gitlab Deliverables:

Sprint #1 was a rocky path, but through our group’s collective efforts, we all learned new tools and skills we can implement in future sprints. At the beginning of this sprint, our group agreed that I would be the Scrum Master and, by extension, manage our GitLab activity. In hindsight, this was a perfect designation as I’ve had managerial experience in the past and continue to be a very organizationally driven worker. With these traits, I sought to make our workspace as clear and accommodating as possible, which would provide a strong foundation for our team to begin working. One area I could have improved upon is making sure everyone’s voice is heard. During Sprint #1, my confidence with Linux started at a 2/10, so over the next couple of weeks, I had to refresh my memory while learning new skills. Due to this lack of confidence, I was much more reserved during group conversations as I was trying to soak in as much information as possible. Consequently, I did not explicitly check if everyone felt as if their voice was being heard. Towards the end of the sprint, my confidence with Linux grew greatly. As a result, I was able to participate in group discussions and ensure that everyone was on the same page. 

As a team, our biggest developmental challenge was understanding when problems should be taken on individually or as a group. At the beginning of Sprint #1, my bias weighed heavily towards solving problems as a team as it would grant everyone equal opportunities to learn from hands-on experience. As we soon found out, this approach is costly in time and does not let people engage with topics that specifically interest them. The task that gave us the most hassle was getting the FrontEnd certified so that the Backend could connect with it. This task was our “group task”, which we used working classes to try and resolve. Beyond this “group task”, we each had individual tasks we would look into. This approach to distributing work across teammates and holding each other accountable for learning unique material has been effective so far. After learning a new tool or skill, I request that the individual creates documentation listing the steps or sources they referred to so that all team members have access to what the individual learned. So far, there have been no issues with this approach, and we will continue to refine it in Sprint #2.

As previously mentioned in my review of Apprenticeship Patterns, the pattern that has resonated with me the most this sprint was “Be the Worst”. This self-assessment pattern has allowed me to refresh my knowledge of Linux through completing tasks such as organization and documentation of our completed tasks. This pattern has the individual actively learn and listen to their teammates discuss current issues. From this assessment, the individual can learn from the shared knowledge of the group and will slowly catch up to their level of proficiency. In the case of Sprint #1, my Linux skills were beyond rusty, making me the least proficient in the group. Although I was not able to start helping on the server immediately, I was able to help record our steps. By doing so, I could educate myself on how we approached problems as they arose. Towards the end of Sprint #1, I found my confidence in using Linux and began contributing to the server.

Moving forward, I plan on interacting with the server more, and I have already begun that process by researching encrypted volumes. Additionally, I will continue to refine my skills as our group’s Scrum Master. Now that I am nearly as proficient as other members of my team, I can now focus on making sure we all understand our current goals and have everyone’s voice heard. In terms of teamwork distribution, we have struck a fair balance at the end of Sprint #1. If there is any issue in Sprint #2, I will have to reconsider how we organize and assign tasks. Fortunately, we now have assigned days for backlog refinement, so we can discuss what changes we would like to make during those periods.

-AG

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.

The Software Craftsman’s Journey: Embracing Learning and Growth

Reading Apprenticeship Patterns was an eye-opening experience. Initially, I was confused by the book’s structure, particularly the sections labeled Context, Problem, Solution, and Actions. I assumed the book would be highly technical, filled with complex concepts. However, after I kept reading, I realized that it was quite the opposite. The book is structured in a way that real-life scenarios that apprentices(interns) or newcomers in the software field might encounter, followed by practical solutions and guidance.

One thing that stood out to me was how much I wished I had read this book earlier in my academic journey. As a senior in Computer Science who transitioned from Nursing, my early years in this major felt overwhelming. Learning my first programming language felt like being thrown into the ocean with just one pool noodle. Each new concept learned added another pool noodle, but the struggle to stay afloat was real. This book, had it been introduced in my freshman year, could have served as a guide for navigating challenges, understanding the learning process, and overcoming self-doubt.

What truly changed my perspective was how the book reframes the way we approach learning and problem-solving. It’s not just about memorizing syntax or mastering algorithms but about adopting the right mindset when facing challenges. One of the most impactful insights for me was the idea that learning is an ongoing journey, and it’s okay to struggle. I often get frustrated when I forget concepts I previously learned, but the book reassured me that this is normal. The phrase “You must unlearn what you have learned” resonated with me deeply. It reminded me that forgetting is not failure; it’s an opportunity to re-learn with better understanding. This realization has helped me become more forgiving toward myself when struggling with new skills or concepts.

Chapter two, in particular, resonated with me because it addressed the common issue of struggling to acquire new skills and knowledge retention. I often worry that if I don’t practice something immediately, I will forget it, leading to self-doubt. This chapter provided strategies to combat this issue, encouraging a more structured and patient approach to learning. By applying these principles, I feel more confident in my ability to retain knowledge over time.

Overall, Apprenticeship Patterns is an invaluable resource that I believe all Computer Science students should read early in their studies. It doesn’t just teach technical skills but also offers a roadmap for navigating the emotional and intellectual challenges of becoming a Software Craftsman. While I didn’t find anything in the book that I strongly disagreed with, I do wish it had been a part of my curriculum earlier. This book has reshaped how I view my learning journey, making me more comfortable with the idea that mastery takes time, patience, and continuous effort.

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

Why API Testing Matters: Ensuring Robust Software Performance

The blog post discusses why developers should use API testing and how it is becoming increasingly important, particularly as microservices architecture gains popularity. This technique necessitates that application components work separately, each with their own data storage and commands. As a result, software components can be updated fast without disrupting the whole system, allowing consumers to continue using the application flawlessly.

Most microservices are based on application programming interfaces (APIs), which specify how to connect with them. APIs usually use REST calls over HTTP to simplify data sharing. Despite this, many testers still rely on user interface (UI) testing, particularly using the popular Selenium automation tool. While UI testing is required to ensure interactive functioning, API testing is more efficient and dependable. It enables testers to edit information in real time and detect flaws early in the development process, even before the user interface is constructed. API testing is also important for identifying security flaws.

To effectively test APIs, it is critical to understand the fundamentals. APIs are REST calls that retrieve or update data from a database. Each REST request consists of an HTTP verb (which specifies the action), a URL (which indicates the target), HTTP headers (which provide additional information to the server), and a request body (which contains the data, usually in JSON or XML). Common HTTP methods are GET (retrieving a record), POST (creating a new record), PUT (altering a record), PATCH (partially updating a record), and DELETE. The URL specifies which data is affected, whereas the request body applies to actions such as POST, PUT, and PATCH.

When a REST request is made, the server responds with HTTP headers defining the response, a response code indicating if the request was successful, and, in certain cases, a response body containing extra data. The response codes are categorized as follows: 200-level codes represent success, 400-level codes indicate client-side issues, and 500-level codes signify server-side faults.

To effectively test APIs, testers must first understand the types of REST queries supported by the API and any limitations on their use. Developers can use tools like Swagger to document their APIs. Testers should ask clarifying questions about available endpoints, HTTP methods, authorization requirements, needed data, validation limits, and expected response codes.

API testing often begins with creating requests via a user-friendly tool like Postman, which allows for easy viewing of results. The initial tests should focus on “happy paths,” or typical user interactions. These tests should include assertions to ensure that the response code is proper and that the delivered data is accurate. Negative tests should then be run to confirm that the application handles problems correctly, such as erroneous HTTP verbs, missing headers, or illegal requests.

Finally, the blog underlines the necessity of API testing and encourages engineers to transition from UI testing to API testing. This shift enables faster and more reliable testing, which aids in the detection of data manipulation issues and improves security.

Blog: https://simpleprogrammer.com/api-testing/

From the blog CS@Worcester – Matchaman10 by tam nguyen and used with permission of the author. All other rights reserved by the author.

Path Testing in Software Engineering

Path Testing is a structural testing method used in software engineering to design test cases by analyzing the control flow graph of a program. This method helps ensure thorough testing by focusing on linearly independent paths of execution within the program. Let’s dive into the key aspects of path testing and how it can benefit your software development process.

The Path Testing Process

  1. Control Flow Graph: Begin by drawing the control flow graph of the program. This graph represents the program’s code as nodes (each representing a specific instruction or operation) and edges (depicting the flow of control from one instruction to the next). It’s the foundational step for path testing.
  2. Cyclomatic Complexity: Calculate the cyclomatic complexity of the program using McCabe’s formula: E−N+2PE – N + 2P, where EE is the number of edges, NN is the number of nodes, and PP is the number of connected components. This complexity measure indicates the number of independent paths in the program.
  3. Identify All Possible Paths: Create a set of all possible paths within the control flow graph. The cardinality of this set should equal the cyclomatic complexity, ensuring that all unique execution paths are accounted for.
  4. Develop Test Cases: For each path identified, develop a corresponding test case that covers that particular path. This ensures comprehensive testing by covering all possible execution scenarios.

Path Testing Techniques

  • Control Flow Graph: The initial step is to create a control flow graph, where nodes represent instructions and edges represent the control flow between instructions. This visual representation helps in identifying the structure and flow of the program.
  • Decision to Decision Path: Break down the control flow graph into smaller paths between decision points. By isolating these paths, it’s easier to analyze and test the decision-making logic within the program.
  • Independent Paths: Identify paths that are independent of each other, meaning they cannot be replicated or derived from other paths in the graph. This ensures that each path tested is unique, providing more thorough coverage.

Advantages of Path Testing

Path Testing offers several benefits that make it an essential technique in software engineering:

  • Reduces Redundant Tests: By focusing on unique execution paths, path testing minimizes redundant test cases, leading to more efficient testing.
  • Improves Test Case Design: Emphasizing the program’s logic and control flow helps in designing more effective and relevant test cases.
  • Enhances Software Quality: Comprehensive branch coverage ensures that different parts of the code are tested thoroughly, leading to higher software quality and reliability.

Challenges of Path Testing

While path testing is advantageous, it does come with its own set of challenges:

  • Requires Understanding of Code Structure: To effectively perform path testing, a solid understanding of the program’s code and structure is essential.
  • Increases with Code Complexity: As the complexity of the code increases, the number of possible paths also increases, making it challenging to manage and test all paths.
  • May Miss Some Conditions: There is a possibility that certain conditions or scenarios might not be covered if there are errors or omissions in identifying the paths.

Conclusion

Path Testing is a valuable technique in software engineering that ensures thorough coverage of a program’s execution paths. By focusing on unique and independent paths, this method helps reduce redundant tests and improve overall software quality. However, it requires a deep understanding of the code and may become complex with larger programs. Embracing path testing can lead to more robust and reliable software, ultimately benefiting both developers and end-users.

All of this comes from:

Path Testing in Software Engineering – GeeksforGeeks

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

Equivalence Class Testing

Week 7 – 3/7/2025

This week, in my last class we had an activity for Equivalence Class Testing(ECT) under the POGIL activity. For the source of this week, I watched a YouTube video titled “Equivalence Class Testing Explained,” which gives us the essentials about this black-box testing method.

The host of the video defines ECT as a technique for partitioning input data into equivalence classes partitions where inputs are expected to yield similar results. To reduce redundant cases without sacrificing coverage, it is also possible to test one value per class. To demonstrate this reality, the presenter tested a function that takes in integers between 1 and 100. Classes in this example are invalid lower (≤0), invalid upper (≥101), and valid classes (1–100). Boundary value testing, in which values like 0, 1, 100, and 101 are applied to test for common problems in partition boundaries, was also accorded importance in the video.

I chose this video because ECT of the course we took included this topic and I wanted more information about the topic. Reading the course textbook it was difficult to follow. The class activity did make me do this topic, though this clarified it better to me. The video’s visual illustrations and step-by-step discussion clarified the practical application of ECT. The speaker’s observation about maintaining a balance between being thorough and being effective resonated with me, especially after spending hours of writing duplicate test cases for a recent project.

I thought that thorough testing had to test all possible inputs before watching. The video rebutted this by demonstrating how ECT reduces effort without losing effectiveness. I understood that my previous method of testing each edge case individually was not possible. Another fascinating thing was the difference between valid and invalid classes. I had neglected how the system handled wrong data in a previous project, dealing primarily with “correct” inputs. I realize how crucial both testing are for ensuring robustness after watching the demonstration of the video. Henceforth, in the future, I will adopt this approach to my future projects if needed.

My perception regarding testing has changed because of this movie, from a boring activity to a sensible activity. It serves the need of our course directly, i.e., providing efficient, scalable engineering practices. I can create fewer, yet stronger tests with the help of ECT, and that will surely help me as a software programmer. Equivalency class testing is a kit of wiser problem-solving, and I want to keep on practicing it. It’s not theory.

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

Sprint 1 – Reflection

During Sprint 1, I went through many ups and downs regarding time management. At first, I was not able to manage my time correctly in order to be more productive, which held me back slightly, and this happened over the course of a couple of weeks. Although, soon enough, I realized that in order to get some work done, I would have to organize my time better. This is when I began to write or research solutions that either I or some teammate needed. Sometimes, even during free time while waiting for something else, I would try to brainstorm for solutions.

Enthusiasm and anxiety were not the biggest help to me during Sprint 1. I got so excited that even before we had any meetings or anything figured out, I was already working on code. As much as the changes got implemented, this is not the best practice. This proved to be correct another time during the Sprint, where I did not realize that I implemented something without verification. As I mentioned in one of my commits, I implemented a way to store the inventory weight in a single database document instance. In order to remove or add any weight to it, that single instance would be modified. I was so excited and had so much work to put in, along with things that I thought could work, that I even forgot one of the most basic practices of programming. I forgot to make sure to add a way to prevent the inventory weight from becoming negative. Enthusiasm is good — it was not the problem. It is actually something that worked well for me. However, the problem was combining it with anxiety. It led to a mess of willingness to get something working against being proactive regarding limits.

Personally, I should try to improve my willingness to get something done while leaving aside the pressure of showing some work. Sometimes the pressure of having something done by the end of the week comes to mind, causing some faulty code to be written.

As a team, we went through many stages during the Sprint. There were stages where communication was missing from some parts. There were stages where not everyone would speak up their opinion. Thankfully, we are past those and seem to be moving on to a stage where there could be slightly more joking around than we should. I am taking myself out of this equation, although I believe that we are all guilty of this, even if not in the same amount. I believe that this should be the next thing our team should work on — to take meetings a little bit more seriously.

The pattern I chose is called The Deep End. It talks about challenging yourself with the work. Sometimes we may procrastinate the decision to go deep, to dive deep into problems. The only problem is that such behavior will only hold us back and lead to no result. You should not wait until you are ready and fully prepared. Always take your shot, go ahead, do it, and do your best.

This pattern relates to my experience since I decided to take this project as the biggest learning opportunity I have had so far. I decided to dive deep, not to look to the sides and overthink about drowning myself with all that there is to learn. This pattern is the literal reflection of how I decided to tackle this class. If I had read this pattern before, I would have come into Sprint 1 with a different mindset. I would understand that it is not just a learning opportunity, but also a chance for me to learn, break, and build without career-threatening risks.

Contributions done to the Project during Sprint 1

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/54

  • Fixed lint indentation problem on openapi.yaml Added a line so lint ignores the API Version long pattern Changed all 401 responses to 400

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/53

  • Changed inventory document instance creation to a single one. Allowing increment and decrement actions to be performed.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/55

  • Removed 2 difference endpoints for increment and decrement, made a single one for both actions.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/56

  • Changed where the verification if a document to store the weight exists in the database.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/checkinventoryfrontend/-/merge_requests/27

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/checkoutguestfrontend/-/merge_requests/35

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/addinventoryfrontend/-/merge_requests/36

  • Updated devcontainer file with new image.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.