Category Archives: CS@Worcester Blog

The Wisdom of the White Belt

The “White Belt” pattern resonates with me on a personal level, as it summarizes the mark of maintaining a beginner’s mindset, a quality that I believe is crucial for continuous growth and learning in any field, especially in the realm of software development.
One interesting aspect of this pattern is the acknowledgment that expertise and mastery can sometimes become a double-edged sword. While we try to have proficiency in our field, there is a risk of becoming proud or developing a fixed mindset, where we rely too heavily on our existing knowledge and fail to embrace new perspectives or paradigms.
The analogy of “wearing the white belt” serves as a sad reminder that true mastery is not in holding to what we already know but in building a mindset of humility and openness to learning. It challenges us to overlook our assumptions and approach new challenges with a fresh and curious mindset, to a beginner’s eagerness to explore and discover.
What particularly resonates with me is the idea of “unlearning what we have learned,” as emphasized in the quote from “The Empire Strikes Back.” (Favorite movie haha) This concept challenges the work that our knowledge is lively and pushes us to question our assumptions and be willing to adapt and evolve our thinking as we meet new contexts or technologies.
Furthermore, the pattern’s point on approaching new domains with respect and curiosity, rather than assuming expertise, is rather more of a debate. The reason I say so is because it reminds us that true understanding often comes from collaborating with others and acknowledging the unique perspectives and realities they bring to the table.
One interesting aspect I find compelling is the idea of questioning how veterans in the field approached coding in the past versus how we approach it now. While we may be tempted to dismiss older methodologies or technologies as outdated, there is value in understanding the historical context and the challenges that shaped those approaches. By adopting a beginner’s mindset, we can explore these historical perspectives with an open mind, potentially uncovering insights or principles that remain relevant today.
In spirit, the “White Belt” pattern encourages us to have a mindset of continuous learning, humility, and adaptability – qualities that are essential for being advanced in the landscape of software development. It reminds us that true mastery is not a destination but a lifelong journey of growth and exploration, where we must be willing to use our preconceptions and embrace the wisdom of a beginner’s mind.

andicuni
May 5, 2024

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

Sprint 3: A Candid Look at Our Sprint Journey

Sprint Retrospective
Reflection on what worked well:
Hey Everyone! During this sprint, our team demonstrated effective communication and productive collaboration. We were able to complete our assigned issues on time, and each team member contributed by conducting individual research. The meeting with the professor provided valuable insights and guidance, particularly regarding the challenges we faced with Docker Compose and the startup process involving RabbitMQ.
One aspect that worked well in our favor was our ability to divide tasks and responsibilities based on individual strengths and interests. This allowed us to support each team member’s expertise and ensure that the workload was distributed evenly. Additionally, our regular check-ins and progress updates made the ideal coordination and helped identify potential obstacles early on.
Reflection on what didn’t work well:
Despite our best efforts, we encountered some difficulties with Docker Compose and the startup process involving RabbitMQ. Configuring the containers to communicate effectively and ensuring proper dependency management proved to be a great challenge. However, these obstacles presented valuable learning opportunities for our team, and we gained a better understanding of the areas that require further improvement.
Another area that could have been improved was our initial planning and estimation process. While we successfully completed our assigned tasks, there were instances where we underestimated the difficulty of certain issues, leading to potential time crunch or scope.
Reflection on what changes could be made to improve as a team:
To enhance our team’s performance, we could explore more effective ways to share and combine our research findings. By creating a collective repository or doing regular knowledge-sharing sessions, we can ensure that everyone is up-to-date with the latest ideas and techniques. This would not only help grow a collaborative learning environment but also prevent duplication of efforts and assist a mutual learning affair within the team.
Reflection on what changes could be made to improve as an individual:
As an individual, I could focus on improving my expertise in JavaScript linter tools and debugging utilities. By focusing time to hands-on practice and exploring more advanced features of the tools we’ve identified, I can better contribute to the project’s code quality and debugging efforts. This would not only enhance my technical skills but also position me as a valuable resource for the team, capable of providing guidance and support when needed.
Furthermore, I could enhance my documentation skills to ensure that my research findings and insights are effectively communicated to the rest of the team, clear the way for helpful information and collaboration. Clear and brief documentation can serve as a valuable reference for future sprints and aid in onboarding new team members.
We have provided a broad overview of our research on JavaScript linters tools and debugging utilities, which will be a valuable resource for future teams who tackle this. The dedication to exploring various options and understanding the strengths and weaknesses is what we want to leave our mark on.
Overall, I would say for Sprint 3 as a cleanup and research Sprint, it allowed our team to identify areas for improvement and gain a valuable experience into the challenges we faced. By implementing the suggested changes and continuing to collaborate effectively, we can enhance our productivity and deliver high-quality results in future sprints. Open communication, continuous learning, and the strive to move forward will be key to our success as a team.

