In software development, code smells are subtle yet significant indicators of potential problems within a codebase. Much like how an unpleasant odor hints at deeper issues, code smells signal areas in the code that might lead to bigger challenges if left unaddressed. The article linked below is exploration of this concept, highlighting the importance of […]

From the blog CS@Worcester – CurrentlyCompiling by currentlycompiling and used with permission of the author. All other rights reserved by the author.

A key aspect of frontend development is creating websites that perform well and provide a seamless user experience. However, due to time constraints in class, we didn’t have many opportunities to dive deeply into frontend implementation techniques. To fill this gap, I explored the blog “Frontend Development Best Practices: Boost Your Website’s Performance“. It’s clear explanations, organized structure, and bold highlights made it an excellent resource for enhancing my understanding of this crucial topic.

The blog provides a detailed guide on optimizing website performance using effective frontend development techniques. Key recommendations include using appropriate image formats like JPEG for photos, compressing files with tools like TinyPNG, and utilizing lazy loading to improve speed and save bandwidth. It stresses reducing HTTP requests by combining CSS and JavaScript files and using CSS sprites to streamline server interactions and boost loading speed. Another important strategy is enabling browser caching, which allows browsers to locally store static assets, reducing redundant data transfers and improving load times. The blog also suggests optimizing CSS and JavaScript by making files smaller, loading non-essential scripts only when needed, and using critical CSS to improve initial rendering speed. Additional practices include leveraging content delivery networks (CDNs) to deliver files from servers closer to users and employing responsive design principles, such as flexible layouts and mobile-first approaches, to create adaptable websites.

I chose this blog because it addresses frontend implementation topics that were not deeply explored in our course. Its organized layout, with bold headings and step-by-step instructions, makes the content accessible and actionable. As someone who plans to build a website in the future, I found its advice easy to understand.

Reading this blog was incredibly insightful. I learned how even small adjustments—such as choosing the right image format or enabling lazy loading—can significantly improve website performance. For example, understanding browser caching taught me how to make websites load faster and enhance the experience for returning users. The section on responsive web design stood out, emphasizing the importance of creating layouts that work seamlessly across different devices. The blog’s focus on performance monitoring and continuous optimization also aligned with best practices for maintaining high-performing websites. Tools like Google PageSpeed Insights and A/B testing offer valuable feedback to help keep websites efficient and user-focused over time.

In my future web development projects, I plan to implement the best practices outlined in the blog. This includes using image compression tools and lazy loading to improve loading times, combining and minifying CSS and JavaScript files to reduce HTTP requests, and utilizing CDNs alongside browser caching for faster delivery of static assets. I will also adopt a mobile-first approach to ensure websites function smoothly across all devices.

This blog has provided invaluable insights into frontend development, equipping me with practical strategies to optimize website performance. By applying these techniques, I aim to create websites that not only look appealing but also deliver an exceptional user experience.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

YAGNI – You aren’t going to need it. In the simplest terms, the principle (initially created by Ron Jefferies) means don’t overengineer before it is necessary. It means to find the solution that works for what is needed today without engineering for POTENTIAL future scenarios. Outside of software engineering, this principle is applicable to everyday […]

From the blog CS@Worcester – CurrentlyCompiling by currentlycompiling and used with permission of the author. All other rights reserved by the author.

Introduction

APIs are the most important piece of communication between software applications. REST APIs, in particular, have emerged as the standard for building web services due to their simplicity and scalability. This blog by John Au-Yeung explores best practices for efficient REST APIs, a topic that is essential for modern software development.

Summary Of The Source

1. Accept and Respond with JSON: JSON is the standard format for APIs due to its readability and compatibility with most programming languages.
2. Use Nouns Instead of Verbs in Endpoint Paths: Resources should be represented as nouns in endpoint paths, such as /users or /orders, for clarity and consistency.
3. Handle Errors Gracefully and Return Standard Error Codes: APIs should provide clear error messages and use appropriate status codes, like 404 for not found or 500 for server errors.
4. Maintain Good Security Practices: Implement authentication methods such as OAuth, encrypt sensitive data, and use rate limiting to prevent abuse.
5. Versioning Our APIs: Proper versioning, such as including the version in the URL (/v1/users), allows APIs to evolve without disrupting existing integrations.

