Category Archives: Week 5

Blog Post 1

https://github.blog/engineering/engineering-principles/how-we-use-github-to-be-more-productive-collaborative-and-secure/

Since we’ve been going over GitHub and how and why we use it in class, I decided to pick an article right from the source. In the blogpost How we use GitHub to be more productive, collaborative, and secure, Mike Hanley describes how the staff at GitHub use GitHub themselves as well as how they’ve made new additions with developers in mind. A neat thing I thought as developers themselves working on GitHub I’m sure they thought “wouldn’t it be nice if…” then realizing “oh wait we can just add that”. One of those features that the blog mentions is the “new code search and code view”, which allows for a more quick and easy way to sift through multiple lines of code.

Another point in the blog was about productivity and under that Codespaces. As we had used Codespaces during the GitKit Chapters, it felt well integrated, so I was pretty surprised to find out that it was something that they had only recently implemented and started using (they started using Codespaces in 2021 and the article was written in 2022). Based on the article, this allowed what once took 45 minutes on local hardware to 60 seconds on much faster hardware then most would have on hand. This alone struck me as a sort of equalizer, allowing for more inclusivity in the fact that you don’t need to spend a lot of money on hardware to be on the same “playing field” as other developers.

The last main point in the blog goes into GitHub’s stance on security, which I guess isn’t to surprising as Mike Hanley’s current role in GitHub as well as his previous role was being in charge of security. Anyways, too often is cybersecurity put on the backburner until an inevitable data breach occurs, then it’s all “we value our customers security and privacy” and “security is our number one priority”. Mr. Hanley also seems to see things the same way, as he mentions how they were “still pleading with organizations to implement multi-factor authentication…”, something I consider to be pretty bare-minimum in terms of keeping ones accounts safe. Due to this stance on security I was glad to see that GitHub actually enforces multi-factor authentication with security keys. Another method of keeping things secure is their use of CodeQL. According to the article, in the same open-source spirit that GitHub was founded with, CodeQL queries are also open-source where either GitHub or other developers can share vulnerability patterns. This allows for not just “one set of eyes” to pinpoint possible exploits but instead the entire community.

Reading this article has given me a better sense of how the tools and practices we’re learning now actually look in a professional environment. On top of that seeing GitHub’s own team use features like code search, Codespaces, and built-in security tools shows how even though it feels like we’re leagues apart we’re still on even footing.

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

Blog Post for Quarter 1

October 5th, 2025

Recently, I’ve been working on using Git. This came in the form of using a little bit of GitHub, a little bit of GitLab, and the textbook made to help instruct me on how to use them. I began to learn the basics of repositories, and how to make edits and pull requests.

For example, I am now able to create a fork from a repository, create a remote origin, a clone of that onto my local device, make edits using Visual Studio Code, stage those edits, commit those edits, push those edits back to my remote origin, then establish a pull request. And a little bit more. So far, this Quarter of my class has been pretty interesting. I will note how the public changes and such are very interesting to me. I don’t usually like being in public places often because I assume I should be competent before doing anything in public, but oh well.

For the blog post I selected, I wanted to know just a smidge more about Git, since I was learning about it. (This will be linked below at the bottom of this post.) It mostly discusses the future plans for Git and potential for AI.

Honestly, there isn’t much for me to really do from this. I just note how AI appears to be Git stuff I currently use, so that’s mildly interesting. Though, I found it interesting that Git, much like I, is currently developing. It’s fun to think about how I learn and improve as a person that other things in the world are doing the same. While they are wildly different contexts, I find it cool. Everything is always changing and such. Even as I learn, I make notes that aren’t in the textbook to myself. Git will probably always get things added by various different people as well.

It encourages and intimidates me in some way. It’s very cool that by the time I “get caught up” it’ll be better than what I’m currently using, but at the same time, what if everything I learned becomes redundant? Though, for me, I was always a person to enjoy experiences, and I never really liked the idea of a limit. If anything, it is just more “fun” for me. There’s more to learn and I’ll never be caught up. My experiences will lead to my growth, so when the time comes, I’ll be much more suited to using the new tools that arrive.

https://github.blog/open-source/whats-next-for-git-20-years-in-the-community-is-still-pushing-forward/

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.

Understanding Project Management

