Hello! For this quarter’s blog I read a post written by Jeff Bridgforth, titled “Think like a front-end developer.” Coming to the end of the semester we have started working with the frontend, and I got the impression that it would be useful to see, as with my other blog posts, the insights someone who actually has experience working on it may have. As such, I wanted to find a blog that could give me an idea of the practical priorities and decision patterns used in real projects, this post does that well. 

To quickly summarize, a front end developer is someone who designs what a user/client/etc. would actually see when they interact with a program. It encapsulates everything from the UI to how it interacts with the backend, or what goes on behind the scenes. Jeff outlines the basic mindset he believes front-end developers should have. He explains that the three main languages used for front end (html, css, and js) should be “partitioned” specifically for certain roles: html for structure, css for styling, and javascript for behavior, and that keeping these separate makes everything easier to understand and maintain. He also explains that starting with clear, semantic html should come first, then building from that with css before adding any javascript. He also talks about the importance of being involved early in the design process, keeping things simple and using small, practical tools for tasks like testing and image optimization.

Web dev is something I have at least done a few times before starting this class unlike some other topics we have gone through, so I would say I am comfortable with the “design” side of front-end. That being said, when it comes to having it actually “do things” beyond allowing people to navigate from page to page (in other words, interface with the backend aka working with an API), I was completely inexperienced. Our class has really helped me with getting used to all that, but as we are in a classroom setting, like everything else we have learned there is a lack of practical insight to the material. Over this semester I have realized the value of looking online and finding these blog posts, as the first-hand experience they have informs them as to what they should prioritize, which they end up writing about and thus passing on to readers such as myself. Very useful. Anyways I was a bit unsure exactly how the various programming languages would interact with eachother, if this blog is anything to go off of it seems smart to keep them separate, which makes sense. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

Original Blog:https://blog.logrocket.com/solid-open-closed-principle/

For this post, I’ve decided to write about the application of the open-closed principle in programming, and how new features can be added to an existing piece of code without altering existing code. I’ll also be writing about the pitfalls of incorrectly using the Open-Closed principle in circumstances where it isn’t necessary or is excessive.

The Open-Closed principle is a principle in the SOLID foundation of principles, which is an acronym for the its tenants:

S – Single Responsibility

O – Open – Closed principle

L- Liskov Substitution Principle

I – Interference Segregation Principle

D – Dependency Inversion Principle

In the blog, “SOLID series: The Open – Closed Principle”, the author defines the open closed principle as dictating that a program be open for the addition of modules, classes and functions without changes to existing code being made. This can be done, among other methods, through the use of interfaces, which outlines which methods a class must implement without modifying the methods or class themselves, and abstract classes, which provide blueprints for future subclasses. By designing you program around the idea of shared methods within classes and inheritance, you ensure that bugs involving the code within those methods are few and far between. However, criticisms of OCP arise when the abstraction that results from repeated inheritance becomes cumbersome.

In the blog, the author states that many developers feel that the definition of the open-closed principle itself implies inheritance, leading some specific examples of improperly used OCP. The first one the author mentions is “Over engineered-abstractions”. This occurs when the amount of abstractions in a program is unnecessary, which could cause the program to become more complex than it needed to be. This can cause the codebase to become increasingly harder to understand to contributors, leading to possible bugs in the future of the program’s development. Another problem outlined by the author is the “interface explosion” problem. This happens when interfaces are overused in a codebase. The author mentions how the .net ecosystem suffers from this due to it’s reliance on dependency injection. When this is a problem, the codebase can become cluttered and dense.

In summary, the author explained the definition of the open-closed principle, then gave criticisms about the principle based on the environment in which they would be implemented, with inheritance and abstraction sometimes resulting in increase complexity and codebase clutter when implemented in environments that don’t necessarily need them. A thought I had about the material covered in the blog is how the use of the factory design pattern could help in cases of an “interface explosion”, since it would reduce dependencies required by the client for the code to function, and would reduce the amount of locations that would needed to be edited to add a new object of a certain type.

From the blog My first blog by Michael and used with permission of the author. All other rights reserved by the author.

Original Blog: https://blog.ploeh.dk/2024/06/12/simpler-encapsulation-with-immutability/

For this post, I’ve decided to write about encapsulation, and how implementing immutability in a program can make implementing encapsulation scalable and overall easier. I chose this topic because it seems like an interesting look at how concepts learned in a course I’m currently taking would appear in projects designed for a large user base.