Why I Chose This Blog

I selected this blog because REST APIs are integral to modern software development, and understanding their design is essential for building scalable and maintainable systems. The blog provides a good understanding of REST APIs for developers at all levels.

Reflection On The Blog

The blog went over the standards when designing REST APIs. One aspect that resonated with me was the emphasis on clarity and simplicity in API structure. For instance, using nouns like /users instead of verbs like /getUsers for endpoint paths. Another valuable takeaway was the focus on error handling and standard status codes. Before reading this, I hadn’t fully appreciated how critical it is to provide meaningful error responses to help developers debug issues. I now recognize how returning clear messages and consistent codes can improve the user experience and reduce confusion for developers. The section on API versioning was also particularly insightful, as I hadn’t previously considered how unversioned APIs could lead to breaking changes when updates are made. This made me realize the importance of planning for future iterations during the initial API design process.

Future Application

By adopting JSON as the default format and carefully designing resource-based endpoints, I aim to create APIs that are in line with all that standards laid out in this blog. I will also make sure to maintain good security practices, such as implementing authentication. Additionally, I will incorporate API versioning to ensure compatibility with older clients as updates are introduced.

Citation

Best practices for REST API design by John Au-Yeung

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

If you’re studying or working with Rest APIs, the chances of you running into endpoints are extremely high. I struggled a bit to wrap my head around them, so here’s a casual breakdown. It’s not as scary as it sounds.

What Are API Endpoints?

Let’s start with the basics. An API (Application Programming Interface) is like a menu at a restaurant(HOW MANY TIMES MUST I SAY THIS?). It tells you what’s available (services or data) and how to ask for it (requests). Endpoints are specific URLs on that menu where you go to get what you need.

Imagine you’re at a pizza place. You want to order a pizza with extra cheese and pepperoni. The endpoint is like the part of the menu that says, “Build Your Own Pizza.” It’s where your request (extra cheese, pepperoni) is processed and sent to the kitchen (server), and then your pizza (data) comes back to you.

In tech terms, an endpoint is a specific location on a server where an app interacts with the API to get or send information. For example:

https://api.pizzaplace.com/orders

Here, /orders is the endpoint where you place or check your pizza order.

How Do They Work?

Endpoints use URLs and HTTP methods to define what action you’re taking. These methods are the “verbs” of APIs:

• GET: Asking, “What’s on the menu?” You’re retrieving information.
• POST: Placing your pizza order. You’re creating something new.
• PUT or PATCH: Updating your order, like adding mushrooms.
• DELETE: Canceling your order. Sad day.

When your request hits the endpoint, the server processes it and sends back a response, often in JSON (an easy-to-read data format).

Why Do They Matter?

Endpoints make modern apps and websites possible. For instance, when you check Instagram, there’s an API endpoint fetching your posts. When you order on Amazon, there’s an endpoint processing your purchase. They’re everywhere!

Endpoints keep things organized. Instead of exposing a server’s entire functionality, APIs provide specific endpoints for specific actions. It’s like keeping the kitchen off-limits in a restaurant—you just see the front counter.

Real-World Example

Let’s say you’re building a library app. You might have API endpoints like these:

• GET /books: Retrieve a list of all books.
• GET /books/42: Get details about book #42.
• POST /books: Add a new book.
• DELETE /books/42: Remove book #42.

Each endpoint serves a purpose, and together they make the app functional.

Wrapping It Up

API endpoints are the way apps and servers talk to each other. They’re like doorways leading to the data and services you need. Understanding endpoints is crucial because they’re the foundation of so much of what we build. Whether you’re connecting a frontend to a backend or building your own API, endpoints are the unsung heroes of the digital world.

Next time someone mentions an “endpoint,” you’ll know it’s just a fancy name for a digital doorway.

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

