Category Archives: cs-wsu

Blog Post 1

September 8th, 2025

Hello! This is a blog? Probably. As a current student, I will (hopefully) be blogging about my experiences in Computer Science. Otherwise, I don’t really know what to do with this. Anyhow:

I currently have some experience with code. I took AP Computer Science in high school, and a Game Design Class (technically twice by two different teachers due to a mix-up in my high school schedule, but frankly, they did different things so I don’t actually regret it.)
This gives me experience with both Python and Java, although at a beginner level. Additionally, my First Year Seminar class refreshed me on Python, and I took the beginner Unix Systems Programming, which taught me a little bit of C.

I did use Scratch to make a game back in high school but I was atrocious at it. I remember having a habit of over complicating my stuff too. Especially in my Game Design Class. I took AP Computer Science the same year as it and because all the other students were seniors, my teacher let me work on my Game Design stuff after the seniors graduated. I took twice as long as everyone else and barely finished my “game.” (Officially, I never finished it and passed in a partially modified older project.) I am near certain the teacher just let it slide because I was working despite having no official assignments in AP Computer Science and helping people in my game design class. (I have like, 2 unfinished projects? Both were intended to be my final program for my Game Design Class, but neither were passed in.)

The reason I decided to pursue Computer Science was pretty simple: I thought video games were cool. Then I just went for it, and it was okay. I had some classes in high school but nothing complicated. But as time went on, I eventually went into my AP Computer Science class which I did okay in. One day, the teacher said I “have a passion” for Computer Science. Frankly, I thought that was a weird statement since I didn’t really do that much coding nor was I particularly good at it, but it made me feel good about myself so here I am. (Nowadays I hear of my cousins swapping Majors from Computer Science to basically anything else so I’m either doing okay or making a grave mistake. Oh well.)

Anyhow, that’s my current experience with Computer Science and I guess I’ll give you all an update later on.

Thanks for Reading,
Ryan Nguyen

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

Nurse to Developer

One woman’s journey from animal medicine to tech

About

After 12 years in the veterinary medicine field as a nurse, I am actively focused on a career shift into computer science, specifically in software engineering.

This blog is where I will document my technological discoveries, achievements, setbacks, and anything else that contributes to conquering my career goals.

From the blog cs-wsu – Anna The Dev by Adrianna Frazier and used with permission of the author. All other rights reserved by the author.

Sprint 3

During sprint 3, I kept working on the frontend, like the last sprint, I had been stuck trying to get the backend up, while trying to work on the frontend. I had a teammate work with me for this sprint to complete it. We worked on two different branches, mine and Jason’s.  Inside my branch, I was having a problem starting up the frontend through development mode, so I decided to see the original branch and work back into the updates I had made. Jason was able to start the frontend without the backend using dev. This gave me the advantage of designing the frontend and seeing what would work. Working with someone this sprint improved the sprint overall for me because last sprint, everyone else was in the backend while I was working in the frontend. My teammates were helpful, but without working with someone directly in the frontend, it was difficult to get help on exactly what I needed.  

First starting on the design, I had noticed that I had to make the banners and everything the perfect size, or it wouldn’t be eye-appealing. Small things like having the top and bottom borders being same size were important. One of my biggest problems was attempting to make sure the page could fit on one page without having to scroll, because, first, designing the front end, there would be empty white space that wasn’t needed, or having the logos be too small. But I was able to persevere and have a design that I was proud of. I also have to give credit to Byron, who posted his design, which I translated into my design. It helped in choosing what logos should be prioritized and gives the frontend a coherent design.

  For this sprint, I would choose Kindred Spirits as the pattern that most resonated with me. This pattern highlights the importance of working together and working with someone who is like-minded and is determined to learn and accomplish their goals. This is great to have in a team because it allows teammate to grow together while also accomplishing their tasks. Working with a teammate this sprint greatly affected the amount of work I was able to accomplish. I was able to complete more in a shorter amount of time given. Directly working with Jason during this sprint gave me more insight into the issues we faced and helped me grow faster and feel more supported. Before this sprint, as I mentioned, I was isolated, working on the frontend by myself. It was difficult to troubleshoot my work with others because they were working on different aspects of the project, mostly in the backend. My teammates were helpful in what they could help me with, but there was always a disconnect because I didn’t want to slow them down on their work, and they were working on the backend. Working in collaboration with Jason allowed me to exchange ideas and confirm each other’s work. It gave me more confidence to ask questions because we were working in unison on the same problem. If I had been aware of this pattern earlier, I would have gotten a partner sooner because working in isolation isn’t a deterrent to just you but to the whole team.

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Week 13: Re-evaluating the ‘Double D’s’ of Software Development: Test Driven Development

