The Magic Behind Frameworks

https://aws.amazon.com/what-is/framework

When learning about backend and front end architecture, we got to explore the use of frameworks. A framework is a set of reusable software components like libraries, APIs, tools, that help developers build applications more efficiently; they are the structural “skeleton” of a project. Instead of writing everything from scratch, you build on top of a framework’s building blocks and standardized patterns, letting you focus on the unique parts of your application rather than reinventing foundational pieces. This semester was my first real exposure to using a framework and I decided to explore what exactly it was and how to best use one in future projects. To build on my base level knowledge, I came across this article found on the Amazon Web Services site. 

The article explains how using a framework has several advantages like having better code quality. Since the programmer reuses parts that are typically well tested, the code is more efficient and easier to maintain. Also, having less duplication in code decreases certain code smell and leads to faster development. Having a framework can also aid in better collaborations especially when using the same architecture patterns. I remember thinking of a framework as a library, however this article explains that the difference is that frameworks define the structure and flow of your application, controlling how and when things happen, whereas libraries are just a set of helper functions you can call when needed. 

Frameworks are not just one size fits all. As an aspiring web developer, I will need to know how to utilize web development specific frameworks. For example, frameworks such as Angular, VueJS, and Bootstrap are all common frameworks that are utilized by the top tech companies. Frameworks are extremely useful in web development because they give developers a structured, efficient way to build websites and web applications without starting from scratch. A framework provides prewritten components, templates, and patterns for common tasks like routing, handling requests, managing databases, rendering pages, and securing user data. Many web frameworks include built-in security protections, performance optimizations, and ways to organize files so the project scales as it grows. There are, however, benefits to learning more than one framework especially if it helps with more full stack development. Choosing the right one for your project depends on the requirements. In the future I will need to analyze the scalability, the ecosystems or available libraries, longevity, and speed of development for my project.

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

Using immutability in conjunction with encapsulation.

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.

All About Interfaces

When learning about software design and construction, specifically in Java programming, we explored more in depth the implementation and utilization of interfaces. Before this class I had learned about what an interface was, but did not get a good understanding of how powerful it was. I chose this video by youtuber “Keep on coding” to help me understand the different ways an interface is useful and how to best utilize them in my code.

Working with interfaces in Java is essential because interfaces embody core principles of good software design. They allow developers to define behaviors abstractly, separating the “what” from the “how,” reducing complexity and improving clarity. In class we went over different design smells in code. Interfaces combat certain smells by making systems more flexible, easier to modify, and more resilient to change. Interfaces also let code depend on set intentions instead of concrete implementations. When it comes to enabling good object oriented principles, they enable substitution and polymorphism, which are central to many design patterns and architectural styles like Clean Architecture. Additionally, interfaces improve testability by allowing the use of mocks and alternative implementations. 

The video helped expand on this knowledge by walking the viewer through different tutorials that highlights the flexibility of interface implementation. The tutorial covers essential concepts such as defining and implementing interfaces, demonstrating how classes use the implements keyword to adopt an interface and are then required to provide implementations for all its methods. It also illustrates how a single class can implement multiple interfaces. A significant feature discussed is the ability to create interface reference variables, allowing a variable of an interface type to reference objects of any class that implements that interface, which enables polymorphic behavior. Additionally , the video details that variables declared within interfaces are implicitly public, static, and final. It also explains how interfaces can extend other interfaces, inheriting their methods and variables

I wanted to learn more about interfaces because I wanted to be a more proficient java coder. When you are a beginner, you often write code that is tightly tied to specific classes and implementations. I tend to use concrete classes directly, which makes my code rigid and difficult to change later. As seen in our examples of the duck classes, the less efficient architecture allows duplications of similar logic across multiple classes instead of abstracting shared behavior. In my experience I had a tendency to overuse inheritance where an interface would be a better fit.

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

Rest API Design