The blog post by David Hartshorne begins with covering the basics of what project management is. Project management covers the overall facets of how to meet and achieve the deadlines of a project such as setting goals, meetings, and communicating and collaborating the the stakeholders/customers. This is all done in order to insure that tasks are completed in an efficient and timely manner to avoid mistakes or possible challenges from popping up. The blog then moves into have many different types of companies from software to construction as examples that use project management. The main types of projects are,

Predictive: Follow a linear timeline between phases

Adaptive: Short periods of work with frequent check-ins and feedback

Hybrid: A blend of the two

There are also five main phases to the process of a project which are,

Initiating: Laying the foundation of the project including understanding the project scope, main overview and budget

Planning: Define members roles, goals, time tables, and needed resources

Executing: The start of the project, institute changes and suggestions as needed

Monitoring: Check-ins and consistent communication, keep and eye on the goals and overall task at hand

Closing: Deliver the project, Conduct overview on the project on what went good and bad and where to improve

I chose this blog post due to its depth on the topic of what project management is. The blog focuses on the overall scope of the project and all of the possible avenues that need to be considered from tools to aid the process, team members and their roles, phases, tips, and the main areas of management. I also was attracted to this topic due to its application to industry as having a key understanding of project management is needed when either running a project or being the best team member that you can be. Having read the blog, there has been a fundamental shift in how I view projects and my role in them and my other team members. The need to constant communication has only been further reinforced as the backbone of a solid project. Clear defining of roles and goals is also needed to ensure that everyone knows what they need to do. With goals, something that also stuck with me is to keep the prioritization of the goals that need to be completed all within a realistic scope. This stuck out to me as I often feel like and find that scope creep can quickly seep into projects and teams and take hold. I have also begun looking into and pursing how to apply the suggested team-based tools like roadmaps and time management software to help keep me on task and use on future projects such as some of the suggested software like “Waterfall” and “Agile”. This blog was an excellent source on information on the management process and I encourage everyone to read it for themselves.

Works Cited

Hartshorne, David. “A Guide to Project Management.” Monday.com Blog, 20 Dec. 2020, monday.com/blog/project-management/guide-to-project-management/

From the blog CS@Worcester – Dan's Blog by Daniel Fung-A-Fat and used with permission of the author. All other rights reserved by the author.

UML Diagrams With PlantUML

Week 5

This week I chose to expand my knowledge on UML class diagrams in PlantUML. I referred to the PlantUML website where they go over every command that is available to use and how they work. I wanted to read up on class diagrams to prepare myself for creating them in the homework assignment on UML diagrams and for refreshing my knowledge on UML. 

The website goes through all the types of elements you can create, relationships between them, putting labels on relations, defining visibility, adding methods and variables, and how to add notes. 