Jeremy D. Miller’s blog post, “Re-evaluating the ‘Double D’s’ of Software Development: Test Driven Development,” offers a thoughtful exploration of Test Driven Development (TDD) and its role in modern software engineering. Drawing from his experiences at Calavista and in open-source projects, Miller revisits TDD’s principles, benefits, and challenges, providing valuable insights for developers and teams considering or currently practicing TDD. Feel free to check out his blog at https://jeremydmiller.com/2021/01/21/re-evaluating-the-double-ds-of-software-development-test-driven-development/

Understanding Test Driven Development (TDD)

TDD is a development methodology where developers write automated tests before writing the actual code. These tests define the desired functionality, guiding the subsequent code implementation to ensure it meets the specified requirements. Originating from the Extreme Programming (XP) movement in the late 1990s and early 2000s, TDD emphasizes rapid feedback and iterative development.

Miller highlights that, despite its name, TDD is more accurately a software design technique than a testing strategy. By writing tests first, developers are compelled to consider the code’s design and desired outcomes upfront, leading to more intentional and maintainable code structures.

The Value of TDD: Feedback, Design, and Refactoring

One of TDD’s core strengths is its provision of immediate feedback. As developers alternate between writing tests and code, they receive constant validation of their work, facilitating quicker identification and resolution of issues. This rapid feedback loop not only accelerates development but also enhances code reliability.​

Moreover, TDD encourages modularity. Since writing tests for tightly coupled code is challenging, developers are motivated to design more modular and decoupled components, improving overall code maintainability. Miller points out that TDD acts as a “forcing function,” prompting developers to think critically about code structure and dependencies from the outset

Implementing TDD in Practice

At Calavista, TDD is a standard practice in client engagements and internal projects. Miller advocates for its adoption, citing its benefits in producing high-quality, maintainable code. He encourages teams to view TDD not as a rigid doctrine but as a flexible approach that can be tailored to fit various project needs and contexts.

For developers new to TDD, Miller suggests starting with small, manageable components and gradually incorporating testing into the development workflow. Over time, this practice can lead to a more disciplined and thoughtful coding approach

Conclusion

Jeremy D. Miller’s reevaluation of TDD offers a nuanced perspective on its role in software development. By framing TDD as a design methodology that promotes feedback, modularity, and continuous improvement, he provides a compelling case for its adoption. While acknowledging its challenges, Miller’s insights underscore the potential of TDD to enhance code quality and developer productivity when applied judiciously.

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.

Week 12: ​Understanding the Importance of Software Testing: A Comprehensive Guide

In the dynamic world of software development, ensuring the reliability and functionality of applications is paramount. Software testing emerges as a critical process that verifies whether a software product meets its intended requirements and functions seamlessly under various conditions. It’s not merely about identifying bugs; it’s about validating that the software delivers a quality experience to its users.

Types of Software Testing

Software testing encompasses various methodologies, each targeting specific aspects of the application:​

  1. Functional Testing: Validates that each function of the software operates in conformance with the requirement specifications.​Full Scale
  2. Non-functional Testing: Assesses non-functional aspects like performance, usability, and reliability.​Full Scale+1Full Scale+1
  3. Regression Testing: Ensures that new code changes do not adversely affect the existing functionalities of the product.​
  4. Black Box Testing: Examines the functionality of an application without peering into its internal structures or workings.​
  5. White Box Testing: Involves testing internal structures or workings of an application, as opposed to its functionality.​
  6. Automated Testing: Utilizes specialized tools to execute tests automatically, increasing efficiency and coverage.​
  7. Manual Testing: Involves human testers executing test cases without the use of automation tools.​