Encapsulation is a widely used concept of object oriented programming, and for good reason. It allows developers to make efficient methods and functions with only the necessary amount of information, and also makes the scope of variables clear and defined, leading to debugging and problem identification becoming much easier than they would be without the use of encapsulation. A problem with encapsulation, however, is introduced in the blog “Simpler encapsulation with immutability”, by Mark Seemann. Seemann identifies a common difficulty encountered when implementing encapsulation on a large scale: How do we ensure that invariants are included? Invariants are defined as conditions within the program that remain true regardless of changes made to other areas of the code. This can include class representation, loop invariants, or other assumptions about the logic of your program. When implementing encapsulation at a large scale, it can be difficult to preserve this property in as many areas of the code as possible, with function variables taking different states throughout many points in the program.

A solution the author offers is to simply make the object immutable, guaranteeing that through whatever change it may see when the program is executed, it’s value can’t change. The author uses the example of making a program which models a priority list to model to difference in difficulty in preserving invariants, with the invariant being that the sum of the numbers in that list must be 0. Without defining each of the members of the list as immutable, it’s difficult to manually maintain at all times, while if the objects are immutable, you can guarantee that at no point will they not sum to 100.

In summary, the author outlines common problems developers have with implementing encapsulation while preserving invariants at large scales. He then provides the solution of immutability to ensure that at all times, objects desired to be invariants will be unchanging. Some thoughts I have about the blog are if making an object immutable could present some unwanted limit to the developer, and if that were to be the case, is there another solution which preserves invariants at a large scale without ensuring that a condition about an object only sometimes changes.

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.

Since our capstone project next semester will offer roles dealing with both frontend and backend, I thought it’d be a good idea to do a bit more research on each type of web development and how they compare to each other. Backend and frontend will be very relevant to me in the future as many jobs catered to software development involve working on either the frontend, backend, or both with full-stack. We also ran out of time this semester and did not get to fully cover the frontend, but a blog I found on CareerFoundry offered a good rundown on what frontend really is, as well as backend.

Frontend

Frontend is what you see on the screen of your device. It is the client-side. When working on the frontend, the languages you will most likely use are HTML, CSS, and JavaScript. CSS complements the HTML code by defining the style of the website’s content. It deals with the layout, colors, fonts, and more features of the website. Common tools that ease the tasks of the frontend developers include Express, Angular, JQuery, DJango, and SASS. 

Not Web Design

Frontend development is not the same thing as web design. A web designer focuses on designing the aspects of a website, whereas a frontend developer takes that web design and adds functionality to it using the previously listed languages.

Frontend Without Backend

A website is said to be static when the content of the site doesn’t really change. All necessary information that determines what’s on the website can be found on the frontend. This is good if you want to showcase your business or professional profile. In order for the website to be interacted with, the website needs to include a backend.

Backend

For the majority of the semester, we have worked on activities and assignments related to the backend. Common languages used in the backend are Ruby, JavaScript again, Python, and Java. In this class, we used JavaScript to write in backend code. Popular tools include Node.js, MongoDB, Flask, and PostgreSQL. We experimented with the Node.js environment and the MongoDB database in our work for this class.

Which One Should You Pick?

If you like the idea of working with visual designs and adding real actions behind them, creating a smooth easy-to-access experience for the user, frontend is the way to go. If you enjoy working with data, solving algorithms, and finding solutions to optimizing complex systems, backend may suit you more. However, if both descriptions fit you and are proficient on both sides, then you may be able to do both! A developer who is proficient in both the frontend and backend is known as a full-stack developer. But whichever path you choose to go down, understand that one cannot work without the other when developing a website.

Blog

From the blog Blog del William by William Cordor and used with permission of the author. All other rights reserved by the author.

Using Rest API in class while working with our in-class and homework assignments has helped me understand backend development in a practical way. Vaibhav Kandwal’s blog, “REST API Tutorial – REST Client, REST Service, and API Calls Explained With Code Examples” does a really good job of simplifying and giving a top-down overview of what it looks like. Throughout my semester in Software Construction, Design, and Architecture I’ve learned a lot about Rest APIs but Kandwal’s way of breaking it down has deepened my understanding further.

One of the biggest points made in the blog is that Rest APIs are built around the idea of resources. Instead of being stuffed full of complicated actions, everything instead becomes a resource that can be created, retrieves, updated, and deleted. This makes endpoints easy to understand as when you see something like /guests you know what to expect. GET gets the data, POST adds something new, PUT or PATCH updates it, and DELETE removes it. REST reduces the guesswork by having a consistent structurer to follow.