One of the topics we have been looking at in class have been rest APIs. Since we were working with APIs for some time I wanted to dive deeper into what they are and what makes a good one. The blog that I saw seemed perfect for this : “Everything I know about good API design” on SeanGoedecke.com.

One of the major topics that the post touched upon was that a good API design should be familiar and flexible. This mean that for developers who make them, APIs are complex products where lots of effort is put into designing them and polishing them. However, for the people who use them, the API should be familiar so that they know how to use it without lots of documentation. Even reading this makes it seem complicated. I guess I haven’t yet broken into this world of API creation. Basically, it seems like to me it would be a mix of building a simple API design but also make it be as useful as possible. Keeping it simple is not always the best solution but also making things too complicated will make things hard for the team to use.

Another Key topic the article goes over is changing APIs without breaking userspace. Basically what this is saying is that once an API is released and public, making any small change could break everything. Instead the article suggests to use versioning. I know I have working with versioning in class and looking at the different types of changes based on version numbers. For example, we used version with three different numbers as such: 2.4.0 from left to right being more breaking changes to smaller patches. Versioning is a useful way of updating APIs while also maintaining backwards compatibility. Now I really take notice in versions of applications I use and understand what kind of change has been implemented.

These aspects really helped me understand what makes a good API design. Building an API is not only making it functional but also flexible for developers and users. Being able to design APIs in two completely different ways and finding a happy medium is the key to making a good one. Also, being able to and understand versioning and how to not completely destroy your system when making changes. Going forward i hope ill be able to keep these things in mind to make thing predictable while also making the functions complex and useful.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.

Frontend and Backend

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

What’s the Difference Between Frontend vs Backend Web Development?

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

How REST API Controls Backend Flow

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.

A Billion Commits into The Future

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

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.

Reflections on Code Smells

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.

Front End Development

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.

The Definition of Done (DoD)

How to write a Definition of Done

CS-348, CS@Worcester, Week-4

Source Article: https://www.atlassian.com/agile/project-management/definition-of-done

Recently, in doing a project in class, I had to write a Definition of Done (DoD) file for my portion of the project. I had a basic understanding of what needed to be conveyed, but not exactly how to convey it. I wanted to know more. I looked further into what the industry standard is, and that’s how I came across this post, which I used to help me figure out the one for my project.

I recall from the previous class activity that we looked at the Scrum Guide by Ken Schwaber and Jeff Sutherland, and the guide did give information on what the Definition of Done was and what it is meant to convey, but I wanted something more in-depth.

According to the article, the Definition of Done is a shared set of criteria that tells a Scrum team when a product increment is truly complete. The specifications contained are not created by one person but agreed upon by the entire team because there needs to be a shared understanding of what’s expected at the end of each sprint and for the project overall. This is needed to avoid miscommunication and make sure the team adheres to the pillars of Scrum: transparency, inspection, and adaptation. The developers of the team have the responsibility of parsing out what the DoD will be continuously as it will evolve and change as increments pass.

I knew that whatever was agreed upon needed to be something that is measurable and testable, otherwise there would never be a satisfying way to declare being done. But the article mentioned something about the DoD needing to also be “ready to ship”. This means that there can be no hidden work left after the spring, and there can’t be extra polishing stages.

The most helpful portions of the article were the examples that were provided of what can be included in a DoD. Here are some of them./

  • Increment Passes SonarCube checks with no Critical errors
  • Increment’s Code Coverage stays the same or gets higher
  • Increment meets agreed engineering standards
  • Acceptance Criteria for Increment pass
  • Acceptance Tests for Increment are Automated

Most of the examples include the project passing specific tests or meeting certain standards that would be either required by the client or the organization the team is working for, which is par for the course. The DoD is an important part of Scrum, and I need to understand how to think of a project in order to write one in future cases.

From the blog CS@Worcester – A Beginner's Journey Through Computer Science by Christiana Serwaah and used with permission of the author. All other rights reserved by the author.