I chose the blog post, “Best Practices for REST API Design” by John Au-Yeung because it addresses the best practices developers should be following when it comes to utilizing REST API. The blog shows us strategies that we can use so we can create items to the best of our abilities. In class, we have been using the REST API since Thea’s Pantry utilizes it. Due to this, while we have been learning a lot about it due to classwork and homework, it was interesting to be able to read other perspectives such as this blog. This is really our first introduction in our computer science classes on design like this so the more we can read and learn the better.

In the blog, the author focuses on creating user-friendly APIs that adhere to widely accepted principles. The foundation of REST API design is using nouns in endpoints to represent resources, such as /users or /orders, rather than actions like /getUser. This approach keeps the API intuitive and aligns with REST conventions. HTTP methods play a vital role, with verbs like GET , POST , PUT , and DELETE defining the operations on these endpoints. The principle of statelessness is key to this design, meaning each request from a client must contain all the necessary information for the server to fulfill it. This avoids maintaining client-specific state on the server, simplifying scaling and debugging. Error handling is another essential practice. APIs should return meaningful and consistent HTTP status codes, such as 404 for “not found” or 400 for “bad request,” paired with descriptive error messages to guide users on fixing issues. For managing large datasets, pagination, filtering, and sorting should be supported. These features enhance performance by limiting the data returned and allowing clients to specify exactly what they need. APIs should adopt JSON as the standard response format, as it’s widely used and easy to parse. Including appropriate content-type headers ensures compatibility across platforms. These practices foster better user experiences, maintainability, and scalability. By following them, developers can create APIs that are reliable, predictable, and efficient, promoting successful integrations across diverse client applications.

From the blog, I was able to learn the best practices when it comes to designing using REST API. Going forward, I plan to incorporate these practices as I continue to learn more about front end work. After reading, I feel like I will be able to increase my learning in this area as well as be able to share these practices with my peers.

https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

Within object oriented programming, there are four main pillars. These are known as abstraction, encapsulation, polymorphism, and inheritance. These four are essential in understanding object oriented programming and why it is important. While researching, I found a blog called “Encapsulation, Abstraction, Inheritance, and Polymorphism” by Cole Davis which I believe does a great job at explaining all four of the pillars as well as why they are important. I chose to write about this topic as I use object oriented programming all the time, and I plan to do it in the future. Because of this, I wanted to help share some information that I find to be very useful in understanding how it works in case anyone else wants to do the same.

Abstraction: One of the first major pillars you’ll learn about is known as abstraction. Cole Davis does a great job at explaining this pillar, as shown in a quote from his blog: “Abstraction is the process of combining many functions into one. Think of a thermostat. Typically, a thermostat allows the user to change the target temperature, select different modes such as heating, cooling, or fan, and turn the unit on or off. When we use a thermostat, we are unaware of the intricacies that create these functionalities under the hood. By exposing only the necessary abstracted functions to the user, we make it easier for the user to use our programs.” I really enjoyed reading this example as it relates abstraction to real-life terms instead of just using coding terms, making it a lot easier to understand. Essentially, abstraction does the same thing. It makes our code easier to understand, allowing others to get a high-level understanding of our program.

Encapsulation: The second main pillar is known as encapsulation. Encapsulation is the idea of hiding and restricting access to the implementation details of our objects. Basically, this protects the data and functions of our code from being improperly accessed by things other than our objects. It makes our code more robust and predictable, allowing others to see its purpose more clearly. Another major benefit of encapsulation is it allows us to see precisely where we can change implementation details, allowing us to safely change our program.

Inheritance: The third main pillar is known as inheritance. According to the blog “Inheritance is a technique that involves a child class “inheriting” functionality from a parent or super class.” This increases usability in our code as well as stops it from being redundant.

Polymorphism: The four main pillar is known as polymorphism. Polymorphism is a hard one to explain, but its very easy to show. Essentially, it is when child classes run the same inherited method that returns different values. They use the same method, but can return different values based on what they do. Polymorphism allows us to have a more dynamic inheritance, which enables us to use inheritance more for its values that it provides.

Link: https://medium.com/@colebuildanddevelop/encapsulation-abstraction-inheritance-and-polymorphism-26aa98042d41

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.