Development Environments

For this blog, I decided to do some research about development environments. When looking for sources to reference, I came across the article: “Comparison of Development Environments” on Coder’s blog. This blog post goes from simple development environments to more complicated ones.

The article starts off by going into depth about what development environments are. Integrated development environments or IDEs are the center of where developers navigate and edit code. However, the IDE are just one of the components in the development environment. There are the build tools, package managers, system dependencies, and configurations. There are also many development environment architectures as well.

  • Pure local environments: used for single developers or small development teams since it is purely local. Low cost since everything is stored locally
  • Virtual Desktop Infrastructures: the development environment is on a separate remote virtual desktop. Allows better storage across bigger teams and saving in a separate place.
  • Dev Containers: The development environment is packaged into a container . Provides a way to precisely specify the development environment once so everyone can have the same versions and controls on launch every time. I know in class we were able to build our own dev containers and such to match java version and java compiler version.
  • Cloud Development Environment: dedicates, manages, and monitors dev environments.

This blog really helped me to better dive into the deeper areas of development environments. Often when it comes to where code is stored and not just writing it, I get lost and tend to get confused. Seeing the images the article used helped to show what does what and where things are held. Also, as with most things, there are pro and cons to the usages of these environments. An example being Pure local environments being used for single developers or small development teams since it is purely local. This is good because it is low cost but it is hard to work in big development teams since everything is stored locally.

I haven’t had much experience with using different environments and instead have mostly focus on coding itself, but knowing these aspects is crucial when working on projects and software. Knowing to use cloud development environments for big groups and setting up dev containers is very important in proper workflow and to make sure everyone in the team is on the same page. I hope to understand these things pushing forward into my career.

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.

Version Control

https://www.geeksforgeeks.org/git/version-control-systems/

In our class, we spent a lot of time exploring Git and the power of version control systems. A Version Control System (VCS) is an essential software tool designed to track and manage changes to source code over time. Its primary function is to maintain a detailed history of a project, allowing developers to record every update, collaborate effectively without overwriting each other’s work, and revert to previous versions if necessary.This article from GeeksforGeeks provides a comprehensive overview of VCS’s in general, explaining what they are, the different types available, and the most popular ones used today.

The article explains how VCS’s come in 3 different forms: Local, Centralized, and Distributed. Local Version Control Systems operate strictly on a single computer, making them suitable only for individual use, though they carry a high risk of data loss if that machine fails. Centralized Version Control Systems solve the collaboration problem by using a single server to store all files and history; however, this creates a single point of failure where server downtime stops all work. Distributed Version Control Systems address this vulnerability by allowing every developer to mirror the entire repository locally. This means that if the server goes down, any client’s repository can be used to restore it, and most operations, such as committing changes, can be done offline before pushing them to a shared server.

Git is a distributed version control system used to track changes in files, especially source code, during software development. This means developers can work offline, make changes, create branches, and experiment without affecting the main project until they are ready to share their updates. Git also provides tools for merging changes from multiple contributors, resolving conflicts, and keeping a clear history of who made each change and why.

Learning Git has been beneficial to me as a new programmer because I can now host, share and update my code in a structured and maintainable manner. Utilizing online platforms that work with Git helps with contributing work to other projects as well as people contributing to mine. I remember in previous classes where we had to work on group coding projects, it was difficult to update and maintain our code as a cohesive unit. We would find ourselves emailing snippets of code back and forth in order to implement new changes. With the knowledge of git and gitlab/github, in future projects I will resort to creating project repositories that can be simultaneously updated and changed while keeping track of all edits and fixes. Also, since these online platforms are widely used and accepted in the programming field, I will have a place to host all personal projects that will build my portfolio for future employers to access. They will be able to see my progress and changes I have made on certain projects so they can see my improvement as a programmer.

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

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.