Levels of Software Testing

Testing is conducted at various stages of the software development lifecycle:​

  1. Unit Testing: Focuses on individual components or pieces of code for a system.​
  2. Integration Testing: Examines the interactions between integrated units/modules.​
  3. System Testing: Tests the complete and integrated software to evaluate the system’s compliance with its specified requirements.​Full Scale+1Full
  4. Acceptance Testing: Determines whether the system satisfies the business requirements and is ready for deployment.​

The Role of Software Testers

Software testers play a pivotal role in the development process. They are responsible for designing test cases, executing tests, and identifying bugs before the software reaches the end-user. Their work ensures that the final product is reliable, efficient, and user-friendly.


Conclusion

Software testing is an indispensable part of the software development process. It ensures that the final product is of high quality, meets user expectations, and functions as intended. By understanding and implementing effective testing strategies, organizations can deliver robust and reliable software products.

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.

Sprint 2

During this sprint, I switched up the work I did compared to the last sprint instead of working on the backend I was given the task to oversee the front end. First going into the front end blindly I didn’t know exactly how far the front end was already and had to accommodate myself to the code. First opening the frontend I noticed it was missing several files that would hold great importance in starting the frontend. One of my first fixes was the docker-compose file left by the other group was the backend file the same so I created a new file that would hold both servers of the front end and the backend. I updated some of the documentation that had been outdated compared to what we were working on currently. I created a new way to start the frontend server because it was missing that and added an up.sh, down.sh, and rebuild.sh for the front end. I also updated the outdated docker file. After I had a basis for what was needed I decided to go in and organize it better to read the new files in an organized manner to see what files were missing. Had to add new assets and components including new pictures of Libre food pantry and any other ones that were needed. 

During this sprint, I worked well working alone but I should have checked more often with my teammates because of the issue that would later fall upon me. I was making progress every week but I hadn’t yet seen the biggest fault was the backend would crash on me. Next time I should check in with my teammates sooner instead of making progress on my own. I just didn’t want to slow down my teammates with my work. That is a fault in itself I shouldn’t be scared for help because the team will fail if I do this. 

This time around the apprenticeship pattern that resonated with me the most was breakable toys because it is the basis of each sprint. You must create a small project where you can make mistakes in order to learn and be better. During this spring I was learning the ins and outs of the front end on something someone else created that I had to update and fix. This pattern could have made me more confident in messing up because it’s now wrong to mess up. Failing would help with issues that would come up that would show me what to do in other scenarios. Another pattern I would choose is to learn how you fail. I had many times during this sprint where I was head scratching to find an answer or come to an understanding of something but picking up on the patterns of how I failed I could change for the next issue that would come up. This issue opens my mind to being more intentional with my work and picking up on my common mistakes even if sometimes simple mistakes are the biggest headaches. Errors can be preventable by understanding why you do something and adapting to catch them next time. During this sprint, I learned a great deal about my project and I hope in the next sprint I will be able to learn more.

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Week 11: 10 Reasons Why Writing Tests Will Make You a Better Developer

Writing tests might seem like extra work, but it’s one of the most impactful habits you can develop as a programmer. Beyond catching bugs, tests improve your design, boost your confidence, and save time in the long run. Drawing from the insights shared in the NDepend Blog, here are ten compelling reasons to embrace testing in your development workflow.​


1. Spot Ambiguities Early

Writing tests forces you to consider edge cases and potential pitfalls, such as null references or uninitialized data. By thinking from the user’s perspective, you can identify and address ambiguities in requirements early on, leading to more robust code.​

2. Write Better Code from the Start

Testing encourages you to question your assumptions and validate your logic. This practice helps you recognize that initial implementations may have flaws, leading to more thoughtful and accurate coding.​

3. Achieve Better Design

Tests naturally lead to decoupled and modular code. By abstracting complex infrastructures behind interfaces, you create code that’s easier to test and maintain, aligning with principles of good software design.​