andicuni
May 5, 2024
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/experiments/guest-info-backend-java-script-linter-testing-debugging-fork/-/issues/1 One of the issues I worked on was the JS Linters research.

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

Rubbing Elbows: Shortcutting the Path to Software Mastery

The “Rubbing Elbows” pattern advocates for software developers to actively seek out opportunities to work hands-on, side-by-side with other skilled programmers. The core premise is that certain techniques and micro-habits can only be absorbed through close collaboration on shared coding tasks. Practices like pair programming try this kind of knowledge transfer, but the pattern applies to any endeavor that allows you to observe the workflow and decision-making of an experienced developer.
I found this pattern incredibly insightful and motivating. As a software engineering student, I’ve already experienced how much more I can learn by watching lecturers code and explain their thought process in real-time, versus just reading examples. The “Rubbing Elbows” pattern highlights how that same example of accelerated learning through consistency well beyond the classroom.
The authors make an good point that there are “thousand little everyday moves” that skilled developers have pressed through years of experience. These small refinements may seem minor on their own, but include into real improvements in productivity, code quality, and problem-solving prowess. However, these micro-habits are nearly impossible to fully carry through written documentation or formal teaching. Rubbing elbows allows an apprentice to organically absorb them through repeated, intimate observation.
I’m reminded of when I pair-programmed on a school project with a talented classmate. While daunting at first to have my code exposed, I soon realized I was gaining insight into his mental models, techniques for juggling complexity, and little shortcuts that markedly lifted his coding flow. Rubbing physical and mental elbows enabled knowledge transfer that couldn’t have occurred through solo learning.
This pattern has inspired me to be a go getter about joining open source projects, participating in local meetups, and seeking out internships that enable close collaboration with experienced mentors. Identifying and creating these “rubbing elbows” opportunities will be important for go beyond my current peak and speeding my progression as a capable, well-rounded software crafter.
While the unusual feeling of being the “newbie” amongst experts is unavoidable, I’m excited by the authors’ advice: embrace feeling lost at times, ask questions, rotate pair partners if stuck, and record learnings to cement them. Absorbing the tacit knowledge of those further along the path is key to rapidly elevating my own skills.

andicuni
April 28, 2024

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

Software Testing Synergy: Leveraging IT Expertise for Optimization

Hey Everyone! As a student in a software testing course, the article “How Integrating IT Support Enhances Software Testing Outcomes” provided insightful perspectives that directly relate to our classroom lessons on implementing robust and comprehensive testing strategies. Having a good software testing process is important for defining quality and catching defects early before product release.
The article summarizes the key advantages of integrating IT support resources into the software testing lifecycle. It highlights how IT support teams have deep technical knowledge using testing frameworks, systems, networks, and more. By collaborating with developers and testers, they can apply this expertise to help assist processes like building robust testing environments, troubleshooting issues, identifying potential risks and creating test cases that accurately relay real-world scenarios.
I selected this particular resource because it reinforced topics we’ve covered in class about the importance of having well-designed testing processes and environments in place. The article’s examples resonated with me after completing last summer’s IT internship, where I saw firsthand how vital the support staff’s skills were for efficient testing and issue resolution when glitches started. Their ability to quickly diagnose and mediate problems minimized delays and facilitated a smooth development pipeline.
One of the most insightful sections outlined the advantages of integrating IT support beyond just bug detection. As we’ve discussed in our course lectures and materials, catching and fixing bugs is only one side of a comprehensive testing strategy aimed at delivering a high-quality product. The article demonstrated how collaborative IT-tester efforts enable a proactive, physical and mental approach for continuously validating software across the entire system and architecture. With their system-level expertise, IT staff can provide invaluable insights on creating more robust test cases that account for the complexities of production environments and real-world usage scenarios we may not anticipate.
What truly resonated was the need to tailor software testing processes and IT support services based on regional factors like the local talent pool, regulatory environment, and domain-specific challenges. This localized approach was obvious during my internship with Isto Biologics, as their IT support services catered their recommendations based on the market’s unique needs.
As I prepare for my future career, I now better appreciate the varied collaboration required for achieving comprehensive software testing and quality assurance. I expect to apply these learnings by prioritizing open communication between all stakeholders and advocating for strategic IT support integration from the onset of projects. Leveraging this relationship will be key to implementing robust testing processes that continuously validate quality while optimizing resources.

