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.

In building software, it’s easy to focus on writing code, making features, and getting things working. But real, maintainable systems require more, they require thoughtful architecture. In the article “Five Architectural Principles” posted in the Criteo Engineering blog on Medium, Peter Milne lays out five foundational principles that, in his experience, guide sustainable and scalable software systems. The article is short but it outlines an architectural mindset that feels especially relevant.

Milne begins by outlining five principles he believes lead to more maintainable systems, grounding each one in how teams can better structure software over time. He doesn’t claim that implementation is unimportant, but he does consistently direct attention towards fundamental architectural choices. That emphasis made me reflect on how many of my past projects became unmanageable messes simply because I was focused on writing code rather than the structure supporting it.

One of the principles that Milne discuss is the important of designing components around well-defined responsibilities. He explains that keeping components focused on a single purpose helps reduce unnecessary complexity as systems evolve. His explanation made the idea more concrete for me, especially because it aligns with some of what we’ve learned in class about separation of concerns and the value of components that can change independently.

Milne also emphasizes the importance of clear contacts, the rules or interfaces that describe how parts of a system should interface. He presents contracts as a way to maintain stability, even when internal implementation details change. His explanation made me think about much smoother some of my past group projects would have been if interfaces had been clearly defined from the beginning.

Milne also makes it clear that architectural decisions should be intentional rather than accidental. He doesn’t prescribe strict formulas, but he encourages thoughtful design so that systems can evolve without becoming overly complicated. That perspective resonated pretty heavily with me because it connected to an overarching theme that’s been prevalent throughout 343: the choices we make early on influence how well a system can adapt in the future.

Reading this helped me rethink the way I want to approach future projects. Instead of immediately writing code, I want to start by defining boundaries, identifying responsibilities, and agreeing on interfaces. Architecture is meant to support the system, not struggle to keep up with it. Even though Milne’s article is fairly brief and pretty corporate, it made me realize the value of the invisible structure supporting the visible behavior of software.

https://medium.com/criteo-engineering/five-architectural-principles-d32dc2bfefae

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.

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.

Frontend development is an essential part of building any website or just an application. It is the part of web development responsible for what the users see and interact with the user interface  and user experience of a website or application. The author explains that the frontend is built using technologies like HTML, CSS, and JavaScript. HTML is the backbone of any webpage because it provides structure and organization with defining things like headings, images, paragraphs, and links. CSS works with HTML by controlling the visual representation of the page and allows developers to customize colors, fonts, and layouts. Meanwhile JavaScript adds interactivity, handling user input, and dynamic behaviors to the page. These all work together The article also outlines typical tools and practices used by frontend developers like code editors, local development servers , version control systems, package managers, and build tools. In addition, it talks about styling techniques, making content responsive, adding interactivity via DOM manipulation and event handling, and using frontend frameworks or libraries to streamline development. Overall the article supports advancing your frontend development skills and makes it much simpler going in as a beginner who doesn’t know much about it beforehand.

The reason I chose this article is because in our class we have used the backend code for Maria’s Pantry many times, but we had never really used the frontend until the very end of the semester. Since we didn’t have as much time to go over it I also found myself very confused at times as to what was the major difference and how important is it really. I mainly just wanted to do my own research and read about it since I felt it would be something extremely important to know as much as possible to any developer.

After reading the blog post I started to realize how important HTML, CSS, and Javascript were to frontend development. They hold up and give structure to the webpage. This post also names some courses you may take to practice frontend development like udemy, coursera, and codecademy that cover most of the basics behind HTML, CSS, and Javascript. I plan to look up on them and try to practice as much as I can cause I would like to work on my skills as much as possible as I believe that it would be valuable to any sort of career I may look forward to in web development.

https://namtheartist95.medium.com/what-is-frontend-development-5fdfdd892464

From the blog Thanas CS343 Blog by tlara1f9a6bfb54 and used with permission of the author. All other rights reserved by the author.