The blog also heavily emphasizes that REST APIs are stateless. I wasn’t entirely sure why this was the case at first but after reading through it makes sense now. “Statelessness: the communication should have no client context stored on server. This means each request to the server should be made with all the required data and no assumptions should be made if the server has any data from previous requests.” The reason this is so important is scaling becomes much easier. The server doesn’t have to store anything about the previous requests. This also has the added benefit of system reliability. When the server doesn’t have to keep track of any previous conversations, there are fewer opportunities for unexpected bugs. This creates a safer and well-organized approach.

This connects directly with what we’ve worked with in class. One of our more recent homework assignments was created the endpoints in the Specification.yaml file and it was easy to see how each one followed the same structure with minor differences depending on the requirements for that endpoint. We decide what our resources are, what each endpoint should do, and what kind of data each operation should accept or return. Having that structure laid out before me has increased my understanding of the backend logic and made it much easier when it finally came time to write the JavaScript.

Overall, after reading this article I have a deeper understanding or REST APIs, and I plan to take this with me into my future career. I will certainly need this knowledge next semester when I take my Software Development Capstone course but also after I graduate seeing as how I have my sights set on being a software developer.

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

https://github.blog/news-insights/octoverse/what-986-million-code-pushes-say-about-the-developer-workflow-in-2025/

For this blog, I chose to read Github’s 2025 Octoverse article, “What 986 Million Code Pushses Say About The Developer Workflow in 2025.” The article analyses nearly a billion commits from developers around the world and highlights how software development teams are adapting their workflows as the entire CS landscape continues to change and evolve. I selected this article because it felt directly related to what we’ve talked about in CS-348, particularly how processes like CI/CD shape development practices and how Agile could potentially relate to some of the points Cassidy Williams, the author, brings up about teamwork.

One of the central ideas is that “iteration is the default state.” Instead of shipping big releases occasionally, developers should instead push small parts constantly. The article explains how smaller and more frequent commits have become normal. Developers fix a bug, build a small feature, or tweak a config, and then push. These smaller, lightweight commits lead to smaller, more focused pull requests with a single purpose. The article also emphasizes that constant shipping reduces risk because smaller changes are easier to debug and rollback.

The article also argues that communication patterns need to catch up with development and workflow changes. Some of the fundamental change that Williams believes need to happen in order for communication to keep up with development include: Standups being shorter or asynchronous entirely, they state that pull requests being blocked is no longer acceptable, and hiring needs to shift towards people who ship the fastest. In William’s look-ahead at the end of the article, they mention how “AI fatigue” is real but, that in the end, the best tools will win out.

Reading this made me think pretty critically about my own habits. I have always waited to commit until I felt a feature was worth committing, until it felt “big enough.” This article helped me realize that the size of a commit is entirely arbitrary and has nothing to do with the importance of a commit. More frequent commits are better for safety and for collaboration. I also realized that I have heavily underused feature flags and often think of tests and an entirely separate act that development when in reality they should be tightly connected and done pretty much constantly. Looking forward, I want to adopt the practices mentioned in this article, lightweight commits, strong integration and deployment, and clear communication can hopefully help to bridge the gap between communication and development.

From the blog CS@Worcester – My Coding Blog by Jared Delaney and used with permission of the author. All other rights reserved by the author.

Link: https://blog.codinghorror.com/code-smells/

In the blog post “Code Smells” by Jeff Atwood, he proposes an argument that it is very important for programmers to develop a “code nose,” which essentially is the ability to sense when code is beginning to rot before those bugs even appear. Atwood goes through a long list of common smells within classes, such as long parameter lists, duplicated code, overly long methods, and giant classes that simply try to handle too many responsibilities. He also describes smells that are between classes. This includes primitive obsession, where basic types are being overused instead of proper classes, as well as data classes that only store fields but have no behaviors. He also describes feature envy, which is when one class is constantly reaching into another class’s data. His main point is that while refactoring tools and books is helpful, the real key is to learn how to notice these warning signs in your own code.

I chose this topic because I feel like I didn’t get a great understanding of code smells in class, so I felt like it would be beneficial to get a better understanding of it. This blog post was very resourceful, as it reminded me that readable and maintainable code is just as important as whether or not the code is functionable. Sometimes, I get too focused on making sure that the code just works but I don’t pay attention to the readability or maintainability aspect of it. Reading about code smells made me realize that some of these habits apply to my own work. I have definitely been guilty of data clumps before, as sometimes I pass the same group of variables through multiple functions rather than bundling them together into a class. I’ve also definitely done the long method smell before too, as sometimes I keep lumping stuff into main() rather than creating helper functions which makes it more readable and easier to maintain.