andicuni
April 28, 2024
https://www.softwaretestingmagazine.com/knowledge/how-integrating-it-support-enhances-software-testing-outcomes/

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

Nurturing Software Craftsmanship

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

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

Sharing Strategies for Effective Exploration!

As a student studying computer science and software testing, I found the blog post “Mushroom Picking and Testing” to be a fascinating and insightful exploration of the parallels between the art of mushroom foraging and the practice of software testing. The author, a seasoned mushroom picker from Estonia, skillfully draws connections between the two various activities, highlighting the similarities in the decision-making processes, risk assessment, and the development of observational skills.
The blog post begins by describing the author’s love for mushroom picking, a tradition rooted in their Estonian heritage. Interestingly, the author finds this activity to be a meditative and reflective experience, where one part of the mind focuses on the task at hand while the other have multiple thoughts and ideas. It is within this state that the author discovers the similarities between mushroom picking and software testing.
One of the key parallels drawn is the concept of “choice of location vs. product coverage.” Just as the author visits familiar forests to efficiently collect a good amount of mushrooms, software testers may focus on keep on testing the same areas of a product, limiting their vision and potentially missing new or exciting discoveries. The blog post encourages readers to pinpoint a balance between depth and breadth, considering the mission and objectives when deciding how to grant their time and resources.
Another comparison I found is the importance of making preparations before starting on either attempt. The author discusses the need to gather the necessary tools and equipment, as well as staying informed about environmental factors and recent changes that could impact the success of the task. Similarly, in software testing, it is crucial to have the right tools and knowledge about the product and its recent updates to make informed decisions and effectively approach the testing process.
I would say the most eye opening aspect of the blog post is the discussion around “knowing your oracles.” The author explains the importance of recognizing poisonous mushrooms, a skill passed down through generations. This concept directly translates to software testing, where testers must develop a deep understanding of the product’s characteristics and potential issues, rather than relying on a more questioning or searching.
As a software testing student, I found this blog post to be a refreshing and wise point of view on the craft of testing. The author’s ability to draw parallels between these two seemingly unrelated activities has provided me with a new lens through which to approach my studies and future practice. The emphasis on searching for more, risk-taking, and the development of observational skills are all elements that I will strive to plug into my testing methodology. This blog post has not only expanded my understanding of software testing but has also inspired me to continue the unexpected connections between the physical world and the digital realm.

April 14, 2024
andicuni

https://thepainandgainofedwardbear.wordpress.com/2017/09

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

Sprint 2 Retrospective

In our second sprint, the team made important progress on a variety of tasks related to the reporting backend, integration, and documentation. The specific work items we addressed included updating npm packages, improving documentation in the reporting backend, setting up Gitpod permissions, implementing hot-reload functionality with Nodemon, composing Docker files, verifying the testing suite, configuring linters and the pipeline, and fixing a build script. Overall, I feel our team had better communication and a more fair approach to splitting the work this sprint.

Reflection on What Worked Well
One of the key strengths of this sprint was the increased level of communication within the team. We made a better effort to stay in sync, share updates regularly, and support each other when needed. This led to a more collaborative and efficient workflow, as we were able to identify blockers early and provide assistance to unblock each other’s progress. I’d say that a fair distribution of work was also a positive aspect, as we made a combined effort to split the tasks more evenly and ensure that everyone had a manageable workload. This allowed us to make steady progress throughout the sprint, rather than having a last-minute crunch.