OpenAPI and Swagger are huge tools that software developers use every day. It is extremely important to use when it comes to building clear, maintainable, and interactive API documentation. The name of the article I chose was “How to improve API documentation with Swagger and OpenAPI”. According to this article, APIs are central to modern software design, and their documentation plays a critical role in ensuring that developers can consume them and maintain them correctly. “Using the OpenAPI Specification with the Swagger ecosystem offers the much-needed standardization to REST API documentation”. Besides, it explains that the OpenAPI Specification is human- and machine-readable, it clearly states the structure of the API, its endpoints, parameters, responses, and data models. This in turn helps reduce ambiguity, which often results from loosely documented APIs.

Besides these, there are several tools that come with Swagger, including the editor, UI, codegen, and inspector. It allows developers to design and edit OpenAPI definitions in JSON or YAML with built-in validation so syntax errors can be caught right there and then. The UI presents OpenAPI definitions as documentation that users can try API endpoints from within their web browser. Codegen produces client libraries, server stubs, and SDKs that facilitate rapid development on multiple platforms. Finally, the inspector is a tool for testing APIs directly and generating an OpenAPI definition based on existing APIs.

There’s also an updated version, allowing for more modularity and an approach to defining the surface area of an API, with the official release of OpenAPI 3.0. This provides even greater flexibility in describing the request and response model of an API. Good schema and component reuse are emphasized in the most recent version, and handling of multipart documents. Advertisements.The reason I chose this topic was because we have been doing a lot of work with swagger and APIs, and I wanted to look closely into how vital it is to be a software developer in the real world. I also wanted to look closer into how swagger can improve my design skills. After reading this article, I started to see why proper documentation isn’t just something nice and handy but a necessity in being a skilled developer. From now on, I plan to strengthen my understanding of swagger and APIs because I think it will also help me in improving my coding skills and future project.

Resources: https://www.techtarget.com/searchapparchitecture/tip/How-to-improve-API-documentation-with-Swagger-and-OpenAPI

From the blog Maria Delia by Maria Delia and used with permission of the author. All other rights reserved by the author.

Hello everyone,

This will be my last blog of the semester and being the last one, I wanted to do something fun. When we went over Design Patterns in class, I was really amazed and I saw myself going back and thinking about it. I was even surprised to see that I had not written a blog about it. I wanted to do a little digging and wanted to talk in this week’s blog about a new Design Patterns that we didn’t cover in class, and the one I am going to talk about is “…drum rolls please…” Adapter Pattern!!!!

The idea behind it is pretty simple and as you can guess it comes from the name, and its general idea of it in software development is identical to the one in the physical world. When you travel abroad and want to charge your phone or laptop but the power outlet has a different shape from what you are used to seeing back home. In a different scenario, you are going to connect your old console to your new TV, but the plugs and outlet are not compatible so what do you do? In both of these cases you are going to use an adapter which allows you to use your own plugs in scenarios where you normally were not able to.The Adapter Pattern has the same principle but it is applied in object-oriented programming. A prime example of when this is used is when you already have a class and want to reuse in a different interface and rather than creating a whole new class just for that specific interface, youuse the Adapter Pattern. You then implement a class that bridges the gap between an expected interface and an existing class. That enables you to reuse an existing class that doesn’t implement a required interface and to use the functionality of multiple classes, that would otherwise be incompatible.The biggest advantage of the Adapter Pattern is that you don’t need to change the existing class or interface. By introducing a new class, which acts as an adapter between the interface and the class, you avoid any changes to the existing code. That limits the scope of your changes to your software component and avoids any changes and side-effects in other components or applications. This will save you a lot of time, effort, and a lot of headaches.

In conclusion be smart like your Adapter Pattern that you will be using, and make the ability to show your work and project to any interface without being held back from interface compatibility

Source: https://medium.com/@akshatsharma0610/adapter-design-pattern-in-java-fa20d6df25b8

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