Category Archives: CS@Worcester

FRONT/BACK ENDs

The blog entry “Front-End vs. Back-End Explained by Waiting Tables at a Restaurant” breaks down the differences between front-end and back-end development in a straightforward, humorous, and visually appealing manner using an everyday scenario. The front-end is likened by the author to a waiter in a restaurant, who deals directly with customers and is in charge of communication, presentation, and ensuring that they receive what they want. The back end is compared to the kitchen, where the actual cuisine is prepared by the chefs (or servers, databases, and business logic). Although the kitchen is not visible to patrons, the restaurant cannot operate without it. The article also describes how APIs function similarly to a menu, outlining exactly what can be requested and how the restaurant would react. For novice engineers, this example helps make difficult technical concepts more understandable.

I picked this article because it directly relates to the concepts we have been covering in class, the transition from monoliths to client-server and ultimately microservices. We witnessed firsthand how the front-end and back-end communicate through well-defined paths in our Microservices Architecture exercise. For example, the StaffBrowser or AdminBrowser interfaces with the GuestInfoBackend, InventoryBackend, or ReportingBackend. Each backend service mimics the kitchen/waiter structure outlined in the article by processing data and returning results to the browser. The article’s description of how requests go through the system is consistent with even the API endpoints we looked at, such as CheckInGuestFrontend or the Express.js servers that power each system. Knowing this example made it easier to understand why our class project is divided into several components and why there needs to be exact communication between them.

As I thought about the post, I saw how crucial it is that both front-end and back-end engineers comprehend their responsibilities and the connections between the systems. Separating responsibilities makes systems easier to maintain, scale, and debug, as we discovered when we compared the monolith versus microservices models in class. The essay reinforced the point by demonstrating how, similar to a restaurant, uncertainty at the front-end or back-end results in delayed service, mistakes, and disgruntled customers, in this case, users. I was also reminded of the importance of APIs. We were effectively looking at the menu that specifies exactly what the front-end can request and how the server will reply when we examined the OpenAPI definitions and backend endpoints in our code. I want to use this example going forward whenever I create or work with APIs. It will be easier for me to organize cleaner services and interact with coworkers if I know what belongs in the “kitchen” and what belongs in the dining room. I want to focus more on how front-end requests move through the various back-end systems and how each service does its function on its own as we continue to work with microservices.

Front End v. Back End Explained by Waiting Tables At A Restaurant

From the blog CS@Worcester – A Bostonians Blogs by Abdulhafeedh Sotunbo and used with permission of the author. All other rights reserved by the author.

A quick look at front-end

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.

A quick look at front-end

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.

A quick look at front-end

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.

A quick look at front-end

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.

Correctly applying the Open Closed Principle

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.

Teamwork and Project Management

https://www.geeksforgeeks.org/software-engineering/software-engineering-software-project-management-spm/

When learning about the entire software building process and an Agile framework, we learned about a better and more efficient way of developing a project as a team. The overarching theme for having a well maintained project that stays its course is having a good software project management system in place. It is important because software is intangible, making it difficult to visualize progress or quality without strict oversight.This article from GeeksforGeeks discusses Software Project Management, a discipline within software engineering focused on planning, implementing, monitoring, and controlling software projects. The goal is to deliver high-quality software on time and within budget by effectively managing resources, risks, and changes.

The practice encompasses several critical aspects, starting with detailed planning to outline scope and resources, followed by the active leading of diverse technical teams. Managers must oversee execution through rigorous time and budget management while also handling maintenance to address defects early. To achieve this, project management employs specialized management strategies, including risk management to minimize threats, conflict management to resolve team disputes, and change management to handle shifting goals. It also involves technical controls like configuration management to track code versions and release management to oversee deployments. Some drawbacks are touched on being that the process can add complexity and significant communication overhead especially with large teams. 

I think it’s important to understand the different aspects of project management and what goes into creating a project as a team.Working as a team is critical in software engineering because modern projects are often too complex and massive for any single individual to handle efficiently. By dividing tasks, teams can work in parallel, allowing features to be built, tested, and deployed simultaneously which significantly speeds up the development process. Beyond just speed, teamwork improves code quality through practices like peer reviews and pair programming, where “multiple eyes” on the code help catch errors that a solitary developer might miss. It can be easy as a student to think that getting in this field will mean sitting behind a desk and working on your own aspect of a project, however, working within a team and adhering to the group structure and work flow management can be a shock to people new to not just the software field but to the workforce in general. When working in a large team it can be easy to stray from the  goal or specifications without strict planning and oversight. Software project management provides the necessary framework to navigate this, ensuring that unique client requirements are met precisely rather than relying on assumptions. 

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

Understanding Technical Debt: Why It Actually Matters More Than We Think

When I first heard the phrase “technical debt,” I honestly thought it was just a fancy developer way of saying “bad code.” But after reading Atlassian’s article “Technical Debt: What It Is and How to Manage It,” I realized it’s way deeper than that. The article explains technical debt as the cost of choosing a quick solution now instead of a cleaner, long-term one. This can come from rushing to meet deadlines, adding features without proper planning, skipping tests, or even just writing code before fully understanding the problem. What I liked about this resource is that it breaks the topic down in a way that makes sense, showing how debt doesn’t always come from laziness, sometimes it’s just the reality of working in fast-paced software development.

I picked this article because technical debt is something we’ve basically been talking about throughout CS-348, even if we didn’t always call it that. Whether it’s writing maintainable code, designing clean architecture, or keeping up with version control, everything connects back to avoiding unnecessary debt. I’ve heard instructors and even classmates say, “We’ll fix that later,” and this article made me understand the impact behind that mindset. It stood out to me because it not only defined the problem but walked through how teams can recognize debt early and avoid letting it build up until it becomes overwhelming.

Reading this article made me realize how much technical debt affects the entire development process, not just the code. It slows teams down, creates frustration, and makes simple tasks more complicated than they should be. One part that hit me was how the article described debt snowballing over time. It reminded me of school assignments: if you ignore a confusing part early on, it always comes back to make the whole project harder. Another point I loved was the idea of being honest about debt instead of acting like it doesn’t exist. Communication is a big deal in development, and the article made that very clear.

Moving forward, I’m definitely going to be more intentional about how I write and manage code. Instead of rushing through things just to “get it done,” I want to slow down and think about how my decisions today could affect future work, both for me and for anyone else who touches the code. Good documentation, regular refactoring, testing early, and asking questions when something feels off are all habits I want to bring into my future career. Understanding technical debt helped me see software development as a long game, and being aware of these trade-offs will help me build better, cleaner projects in the future.

Source:

https://www.atlassian.com/agile/software-development/technical-debt

From the blog CS@Worcester – Circuit Star | Tech & Business Insights by Queenstar Kyere Gyamfi and used with permission of the author. All other rights reserved by the author.

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.