Reflection on What Didn’t Work Well
While we did see improvements in our progress flow compared to the previous sprint, there were still periods where a significant amount of work was left until the final week. It gave a bit of pressure and gave an increase in the risk of missing deadlines or compromising on quality. Additionally, the team decided not to go forward the Kubernetes with Docker Compose YAML approach, as we don’t currently have Kubernetes set up. Instead, we focused on consolidating all the API Docker files into a single root deployment. The linter and extension setup was also split across multiple issues, which could have been better organized.

Reflection on Changes to Improve as a Team
Moving forward, we should aim to distribute the work more evenly across the entire sprint duration to maintain a more consistent flow of progress. This may involve better planning and task estimation at the start of the sprint, as well as more frequent check-ins and adjustments throughout. Additionally, we should continue to keep our commit messages as clear as possible, especially for merge commits, to ensure the project history remains easy to follow.

Reflection on Changes to Improve as an Individual
As an individual, I could have been more proactive in checking in with my teammates and offering assistance, even if it’s not directly related to my assigned tasks. I want to make sure I’m staying aware of the overall progress and roadblocks faced by the team, and I can provide support where needed. Additionally, I will learn and do what it takes to be better to complete my individual tasks as early as possible to avoid last-minute stress and make sure we meet our sprint goals.

Work and Work Products
One of the key work products I contributed to this sprint was the update to the npm packages in the reporting backend, as well as the improvements to the documentation for recent changes. I also collaborated with Issac on writing documentation for the reporting backend and composing the Docker files. While I was involved in the initial stages of configuring the linters and pipeline in the reporting integration, Victor and Hieu took the lead on those tasks as they were more closely related to their other assigned issues.

To speak upon the work and work products we are producing, we faced an issue with the guest info frontend not working due to a local host problem, and we worked to set up a solution where the application can check if it’s running in Gitpod and query the URL accordingly. We also identified the need to have a more stronger approach to setting up environment variables, rather than hardcoding them.

Overall, this sprint saw improvements in team communication and task distribution, but there is still room for us to refine our process and ensure a more consistent flow of progress. As we move forward, I am committed to playing an active role in supporting my teammates, completing my work efficiently, and contributing to the improvement of our team goals.

April 9, 2024

andicuni

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/70#note_1840354434

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

Sprint Retrospective Blog #1

Hello everyone, I’m Abdullah Farouk, for those who may not be familiar with me yet, and I’m here to document my second sprint retrospective blog for this semester. Let me begin by saying how impressed I am with our collective efforts in adapting to these issues; we’ve managed to go  through various changes very nicely. While there’s certainly room for improvement across the board, I want to say we have successfully navigated through this long sprint. This sprint went deeper into our project which is the libre food pantry. The first thing we did in the beginning of the sprint was weighing the different issues and breaking some epics into smaller issues and assigning it to our team, just like we did in the last sprint.  Then, we prioritized these tasks and started working on them. Personally, I found class time to be particularly productive, allowing me to get most of the issues done, with the support of my teammates. Obviously, there were moments when there were challenges, but having my teammates by my side proved to be helpful. Additionally, I want to say I prefer in-person meetings over virtual ones; the presence of one another helps me be  more productive, as opposed to interacting only through computer screens. I would definitely say that this sprint went better than sprint-1, everyone was more involved because we knew what we had to do in order to finish the semester. Our work was more evenly spread and we did not have any major hiccups or challenges that we couldn’t figure out as a group.

I feel like we fixed our issue of not knowing how to weigh the issues properly, compared to the first sprint. I downloaded discord on my phone so I was responding more to my classmates outside of class time, which is a BIG improvement from last semester. One thing we still need to put some more work and effort into is adding a description to some of the issues that we created. It was still a little difficult for me to figure out what they wanted me to do just from the title, so I had to ask a classmate to double check. I hate asking people for help on things that should be more clear, so that’s one thing we need to be better at in the next sprint.

Other than those minor issues, I think me, and the team did a great job going through these issues and completing them on a timely basis. To improve as an individual, work on these issues gradually. I took spring break for granted, when I should have finished at least the issue that I was working on so I don’t hold my team back. To improve as a team, I think we should start adding a description of the issue under the title just so we don’t get confused and be more organized I would say.

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

  • Verifying that ReportingAPI has correct extensions and linters

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/68

  • Verifying that ReportingBackend has correct extensions, linters, and pipeline stages

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

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/122

  • Research functionality of “nodemon” and how to properly integrate it

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

The Apprentice’s Superpower!