Going forward, I plan to use this list of code smells as more of a mental checklist whenever I am working on a group project or assignment. This will improve my own code by making it more readable and maintainable, but will also prove to be beneficial in a workplace environment. In my career, this will help me navigate potentially unfamiliar code bases, and will even help me leave code cleaner for my coworkers. Overall, understanding code smells will prove to be beneficial for myself as well as my potential future coworkers.

From the blog CS@Worcester – Coding Canvas by Sean Wang and used with permission of the author. All other rights reserved by the author.

I have never worked on front end development until now. My preconceived notions made me think this would be simpler like web design, but I was wrong. This is the piece that the users interact with directly. Mistakes here make the project look sloppy, reduce user satisfaction, or can make it hard to navigate. The front end is the first impression, if this leaves a bad taste, then it may lower user satisfaction.

Front end development relies on three things, html, css, and javascript. HTTPs give us the skeleton of the page. It shows where our elements like headers, images, and links go. CSS takes what we have and stylizes it. This handles things like colors and layers. This is also responsible for ensuring the front end looks good on whatever device it is ran on. And finally java script introduces dynamic behaviors. This can include dropdown menus, data fetching, animations. This pulls everything together to create a responsive UI.

There’s a lot of good front end tools to check out. Tailwind css allows you to simply learn styling patterns that work, without having to write full css files. Bootstrap is a css framework that provides pre-built ,https, javascript and css components. Apparently 19% of all websites were created with this. Css loaders give you hundreds of loading animations that you can use in your projects. Coolers are a pallet generator. This allows you to see a variety of color pallets to choose from so you can see what you link and implement into your front end. A lot of these tools seem very interesting and have gotten me more interested because they seem very simple to implement while making your project look cleaner. These tools don’t exist to replace doin the work yourself. These are in place to support the core aspects of front end development. Some of these tools will help you build a layout faster, and other tools like codepen allow you to test without having a complete project. They give the developer some simple quality of life improvements that can make the process more streamlined.

https://www.wearedevelopers.com/en/magazine/210/best-tools-for-front-end-development

https://martijnhols.nl/blog/accessibility-essentials-every-front-end-developer-should-know?

From the blog CS@Worcester – Aaron Nanos Software Blog by Aaron Nano and used with permission of the author. All other rights reserved by the author.

For this blog I chose to explore the article “REST API Design: Architectural Foundations and Modern Practices” by Nikola Lazarov. Since CS-343 focuses on software construction, modularity, and clean interfacing, I wanted to learn more about how REST APIs fit into architecture beyond the basic GET/PUT/POST/PATCH commands. Lararov’s article stood out because it connects the roots of REST with other practical API design conventions we’ve learned in 343.

Lazarov begins by grounding the discussion in the original REST constraints defined by Roy Fielding. These include ideas such as statelessness, a uniform interface, resource-based design, and layered system architecture. The article then explains how these constraints influenced real world API design today. He connects these constraints directly to the goals of scalability, simplicity, and clear separation of concerns. For example, the statelessness requirements means that each request must contain all the information the server needs, which helps a system scale because servers don’t need client-specific context. His explanation in the article helped me understand that REST is a set of architectural decisions that influence how the entire system behaves and it isn’t nearly as independent as I thought.

The article also discusses how to apply REST principles in API design. Lazarov highlights the importance of resource-oriented URLs and matching HTTP methods, GET for retrieving, POST for creating, PUT for updating, and DELETE for … deleting. He also greatly emphasizes using meaningful HTTP status codes to communicate consistently. These design choices might seem small, but that’s kind of the entire point, these choices contribute to APIs that are predictable and easier for clients and developers to understand. Rather than presenting REST as a rigid formula, Lazarov explains how these principles guide the structure of modern APIs, helping developers create interfaces that are both intuitive and aligned with broader architectural goals.

I selected this article because I believe that it directly ties into topics we’ve explored in 343. REST APIs are essentially interfaces between components of service, so understanding why they are designed the way they are is directly relevant. I also wanted a source that explains the “why” behind REST’s patterns instead of just the “how.”

What I learned most from this article is how intentional REST API design is and what it should look like. I had previously thought of endpoints of pretty arbitrary choices, but Lazarov’s explanation helped me understand that each part of an API should reflect the underlying REST principles.

From the blog CS@Worcester – My Coding Blog by Jared Delaney and used with permission of the author. All other rights reserved by the author.