Clean code is about writing software that humans can easily read, understand, and change. Not just about making something that compiles and runs. The main idea is that code should communicate clearly to other developers so the intent of each part is obvious without needing to dig through the entire project or guess what the … Read more
From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.
This week we learned a lot about front-end development. Working through the microservices front-end activities (MS07–MS09) really helped me understand what the front end is all about. As a CS student who loves full-stack development, the activities offered a structured approach to seeing how a front end fits into a bigger system rather than just … Read more
From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.
Design patterns are important for developers to use in their code. They make your programs easy to read and implement and they are able to be adapted to many situations. There are 3 kinds of design patterns: creational, structural, and behavioral.
Creational patterns are used for creating objects. They give flexibility to change the creation process and allow for many types of objects to be created using the same method. The singleton pattern is used when there should only be one instance of an object. Instead of creating a new object every time you need to call it, you call a method that will call an instance of the object. The builder pattern is used when an object has a lot of optional parameters that make it difficult to know what is being applied when it is created. Using a builder pattern creates an empty or default object and then calls set methods to add each parameter you want to use. The factory pattern is for when there are a lot of objects of a certain type, but with different forms. Instead of creating many new objects, you call a factory to create the objects with the specifications hidden in the factory code.
Structural patterns are used for how objects relate to each other. These patterns allow for high level code to be readable and simple, while keeping the intricacies hidden below the surface. The facade pattern is used when there are many operations and calculations behind the scenes of a process and those are all hidden with encapsulation. On a high level, one method will, for example, purchase a product, but deeper, there is a payment being processed, shipping calculations, inventory checks, etc. The adapter pattern is for when a program needs to be adapted to fit your code. It can be used for implementing public libraries where their units do not match what your program expects, and each time you use the public library, it calls the adapter to modify the output.
Behavioral patterns are used for how objects interact with each other. The strategy pattern is used when you have multiple ways of doing a process. Instead of using a lot of if else statements, you can define several strategies and set each object to have a strategy. The observer pattern is used for objects that watch for something. It works by “subscribing” to receive a notification of an event. If a program is watching for errors, it would be automatically notified of any errors so it can add it to a log.
In class, we went over the strategy, factory, and singleton patterns for the Duck example. These 7 patterns are common practice in the software development field and it’s important to know how to implement them. I watched a video explaining these patterns and now I have a deeper understanding of the three we learned and the four that were new to me. I feel confident I can expand on these in a professional setting.
From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.
I am Dipesh Bhatta, and I am writing this blog entry for CS-348 Software Process Management for Blog Quarter 4. I chose to write about code review and how it connects to software process management. My chosen resource is an article titled “What is a Code Review?” from Atlassian (https://www.atlassian.com/agile/software-development/code-reviews). This passage explains what code review is, why it matters in software development, and how teams use it to maintain quality, consistency, and shared understanding across a project.
The passage defines code review as the practice of examining another developer’s work before it becomes part of the main codebase. It emphasizes that code review is more than a bug-finding activity. It helps improve readability, structure, naming, and overall maintainability. One important idea from the article is that code review serves as a communication channel. When developers submit changes for review, they are also sharing their reasoning and thought process with the team. This allows everyone to stay aligned and ensures that the project follows a predictable and well-managed workflow. These ideas directly connect to the concepts of structured processes and shared ownership that we learn in CS-348.
I chose this resource because code review is a key part of modern software process management. Throughout the semester, we used Git, branches, merge requests, and clean code practices. Code review brings all of these together into a single process that supports collaboration and project organization. Understanding how professional teams use code review helped me see the purpose behind good habits such as writing meaningful commit messages, keeping changes small, and separating different tasks into separate branches. These practices make reviews easier and prevent confusion later.
Another valuable point from the article is how code review helps reduce technical debt early. Small issues, such as unclear variable names or overly complex functions, may not break the program right away, but they make the code harder to maintain. Code review allows teams to fix these problems before they grow. This is especially important in long-term projects, where small mistakes can become costly if left unchecked.
The article also highlights the importance of giving feedback respectfully. Suggestions like “Could we simplify this part?” or “What do you think about renaming this variable?” create a more positive and productive review environment. I experienced this in class as well. The way feedback is written affects how teammates respond and how smoothly the discussion goes. Good communication makes the whole team stronger.
In short, code review is an essential part of software process management. It supports collaboration, improves quality, and keeps the codebase organized. Through Blog Quarter 4, I strengthened my understanding of reviews, communication, and clean coding practices that will benefit me in future projects and my career.
From the blog CS@Worcester – dipeshbhattaprofile by Dipesh Bhatta and used with permission of the author. All other rights reserved by the author.
Software licensing is a crucial part of the software development process. It is vital to establish a license to set the legal precedent for the work that can be enforced. This blog post from “Click Up” focused on different types of licensing and monetization models.
Software licensing outlines the terms under which a program can be used, shared, modified, or accessed. Different licences can have more restrictions or more freedoms than others.
Types of Licenses from the blog
Propriety: Commercial-based, normally only gives access to use the software and does not allow any further rights. An example is Microsoft Office.
Open Source: Gives large rights for modification, sharing, adaptation, and selling of further forms of software. Some examples are GNU GPL and MIT.
Free and shareware: Freeware can be used for free but may have limited features. Shareware is software that has a free trial version to push the user into buying the full version to either access all the content or continue allowing usage. An example of this is the Adobe suite.
The blog also outlines potential terms of monetization for software and the main forms being used. The types are
Perpetual: One payment with complete ownership of the software. Maintenance may be a separate plan
Subscription: Lower upfront and user-decided cost, but recurring cost with less control and no complete ownership for the user
Usage-Based: Monitor consumption and charge based on usage. Requires metering
Pay-for-overage: User pays base fee and more if they exceed a threshold of usage. Often used in conjunction with usage-based or subscription
Device: Restricts to one or a certain paid for number of paid-for devices
Concurrent/Floating: After paying, you have a set number of uses for the software
I chose this topic due to the coverage in class on licensing topics. While we mainly covered why licensing is important and what the main types are, I wanted to learn more and look into what the other forms of application are. It was good to be able to learn more about how people work to monetize their programs and work through their licenses. One of the biggest things that I learned from the blog and to consider in my future works is in terms of licensing. While I would normally favor open-source for my own projects, in a work environment, I know that the revenue stream from the software must be considered. I now have a greater understanding of potential licenses to consider with software and what the user will be getting when they pay. I found perpetual licenses to be most appealing, and then pushing updated forms to the users or simply selling new yearly versions, as was done in the past with software before switching to a subscription-based model. This is due to my desire to have the user still owning the software while not needing a constant internet connection.
Works Cited:
Team, E. (2024, September 28). Types of Software Licenses and Models Explained | ClickUp. ClickUp. https://clickup.com/blog/types-of-software-licenses/
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.
As we continue to study API implementation in my CS343 class, I find it important to continue to learn more about the subject. I came across this article that discusses 11 security practices for API implementation. A statistic I found interesting that is brought up at the beginning of the article is that APIs now account for more than 80% of internet traffic. The first practice listed is continuous API discovery. This means automating processes that catalog APIs across your infrastructure in real time. Doing this helps prevent the deployment of shadow APIs. The next practice is encrypting traffic in every direction. This one seems fairly obvious, but it is something that cannot be forgotten. The article also lists some key encryption requirements. Authentication and authorization are very important practices for API implementation as well. This allows for control over the usage of the APIs in the system, and it protects the user by keeping their primary credentials hidden to prevent theft and misuse. Using the Principle of Least Privilege is another good practice. Granting users the least amount of privilege necessary to use the system prevents damage from a malicious user. Documentation is also very important to help other developers maintain the system in a safe way. You must also validate your data to help protect against injection attacks. Make sure to limit data exposure as well. Data breaches are an issue that no one wants to deal with. The article lists a few more practices that are important for security in systems that use APIs.
This particular article stuck out to me because, as I said in the beginning, we are learning about API implementation in my CS343 class. Knowing the typical security practices for implementing APIs is imperative for creating a good system. It’s something that many may overlook, but cannot be omitted. I myself had failed to consider the potential security risks of implementing APIs. This article gave good insights on the security risks and how to prevent them. This was definitely worth the time it took to read and understand. It is always important that the data going through your system is protected to ensure that the users have a problem free experience. The problems that could possibly arise from a lack of security could result in huge losses for a company deploying these systems. As someone who has not had to deal with that kind of risk yet, I believe it is important I learn about these potential issues before it becomes too late.
https://www.wiz.io/academy/api-security-best-practices
From the blog CS@Worcester – Auger CS by Joseph Auger and used with permission of the author. All other rights reserved by the author.
For this blog, I chose the blog “REST API Design Best Practices Guide” from PostPilot. I chose this resource because our course directly works with REST API, focused on backend development, and how different software components communicate through REST API. Since REST APIs are one of the most common ways to build websites, I felt it was important to reinforce what I learned in class about how to work with REST API.
The blog explains the core principles behind REST, including having a stateless server, a client server relationship, caching, and interfaces. It then goes into the basics for building APIs that are easy to understand. One of the first practices it suggests introduces designing resource based URLs using nouns instead of verbs and making them simple and plural such as users or orders. It also emphasizes the importance of properly using HTTP methods, like GET for retrieving information, POST for creating data, PUT or PATCH for updates, and DELETE for removal. The guide goes deeper by discussing when to use path parameters versus query parameters, especially for filtering data and explains why good responses help developers with context and confusion.
Something I found especially insightful was the explanation on versioning and error handling. The blog explains why APIs should include versioning so that future updates don’t break existing clients. It also explains why providing consistent and descriptive error responses are important so that developers can debug what went wrong rather than guessing. It also talks about security requirements such as using HTTPS and authentication tokens, as well as using tools like Swagger to make the API easier for other developers to use.
This blog improved my understanding after reading it, I’ve noticed that good planning and design are crucial, especially when multiple people use the same system. I noticed that the HTTP method already conveys the idea, so keeping endpoints focused on resources makes everything cleaner.
Hopefully, I can apply what I learned in future API work, particularly when working with backend development. This blog’s information will definitely be helpful when designing good and useful APIs rather than messy and unreadable designs. This blog has made me more aware and informed of how important API design is, not just for functionality but for maintainability and ease of use. Reading this guide along with that I’ve picked up in class gives me a strong foundation to understanding REST APIs, if not at least be a little more informed on the topic..
https://www.postpilot.dev/blog/rest-api-design-best-practice-cheat-sheet
From the blog CS@Worcester – Coding with Tai by Tai Nguyen and used with permission of the author. All other rights reserved by the author.
For my last quarter blog post, I decided to explore the topic of documentation. Even though we didn’t talk about it directly in class, we were actually working with it during many of our activities, like working with REST, learning how the frontend and backend communicate, and practicing the commands needed to run both sides of a project. Most times the owners of a product aren’t technical, and because of that, engineers end up having to create their own documentation so everyone can understand how things work. All of our in class activities became much easier when we had clear and easy-to-follow documentation in front of us. The blog I chose for this post, written by Mark Dappollone, goes deeper into the topic by giving tips that help both the person building the product and anyone trying to understand how the software works.
Mark’s blog explains three main ideas about documentation that people should understand. The first is that the only way to create good documentation is to just get started and write something. He points out that when there is no documentation, people are forced to rely only on the code and if the code is wrong or changes, no one would know because there’s nothing written down to compare it to. So even if your documentation isn’t perfect, it’s still better than nothing. Without it, clarity disappears and developers end up guessing what’s going on.
The second idea is the importance of using visual aids. One of my favorite examples in the post was when he included a screenshot and labeled each field with the API calls and the data fields they come from. This instantly shows how everything connects to backend data through REST, which is exactly what we practiced in class. With visuals like that, developers can read and understand the logic behind GET or POST requests without having to guess.
The third and final idea is keeping documentation updated. In class, we noticed that even small changes to the code, like changing where data/input is coming from for, can make things confusing very quickly. Without good documentation, things get messy for anyone working on the product. Keeping documentation in sync with changes to both the backend and frontend helps avoid those misunderstandings.
In the future, I can definitely see myself working with API calls or making frontend fixes, and using documentation will help me understand the whole picture. It also ensures that anyone reading the documentation can see how everything ties together. I would especially like to use visual aids because I’m a visual learner, and I think many people are too. Using visuals can help clear up confusion and make the whole development process smoother.
Source: https://mdapp.medium.com/how-to-document-front-end-software-products-e1f5785279bb
From the blog Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.
For this blog entry, I chose to review the blog “Software Licensing – Terms and Licenses Explained” by CrystalLabs because software licensing connects to what we’ve been learning and working with in class. The blog explains what software licensing is, how it works, and why choosing the right license is essential for developers and organizations. It also covers the differences between proprietary software, open-source software, and other license types that decide whether people can modify or redistribute code. This ties directly into our course discussions on ownership, copyright law, and the responsibility developers have when sharing their work.
The blog begins by defining a software license as a legal agreement that outlines how software can be used, shared, or changed. Proprietary software licenses are restrictive, stopping users from seeing source code or redistributing the program. Most commercial software uses this model. The blog then explains that open-source software gives users more freedom, but the level of freedom depends on the specific license. Permissive licenses like MIT or BSD allow people to reuse the code in pretty much any way they want, including in commercial applications. Copyleft licenses like GPL require that any modified version remains open-source under the same license, protecting long-term openness. The blog also briefly touches on public-domain software, where the creator essentially gives up all rights.
I selected this resource because software licensing is something that is extremely important but I didn’t fully understand. Since we are studying software licensing in class, learning how and when I can use someone else’s code is crucial. It isn’t just about making software work, developers must consider legal compliance and respect for the original author’s intentions.
What stood out to me was how much power a license has over the future of a project. One document can determine whether software becomes a community project or remains locked behind a licensing wall. Now I understand that licenses shape the project itself, being an essential part of the start of any work. This made me more aware for future software that I work on later down the line, I will need to purposely choose a license that matches my goals.
Overall, this resource helped me better understand software licensing as something tied to ethics, law, and user rights. I’m definitely more prepared to navigate licensing in my future work, the software I use and create will be properly licensed with this knowledge in mind.
https://crystallabs.io/software-licensing
From the blog CS@Worcester – Coding with Tai by Tai Nguyen and used with permission of the author. All other rights reserved by the author.
I’ve been hearing about artificial general intelligence (AGI) a lot lately, so I investigated how it’s beginning to affect the day-to-day work of frontend and backend engineers. Since clean design, architecture, and concepts like SOLID and DRY are the major topics of our course, I was curious in how these fundamentals might evolve as AGI advances. What I found is that AGI does not diminish the significance of smart engineering – it enhances it.
With just a prompt, AGI tools are getting better at creating visual elements, layouts, and even a complex relationship. For frontend developers, this means less time spent creating repeated markup and more time thinking about user experience, accessibility, and smooth interactions. Instead of hand-crafting every item, engineers will guide AGI-generated components and refine them, much like examining a merge request in GitLab. AGI may generate the first version, but the developer decides what is appropriate for production.
The impact is even greater for backend engineers. AGI is capable of writing controllers, creating REST API endpoints, building database structures, and even producing metadata. However, backend systems depend largely on architecture, security, error management, and scalability – areas where AGI still needs human guidance. A developer must still apply clean principles, prevent code smells, and create connected components. Similar to how pipelines, CI/CD, and merge approvals protect the main branch in a GitLab workflow, backend engineers must examine each AGI-generated change to ensure system stability.
One thing that sticks out to me is how AGI transforms the developer’s position from “code writer” to “system thinker.” Instead of entering every line manually, developers will focus on verifying logic, detecting edge cases, defining patterns, and structuring interactions. This is consistent with our understanding of UML diagrams and architectural styles: humans define the structure, while AGI can produce its parts. Using GitLab as an example makes this obvious. Even if AGI generates code on a feature branch, the developer still analyzes the merge request, reviews pipeline results, and ensures the update matches project requirements. AGI can aid, but it cannot replace human expertise in maintaining clean design, secure APIs, or reliable backend logic.
Overall, I concluded that frontend and backend duties are not vanishing – they are developing. While developers will focus more time on design, problem-solving, moral decision-making, and long-term maintainability, AGI will automate routine tasks. Understanding ideas like abstraction, encapsulation, and GRASP patterns will remain crucial since AGI operates best under strong human leadership.
References
From the blog CS@Worcester – Pre-Learner —> A Blog Introduction by Aksh Patel and used with permission of the author. All other rights reserved by the author.