-The UML block is contained in “@startuml” and “@enduml”. In the dev container we used in class it is contained in ““`plantuml" and ““`”.
-To create a class, use “class <name> {<body>}”. If you want to make an abstract class or interface, you would do “abstract <name> {<body>}” or “interface <name> {<body>}”. 
-To define visibility modifiers for attributes and properties, use + for public, – for private, # for protected, and ~ for package private. By default, the diagram will show these symbols in colors and shapes, but that can be changed if wanted. A static attribute is defined with
“{static}” before the name.
-The site shows a lot of ways to create notes and all the things you can do to change them, like location, size, color, line breaks, etc, which can be useful to categorize notes in your diagram. 
-You can also change the colors of classes and elements, which can help to organize as well.
-Another element you utilize is arrows, when a class is defined, you can say “implements <class>” or “extends <class>” and it will automatically use the correct arrow. But, you can create your own arrows for associations by using “–>”, “-[bold]->”, “-[dashed->”, “-[hidden]->, or “-[plain]->” with the class names on either side. Notes can be attached to arrows as well. For example: Order “many” –> “1” Customer

I referenced the site a lot while doing the UML homework for a refresher. While working on the base assignment, I was cross referencing a lot to make sure I was doing it correctly, but when I got to the advanced assignment, I felt a lot more confident and comfortable with creating UML diagrams in VSCode and only needed to reference it for creating static variables. 

UML diagrams are essential for smooth code developing and finding any structural issues before you’re too deep in a project. Having the knowledge and practice to create them will definitely help me outside of this class. Using PlantUML is now something I feel like I can say I can do in real life. In the future, if we make more diagrams in class or if in a job they ask me to make one, I feel comfortable telling them I can make one.

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

Unit Testing: Decision Tables

Week 5 – 2/23/2025

For this week’s blog, I recently came across an insightful article titled “Decision Table Testing: A Comprehensive Guide” on the Testsigma website. This article provided a detailed overview of decision table testing, a technique for testing system behavior for various input combinations. The article not only defined the concept but also went over its applicability, benefits, and practical applications. 

I chose this resource because we had just done a POGIL activity on decision table testing in class, and I wanted to learn more about how it works in real-world circumstances. The article stood out to me because it was well organized, simple to understand, and contained practical examples to make the subject more approachable. As someone who is still learning about software testing, I found this material to be both instructive and accessible.

The article begins by defining decision table testing as a black-box testing technique for determining how a system responds to different input combinations. It then describes the structure of a decision table, which is made up of conditions (inputs) and actions (outputs), as well as how to generate one. What I found most useful was the step-by-step illustration of how to apply decision table testing to a login system. This example helped me visualize how the strategy works in practice.

One of the most important takeaways for me was the emphasis on the value of decision table testing in dealing with complex business logic. The article explained how this technique assures that all conceivable scenarios are examined, lowering the likelihood of missing key edge cases. This spoke to me because, in my limited experience, I’ve seen how easy it is to overlook specific input combinations, particularly in systems with several decision points. The blog also covered decision table testing’s limits, such as its inefficiency for systems with a large number of inputs, which helped me understand when to utilize this technique and when to look into alternatives.

Reading this article has greatly increased my understanding of decision table testing. I’m now more confident in my ability to apply this strategy to future projects. For example, I envision myself utilizing decision tables to evaluate systems with well-defined criteria, such as payment processing or eligibility verification. In addition, the blog emphasized the need for thorough testing and considering all possible circumstances, which I will include in my testing methods.

Overall, this article was a helpful resource for my learning experience. It not only simplified a subject that I was having trouble understanding, but it also provided practical insights that I may use in the future. This article is highly recommended to anyone looking for a clear and practical explanation of decision table testing.

https://testsigma.com/blog/decision-table-testing/

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

Test-driven Development

URL: https://semaphoreci.com/blog/test-driven-development
The blog in question was written by Ferdinando Santacroce on Sephamore. The title is Test-Driven Development (TDD): A Time-Tested Recipe for Quality Software. He walks his readers through many topics related to Test-Driven Development. These topics include TDD as a design practice, TDD as a well-established engineering practice, and many others.

Test-Driven Development caught my attention because it implies that the inverse of traditional testing should be done. Instead of writing tests for existing code, you should rather write tests for code that has yet to be written. This is confusing in some ways and also misleading when considering only the phrase “Test-Driven Development.” However, as we all know, every concept means more than just the words it comprises. And TDD (or Test-Driven Development) follows the same rule—it is much more than simply writing tests first.

I would personally call it a way of thinking or a different point of view on how tests and code are written. TDD resembles Agile and Scrum’s approach to software development. It shifts the developer’s focus from simply producing and creating large amounts of code—where everything eventually becomes one big entity—to a much more structured and manageable process. As Agile methodology suggests, it is better to build, review, test, and repeat. This method, combined with Scrum, takes this perspective further. Small chunks of functionality are built in shorter time frames, allowing for continuous review and feedback.

TDD applies the same principle with one key difference: test first—or at least, write your tests first. By writing down what should be tested and what a program should return or produce, you now have a clear goal. This method shifts the traditional way of thinking and provides a clear path to the main objective. This objective is then broken down into many smaller pieces that are easier to understand. Another benefit of TDD is the constant feedback, often called a “pleasing side effect.” Continuously receiving feedback on your code gives you a steady sense of accomplishment.

The outcomes of introducing Test-Driven Development into one’s development process can bring many benefits. However, beneficial outcomes are not guaranteed for every single person who applies this methodology. That said, I would argue that certain developers may benefit more than others. Developers who often feel lost, confused, or disoriented may benefit greatly from Test-Driven Development. This approach provides them with a clear understanding of the code’s structure in a more modular and organized way. By separating the code’s functions into different sections, building blocks, or containers, TDD creates a more structured and efficient development environment.

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.

Unit Testing and Testable Code

Unit testing is a fundamental practice in software development, ensuring that individual units of code work as expected. However, the real challenge often lies in writing code that is easy to test. Poorly designed, untestable code can complicate unit testing and introduce expensive complexity. In this blog post, we’ll explore the importance of writing testable code, the common pitfalls that make code hard to test, and the benefits of adopting testable coding practices.

The Significance of Unit Testing

Unit testing involves verifying the behavior of a small portion of an application independently from other parts. A typical unit test follows the Arrange-Act-Assert (AAA) pattern: initializing the system under test, applying a stimulus, and observing the resulting behavior. The goal is to ensure that the code behaves as expected and meets the specified requirements.

However, the ease of writing unit tests is significantly influenced by the design of the code. Code that is tightly coupled, non-deterministic, or dependent on mutable global state is inherently difficult to test. Writing testable code is not only about making testing less troublesome but also about creating robust and maintainable software.

Common Pitfalls in Writing Testable Code

Several factors can make code challenging to test, including:

  1. Tight Coupling: Code that is tightly coupled to specific implementations or data sources is difficult to isolate for testing. Decoupling concerns and introducing clear seams between components can enhance testability.
  2. Non-Deterministic Behavior: Code that depends on mutable global state or external factors (e.g., current system time) can produce different results in different environments, complicating testing. Making code deterministic by injecting dependencies can address this issue.
  3. Side Effects: Methods that produce side effects (e.g., interacting with hardware or external systems) are hard to test in isolation. Employing techniques like Dependency Injection or using higher-order functions can help in decoupling and testing such code.

Benefits of Testable Code

Adopting testable coding practices offers several benefits:

  1. Improved Code Quality: Testable code is typically well-structured, modular, and easier to understand. This leads to higher code quality and reduces the likelihood of bugs.
  2. Easier Maintenance: Code that is easy to test is also easier to maintain. Changes can be made with confidence, knowing that unit tests will catch any regressions.
  3. Faster Development: With a robust suite of unit tests, developers can iterate quickly and confidently, reducing the time spent on manual testing and debugging.
  4. Enhanced Collaboration: Clear and testable code promotes better collaboration among team members, as the intent and behavior of the code are easier to comprehend.

Conclusion

Writing testable code is a crucial aspect of software development that extends beyond the realm of testing. It encompasses good design principles, decoupling, and the elimination of non-deterministic behavior and side effects. By focusing on writing testable code, developers can create software that is not only easier to test but also more robust, maintainable, and reliable. Embracing these practices ultimately leads to higher quality software and more efficient development processes.

All of this comes from the link below:

https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters

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

Software Testing Thinking Hats

The blog post I’ve chosen talks about the different mind sets that you should use when tackling different situations. When writing tests, it helps to write tests with different goals so that you don’t forget to test every aspect of some section of code. The blog author talks about how trying to do the tests out of order or without any order in mind you can forget things and cause it to take more time in the long run. The author categorizes these as “hats” to wear during each progressive stage. There is the ambitious hat which is for when you are testing the code in the way the customer will be using the code. There is then an uncomfortable hat which is for when your tests are failing, and you need to fix what you can in your testing. The confident hat is the one you can wear while you are refactoring your code and running just to confirm everything passes. The author also makes specific mention to not try and wear multiple hats at once.
From my experience in the classes I’ve taken so far, I’ve done some built in testing in files for whole programs that I myself have written, and so I know exactly what the code should do, what I need to have pass in order to meet the homework criteria. In these cases, because I am both the author of the code and the author of the test cases, I am able to make edits in both parts with the knowledge of exactly what the test cases should be. This has helped in my current class so far but as we move forward, we will be approaching testing like it is done in the workplace and when the people testing the code are a separate group that has not touched the program code. I’ve definitely seen myself as the coder that the author describes who frantically moves around the code and tests trying whatever I can to get everything to work instead of approaching it with any methodology. I want to become both better and more efficient at testing code as it will help me write code also and further my understanding of what makes a complete program. Testing is a big part of working in the computer science field and I know that quality assurance is very important, so I look forward to both learning more about this within the course and doing more blogs about the industry.

Chris James – The TDD Thinking Hats

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

Exploring Design Patterns in Computer Science: A Beginner’s Perspective

Design patterns are essential concepts in software engineering, providing time-tested solutions to common problems. As an apprentice in computer science, understanding design patterns can significantly boost your coding efficiency and software design skills. During my learning journey, I found an insightful article, Java Design Patterns from GeeksforGeeks, that provided me with a solid foundation on design patterns. Here’s a summary of the article and my reflections on how it has shaped my learning experience.

Summary of the Selected Article

The GeeksforGeeks article Java Design Patterns covers the key design patterns used in Java programming. It introduces three main types of design patterns—Creational, Structural, and Behavioral. Each category is explored with practical examples and explanations that break down the complexities of design patterns into digestible information. The article also touches on popular patterns like Singleton, Factory, Decorator, and Observer, providing clear definitions and illustrating their use cases in real-world Java applications. It serves as an excellent resource for beginners to grasp how design patterns can improve code readability, reusability, and maintainability.

Reason for Choosing this Resource

I chose this article because GeeksforGeeks is known for delivering educational content tailored to both novices and experienced developers. I needed a source that could present design patterns clearly and practically, specifically for Java programming, which I am currently studying. The website’s step-by-step approach to explaining concepts, accompanied by code snippets, resonated with my learning style. As a beginner, I was looking for a resource that could demystify design patterns without overwhelming me with technical jargon, and this article did exactly that.

Personal Reflection and Key Takeaways

The material was enlightening, especially in how it framed design patterns as reusable solutions to software design issues. Before reading the article, my understanding of patterns like Singleton or Factory was limited to theoretical concepts, but the examples provided helped me visualize their practical applications. One major lesson I took from this article is the importance of the Singleton pattern, which ensures that a class has only one instance and provides a global point of access to that instance. This concept is essential in areas like database connections, where having multiple instances could lead to conflicts.

Additionally, learning about the Factory pattern—a creational pattern that allows for the creation of objects without specifying the exact class—opened my eyes to how flexibility and scalability are achievable in code. This pattern is especially helpful when dealing with large projects where new object types might frequently need to be added.

The article not only strengthened my grasp of object-oriented principles but also inspired me to think more critically about how I structure my code. It shifted my perspective from merely getting the code to work, to considering how to design it efficiently for future use and maintenance. I now see design patterns as a roadmap to writing better, more scalable code.

Future Application of Design Patterns

Moving forward, I plan to incorporate these design patterns into my coding work practices, particularly in my Java projects. The Singleton pattern will be useful in managing system-wide resources, while the Factory pattern will aid in developing modular code that can easily evolve. Understanding these patterns equips me to write code that is not only functional but also adaptable, which is crucial as I delve into larger, more complex projects.

In conclusion, design patterns are invaluable tools for every software developer. Thanks to resources like the GeeksforGeeks article, I now have a clearer understanding of how to implement these patterns in Java, and I look forward to applying them in my future projects.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

Code Review

For my first real blog entry, I would like to talk about Code Review. I chose this topic because we are doing in-person activities based on clean code, in my Software Process Management class. When discussing how to make code cleaner and more readable, I looked more into the topic for more information. Code Review is a process performed by a person or more to examine and improve the code. I found this blog titled “How to Review Code – Tips and Best Practices” by ‘AK DevCraft’ and noticed that some of the points and practices are the same as we learned in class.

The blog highlights three important tips to be aware of when reviewing code, the first tip being Intention. This tip explained what the dos and don’ts are when reviewing code. When you review someone’s work, it’s pivotal to be positive and respectable. Giving constructive criticism, and explaining precisely what changes need to be made to improve the code. The blog also made sure to emphasize not to leave comments where you didn’t need one. Adding multiple comments to code is unnecessary and makes the code harder to read. The summary of the first tip was to be respectful to the ones who wrote the code and make it a collaboration when reviewing the code.

The second tip the author said was important was Standards. When reviewing code, making the code easy to read while making it easy to understand is what coding is all about. This can be done by sticking to a consistent format, which can be having meaningful whitespace, removing unnecessary gaps, or breaking larger functions into smaller ones. Understanding the standards of variables by creating clear and concise names for every variable. By knowing to avoid abbreviations and add values to variables such as “gallon” or “mL” to make the variable clear on what unit it is. A good practice we learned in class is to avoid duplication, duplication of code can lead to unnecessary code or more confusing messes like bugs or error messages.

The last tip the author highlighted was to review. When finishing the code review, keeping the big picture in mind can verify if your changes were necessary. GitHub is a platform we are using in class for our in-class discussions the platform has a review system to look over the source code and can help you double-check the code.

The blog shined a light on tips I believe are important when reviewing code, when my group did discussions on reviewing code, we used the same tips listed in this blog in our discussion. The blog gave me information on taking reviewing code to the next level, informing me of the GitHub feature to review the source code and always keeping a strict format in mind when reviewing code. I would recommend this blog to someone who is new to reviewing code or just wants a different approach when reviewing code with another person.

Source: https://dev.to/akdevcraft/how-to-review-code-2gam

From the blog Mike&#039;s Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.