4. Simplify Debugging

Instead of navigating through the entire application to reach a specific context, tests allow you to isolate and verify individual components. This targeted approach makes debugging more efficient and less time-consuming.​

5. Maintain Up-to-Date Documentation

Tests serve as living documentation, illustrating how different parts of your codebase are intended to function. They provide clear examples of usage and expected behavior, which is invaluable for future reference and onboarding new team members.​

6. Measure Progress Accurately

With a comprehensive test suite, you can track your development progress more precisely. Passing tests indicate completed functionality, while failing tests highlight areas that need attention, providing a clear roadmap for development.​

7. Catch Regressions Early

Automated tests run consistently, alerting you to unintended changes that may break existing functionality. This early detection helps maintain the integrity of your codebase as it evolves.​

8. Refactor with Confidence

A robust test suite gives you the assurance to refactor code without fear of introducing new bugs. Knowing that tests will catch any regressions allows you to improve code quality safely.​

9. Release with Confidence

Before deploying new features or updates, running your tests ensures that everything works as expected. This verification process reduces the risk of releasing faulty code, leading to more stable and reliable software.​

10. Save Time and Enjoy Development

While writing tests requires an initial investment of time, it pays off by reducing the time spent on debugging and maintenance. Moreover, the confidence and clarity that tests provide make the development process more enjoyable and less stressful.

Embracing testing is not just about preventing bugs; it’s about fostering a mindset that values quality, clarity, and continuous improvement. By integrating testing into your workflow, you set yourself up for success and growth as a developer

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.

Week 9: Software Testing vs. Quality Assurance: Understanding the Difference

In software development, Software Testing and Quality Assurance (QA) are two essential practices, but they serve different purposes. While both aim to ensure the delivery of high-quality software, understanding their differences is key to a successful development process.

What is Software Testing?

Software Testing involves evaluating a software application to find bugs, defects, or issues. The goal is to verify that the software functions as expected, meeting the specified requirements. Testing usually takes place after the software is developed, and it includes various types such as unit, integration, and system testing. The primary purpose of testing is to identify errors before releasing the product.

What is Quality Assurance?

Quality Assurance (QA) is a broader, more proactive approach. It focuses on improving the entire software development process to prevent defects before they happen. QA involves setting up best practices, frameworks, and guidelines to ensure that all stages of development—planning, coding, testing—follow high standards. QA runs throughout the software lifecycle, not just after development, and aims to ensure continuous quality improvement.

Key Differences Between Software Testing and Quality Assurance

  1. Scope:
    • Software Testing focuses on identifying defects in the finished product.
    • QA aims to prevent defects by improving the development process.
  2. Objective:
    • Software Testing’s goal is to find issues in the product.
    • QA’s goal is to enhance the development process and ensure quality from start to finish.
  3. Timing:
    • Software Testing typically happens after development.
    • QA is an ongoing process that begins early in development and continues throughout.
  4. Approach:
    • Software Testing is reactive, identifying issues after they arise.
    • QA is proactive, aiming to prevent issues before they occur.

Conclusion

While Software Testing focuses on finding defects in the product, Quality Assurance works on improving processes to avoid defects in the first place. Both are critical in ensuring that the final product is reliable and meets user expectations. By integrating both, development teams can produce high-quality software more effectively.

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.

Week 8: A Comprehensive Guide for Product Managers

Introduction

Unit testing is a critical aspect of software development that ensures code reliability, maintainability, and efficiency. While often considered a developer’s responsibility, product managers (PMs) can benefit from understanding unit testing fundamentals to improve collaboration, enhance product quality, and streamline the development process.

What is Unit Testing?

Unit testing involves testing individual components or functions of a software application in isolation. By verifying that each unit of code performs as expected, teams can detect and resolve issues early in the development lifecycle. Typically, unit tests are automated and executed frequently to maintain code integrity.

Why Product Managers Should Care About Unit Testing