Hey Everyone ! As a computer science student embarking on my journey towards becoming a software development professional, the pattern “Unleash Your Enthusiasm” from the Apprenticeship Patterns book has matched deeply with me. This pattern emphasizes the importance of embracing and expressing the excitement and curiosity that often characterize the early stages of one’s career.
The pattern highlights the interesting attributes that apprentices bring to their teams, such as a fresh perspective, diverse ideas, and an exciting drive for learning. It acknowledges that while this level of enthusiasm may be seen as rare or even risky by more experienced team members.
What I found particularly thought-provoking about this pattern is the way it challenges the common tendency to conform to the norms of a team or organization. The pattern encourages apprentices to resist the urge to suppress their enthusiasm and instead to embrace it as a valuable contribution to the collective intelligence of the group.
Moreover, the pattern’s weight on the diversity of thought that enthusiastic apprentices can bring to a team resonates with my understanding of the importance of diverse perspectives in problem-solving and innovation. As I progress in my studies and eventually enter the workforce, I am eager to leverage my background and mindset to offer new upcoming solutions and challenge the current state.
In my own context, as a computer science student, I can see the value of this pattern in the classroom, where I can actively engage with my peers and professors, offering new ideas and questioning established practices. I am also excited to bring this mindset to any internships or entry-level positions I may pursue, with the goal of not only accelerating my own learning but also contributing to the growth and success of the teams I work with.
Overall, the “Unleash Your Enthusiasm” pattern has inspired me to embrace my natural curiosity and excitement for the field of software development, while also modifying that enthusiasm with an understanding of the importance of navigating team dynamics and building strong relationships with my colleagues. As I continue on my apprenticeship journey, I am committed to maintaining this balance, using my enthusiasm as a catalyst for learning and growth, and ultimately, becoming a valued contributor to the software development community.

April 7, 2024

andicuni

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

A Software QA Student’s Guide to Impactful Code Documentation

Hey everyone! I found the article “Elevating Your Test Automation Projects With Meaningful Code Documentation” to be a valuable resource that directly relates to the course material. The article begins by highlighting the common challenges faced when trying to understand existing automated test code, such as unclear naming conventions and a lack of explanatory comments or documentation. Dickson emphasizes the importance of documenting code to ensure that both new and experienced team members can easily comprehend the purpose and functionality of the automated tests.
One of the key points discussed in the article is the effective use of comments. Dickson outlines two simple rules for writing meaningful comments: avoiding redundancy and being informative and concise. She provides an example of a Cypress test where the description of the test case made the additional comments unnecessary, as the test was already self-explanatory. On the other hand, Dickson suggests adding comments to explain the purpose and implementation of more complex code.
Another valuable documentation technique covered in the article is the use of docstrings. Dickson explains how docstrings, which are associated with specific code blocks, can greatly improve the reusability of the code. She demonstrates the power of docstrings by showing how they can provide information about function parameters, return values, and usage examples, making it easier for collaborators to understand and effectively utilize the code.
Dickson outlines several popular naming conventions and explains the benefits of using descriptive and consistent names for variables, functions, classes, and files. She highlights how these naming conventions can enhance the readability and organization of the codebase, ultimately making it more maintainable and collaborative.
As a software quality assurance student, I found this article to be particularly relevant and helpful. The author’s clear explanations and examples have assisted my understanding of the role that code documentation plays in the success of test automation projects. I can already can imagine applying these practices in my own future work, where I will continue to create well-documented and easily understandable test automation code.
Furthermore, the article’s emphasis on collaboration and code reusability stays with me, as I recognize the importance of working effectively with cross-functional teams in the software development process. By prioritizing meaningful code documentation, I can make sure that my fellow team members can understand and build upon the automated tests I create.
In conclusion, “Elevating Your Test Automation Projects With Meaningful Code Documentation” is a vital resource that has pushed my thinking for the role of code documentation in software quality assurance. The author’s practical advice has provided me with the knowledge and tools to enhance the readability, maintainability, and collaboration within my own test automation projects. I am confident that applying these principles will lead to more efficient and effective test automation, ultimately contributing to the overall quality and success of the software I help develop.

April 7, 2024
andicuni
https://www.ministryoftesting.com/articles/elevating-your-test-automation-projects-with-meaningful-code-documentation

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