Though unit testing is primarily a technical function, PMs should have a basic grasp of its significance. Here’s why:

  • Improved Code Quality: Unit testing helps catch bugs early, reducing the risk of defects in production.
  • Faster Development Cycles: Automated tests accelerate development by reducing the time spent on debugging and QA.
  • Better Collaboration: Understanding unit testing enables PMs to facilitate better conversations with engineers and align on quality expectations.
  • Reduced Technical Debt: Encouraging a test-driven approach helps maintain clean and maintainable code.

Key Concepts of Unit Testing

1. Test-Driven Development (TDD)

TDD is a methodology where developers write tests before writing the actual code. This practice ensures that each piece of code is created with testability in mind, leading to more robust software.

2. Mocking & Stubbing

Mocking involves creating simulated objects to mimic real dependencies in unit tests. This technique helps isolate the component under test, ensuring that external dependencies do not interfere with test results.

3. Code Coverage

Code coverage measures the percentage of code executed by unit tests. While high coverage is beneficial, quality matters more than quantity—focusing on critical components rather than achieving 100% coverage.

Best Practices for Unit Testing

  • Write Small, Focused Tests: Each test should validate a single functionality to improve clarity and maintainability.
  • Keep Tests Independent: Avoid dependencies between tests to ensure they run reliably in any order.
  • Automate Testing: Integrate unit tests into the CI/CD pipeline for continuous validation.
  • Maintain Readability: Write clear and well-documented tests to help teams understand their purpose.

How Product Managers Can Support Unit Testing

  • Advocate for Testing in Development Planning: Encourage teams to allocate time for writing and maintaining tests.
  • Align Testing Goals with Business Objectives: Ensure that critical features have adequate test coverage to minimize risks.
  • Foster a Quality-Driven Culture: Promote the importance of testing in team discussions and retrospectives.

Conclusion

Unit testing is a powerful practice that enhances software reliability and efficiency. While product managers may not write tests themselves, understanding their role in the development process fosters collaboration and contributes to delivering high-quality products. By embracing unit testing principles, PMs can help bridge the gap between technical teams and business goals, ultimately driving better outcomes for users and stakeholders alike.

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

My first sprint was a trial of figuring things out. Had to get accustomed to my team members and the program that was already created before. I was assigned to the reporting system and going in with my teammates and I didn’t know how far along the project had been. We had to first get settled and understand what updates needed to be done to complete our first sprint. Our sprint planning went well we understood the issues left before from a different class could be used for our sprint in this class. We all selected an issue that each one of us would resolve including some minor ones that came later on. I was chosen to Determine the startup procedure for MongoDB and RabbitMQ in the development environment

At first, I was confused with understanding what I had to do but after reading the comments made I began to understand what needed to be done. It was more of a test by creating another docker-compose file to run the Rabbimq without the backend. I created a devDocker-compose to achieve my goal. I then created another index.js file. I did this to run the developer versions or production of the up scripts. I did minor updates during the sprint including updating devcontainer so it would work better on Macs. There were several things we had to update so we split up the work and committed the corresponding ones to the main. I helped my teammates in their projects as well by working in their branches and accepting their merges when needed. As a team, we worked united and we always made sure we were all on the same page. During this sprint, we learned new things that we could incorporate into our team including updating each other on what we are working on today to be on the same page. We never let any team get lost and we were always there to pick each other up. One moment I could recall is that one of our member’s computers was having issues and we all as a unit came to find the issue which we did. Even for minor mistakes like commit messages, we made sure to edit and fix them to pass the pipeline. 

The pattern I would choose from the Apprenticeship Patterns book would be to expose your ignorance. It’s great to work alone and do your own thing but if you get stuck don’t be scared to get help from teammates instead of figuring it out alone. It’s great to get feedback and ask questions to everyone. This pattern is key for the growth of a developer and being able to be humble when addressing gaps of knowledge. You don’t have to act like you know everything because of pride or embarrassment but be willing to learn and be curious without fear. During this sprint, if I didn’t ask for help in certain scenarios I wouldn’t have known how to continue my project but being able to discuss boosted my work progress. When you are first joining a team you want to be reliable instead of a burden but asking questions as a whole will strengthen your team. During this spring I wouldn’t have hesitated to ask more questions that I had figured out on my own.     

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