Category Archives: CS-343

Blog Post Title: Exploring the World of REST APIs: A Journey Through Modern Web Development

In the realm of computer science and web development, understanding the intricacies of Application Programming Interfaces (APIs) is indispensable. My recent exploration into this subject led me to an enlightening IBM article about REST APIs, a cornerstone of modern web services and architecture. This article, fittingly titled “What is a REST API?” (IBM Article Link), delves into the principles and practices of RESTful APIs, offering a comprehensive overview that resonates deeply with our course material.

Selecting this resource was a no-brainer for me. The blend of theoretical concepts and practical applications it offers aligns perfectly with our current coursework on web development and API integration. The article’s clear delineation of REST API characteristics, alongside examples of their use in microservices architecture, provided a solid foundation for understanding their role in contemporary web development.

The six foundational principles of REST APIs, as elucidated in the article, were particularly enlightening. They include uniform interface, client-server decoupling, statelessness, cacheability, layered system architecture, and code on demand. Each principle contributes to the overall functionality and efficiency of web services, emphasizing the importance of a well-structured API.

What struck me most was the concept of statelessness in REST APIs. The idea that each request from a client to a server must contain all the information needed for the server to respond, without relying on any stored context, highlighted the need for efficient data management and transfer in web applications. This insight has reshaped my understanding of client-server interactions and will undoubtedly influence my future projects.

Furthermore, the article’s discussion on the importance of security in REST APIs, such as using OAuth 2.0 for authorization and HTTPS for secure data transmission, was particularly relevant. It underscored the critical nature of protecting data and maintaining user privacy, aspects I intend to prioritize in my future work.

In summary, this IBM article not only broadened my knowledge of REST APIs but also reinforced the importance of secure, efficient web development practices. The principles of RESTful design will be an integral part of my toolkit as I progress in my computer science career. I strongly recommend this resource to my peers for its clarity, depth, and relevance to our course.

As I continue my journey in computer science at Worcester, I am excited to apply these concepts in practical scenarios, especially in web development projects. This article has been a stepping stone in my understanding of how web technologies work in harmony to create seamless user experiences and secure, efficient web services.

Citation: “What is a REST API?” IBM. https://www.ibm.com/topics/rest-apis

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

CS343 – Week 9

Front-end development is focused on the user experience with the site. They design the elements of the application that the user interacts with and ensures that the interface is fast and easy to use. As technology continues to grow with different devices with varying screen sizes, a challenge that has arisen for front-end development is the accommodation for the different screen sizes that want to access the same site or application. There are different programming languages for front-end development, including HTML, CSS, and JavaScript. HTML (HyperText Markup Language) allows browsers to display text or load elements, rendering webpages for users. CSS (Cascading Style Sheets) is the standard language to identify how HTML content will be displayed, such as fonts, foreground and background colors. JavaScript (JS) extends the functionality of websites beyond HTML and CSS. This gives websites the ability to refresh themselves dynamically and respond to user actions without page reloads. You can also model UI components like pop-ups and interactive sliders.

While the front-end interface draws a lot of attention to the general audience due to the visual interaction with it, the back-end forms the backbone of any online program. It includes the logic, data storage, and security features required to create a fully functional and reliable application. It is also responsible for processing client requests, interacting with databases, and generating responses to be delivered back to the client. There are several different responses that can be generated depending on the quality of the request. Examples of some responses include 200, 201, 400, 404, and 500. 200 OK indicates the request was successful and returns the requested data. 201 Created indicates another successful request but creates a new resource rather than displaying an existing one. 400 Bad Request indicates the server could not understand the request due to malformed syntax. 404 Not Found is a different type of client error response which indicates the requested resource could not be found. 500 Internal Server Error indicates the server encountered an unexpected condition which prevented a successful request.

The use of databases is important when it comes to designing the back end for several reasons. Data persistence is a positive outcome from databases and ensures that information is not lost when an application is closed or is restarting. It also allows for better data management and efficient mechanisms for inserting, updating, deleting, and retrieving information. Concurrency control is allowed through the use of databases, meaning multiple users or applications can access and modify data simultaneously.

Front-End Development: The Complete Guide (cloudinary.com)

Back-End Web Architecture | AppMaster

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

The DRY Principle

One of many important programming principles is what is called ‘Don’t Repeat Yourself’ or ‘DRY’.

The DRY principle focuses on reducing the number of unnecessary repetitions in code. This goal can be achieved through multiple methods detailed in Tahmeed Tarek’s article Understanding the DRY Principle — the three most common being:

  1. Abstraction
  2. Automation
  3. Normalization

Abstraction is often used in Object-Oriented Programming. The strategy is to create a super-class containing the necessary attributes and methods which each class can then inherit. This reduces the number of times common attributes and methods have to be defined.

Automation focuses on communication within the team and between teams working on a project. Cross-functionality between team members and different teams is vital as it gives everyone an opportunity to discuss mutual problems and thereby capable of formulating a mutual solution.

Normalization is often used in designing databases to prevent the occurrence of redundant data. It works by “extracting duplicates into a separate entity” (Tarek), ensuring that the data is consistent and properly distributed so the data’s integrity is maintained at a single source and the database is flexible and scalable.

In addition to the three methods, there are some important things to keep in mind to practice the DRY principle.

The first is to design code that is easy to reuse. This includes elements of clean code such as abstraction and documentation. Code that is simple and easy to read and understand is also easier to reuse. Sometimes, however, this process can be long and tedious, which bring up the next point to keep in mind.

The second is that shortcuts make for long delays. While they may save time in the present, shortcuts introduce what is called ‘technical debt’ which causes problems later in the future. Failing to discover and resolve technical debt early on can be a costly mistake for a project.

The third is to focus on active communication and project awareness. I have personal experience with this point relating to my research project. While still a learning intern, I found myself focusing in on the singular task assigned to me and failing to see the project in its wider scope. This became a problem because I did not think to write my code in a reusable manner for later steps in the project, creating areas of unnecessary redundancy that led to an accumulation of technical debt.

While not a seriously costly mistake — thanks to my advisor — I still had to go back and redesign my code to remove the redundancies. From then on, I learned to apply the DRY principle to my code to prevent the same scenario from happening again.

As I learned from my personal experience, the DRY method is an important principle that guides programmers to develop code that reusable and scalable, making life a lot easier.

Source: https://www.plutora.com/blog/understanding-the-dry-dont-repeat-yourself-principle

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

GRASP (General Responsibility Assignment Software Patterns) in Software Engineering (Week-9)

In the realm of software development, particularly object-oriented design, GRASP (General Responsibility Assignment Software Patterns) plays a pivotal role in shaping efficient and maintainable software. This set of principles, first introduced by Craig Larman in his 1997 book “Applying UML and Patterns,” serves as a critical design tool, not just for software development but also as a mental toolkit for understanding and applying design principles.

GRASP encompasses nine fundamental principles: Controller, Creator, Indirection, Information Expert, Low Coupling, High Cohesion, Polymorphism, Protected Variations, and Pure Fabrication. These principles are not new inventions but rather documentation and standardization of old, tried-and-tested programming principles in object-oriented design. They are instrumental in solving common software problems and enhancing the readability, scalability, and maintainability of code.

One of the key principles of GRASP is the Information Expert. This principle suggests assigning responsibilities to the class that possesses the necessary information to fulfill them. In essence, the class with the most information required to fulfill a given responsibility should be the one to undertake it. This approach not only streamlines the process of assigning responsibilities but also ensures that they are placed where the most knowledge and capability reside.

Another essential pattern is the Creator. It deals with the creation of objects, a common activity in object-oriented systems, and suggests that the class that uses or has the initializing information for an object should be responsible for creating it. This principle helps in defining clear relationships between different classes and their objects, thereby making the system more intuitive and easier to manage.

The Controller pattern is crucial for handling system events. It assigns the responsibility of dealing with these events to a non-user interface class that represents the overall system or a specific use case scenario. The controller coordinates and delegates the work that needs to be done to other objects, acting as a central point of control without taking on too much work itself. This pattern is fundamental in defining how interactions within the system are managed and is a key part of the application/service layer in an object-oriented system.

Understanding and applying GRASP principles is vital for any software developer working in object-oriented design. These patterns provide a framework for assigning responsibilities within a system, ensuring that each part of the codebase is both efficient and purposeful. By adhering to these principles, developers can create software that is not only functional but also easy to understand, extend, and maintain. This knowledge is not just technical but conceptual, offering a deeper understanding of how to approach software design in a methodical and thoughtful manner.

Sources

From the blog CS@Worcester – Kadriu's Blog by Arber Kadriu and used with permission of the author. All other rights reserved by the author.

Open Source Software in Education

     In recent times I have started a job as a computer teacher for a private school, and as such I have had to become familiar with a variety of educational software. As an educator, it is important for there to be a plethora of accessible software to teach children digital literacy, as computers have become increasingly incorporated into more facets of modern society.  Open-source software is one avenue that allows young students access to important tools to learn and create, without incurring a hefty price tag for their school. This is especially true for those learning how to code since it is not exactly a subject that comes naturally to everyone. While there are certainly many free IDEs out there for any aspiring adult programmer to use, I am more concerned with young children who may not be able to understand all the complex operations of standard IDEs. The best answer I have found is the educational coding software Scratch, created by MIT. Licensed under the “Creative Commons Share Alike” license, Scratch provides a drag and drop block-based coding environment that is easily understood and accessible to children. This allows teachers to easily demonstrate basic coding concepts like if-then-else statements and assigning variables. There’s even Scratch jr., available on tablets, that has an even more simplistic UI designed for even younger audiences. MIT has also released App Inventor, a free open-source software for creating mobile applications. These coding applications highlight the ability of open-source software to easily adapt to changes in social needs. But educational software does not just encompass programming and mobile apps, it also extends to various tools needed for academic success. Software such as ONLYOFFICE and LibreOffice, which provides a free alternative to Microsoft Office, is appreciated by students who cannot afford the more popular and expensive version. Not only are these applications useful within the U.S. education system, but another benefit they provide is their international reach. Since they are online and free for anyone to download and copy, they can be distributed to anyone globally with an internet connection. This opens new avenues for providing education to those in need. Education is a sector in need of accessible tools so that we can better teach the next generation and expand access to reliable education within our own borders and beyond. Not only that, but in this modern time where the importance of digital literacy is at an all-time high, we need to start laying the groundwork for future developers. 

https://scratch.mit.edu/faq

https://elearningindustry.com/open-source-tools-to-boost-digital-learning

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

application architecture, serverless

In CS-343, we’ve gone over three major architectures for designing applications. These three are the monolith, client-server and microservices architectures. Each has its strengths and weaknesses, but it seems as though if you can go with microservices, you should go with it as it provides stronger scalability and reliability even if it is much more complex.

From this, it seems like you would use the other architectures if you cannot afford to build a microservices architecture currently, do not have the time to do it, or if your team does not have the required skills / manpower to build up the architecture. It makes sense in the case where the application doesn’t need to be complex, but as time progresses, perhaps it will be that complex in the future, and having built from a monolith architecture ends up being a nuisance.

Out of curiosity, I wanted to learn about some additional types of architectures. I found this blog post written by Paul Gillin, and what stuck out to me was the serverless architecture model. His explanation of it is that it is an evolution of the microservices architecture, with the main departure being that it is, well, serverless. Services are run from software containers as opposed to being pulled from a server.

This idea interests me, not just because of not needing to construct a server with it, but also because it utilizes containers in a very effective way. In this course, I was interested in the practical uses of containers outside of simplifying development within a team, and it seems like this implementation is what I was looking for. Of course, there are some cases where a serverless architecture wouldn’t work, and this architecture is mostly suited for experienced teams due to its complexity, but it’s an interesting idea nonetheless.

After looking at other websites, I must mention that there is a distinction between a pure serverless architecture and one that utilizes containers. This webpage on the serverless architecture from DataDog makes this clear in the “Serverless Architecture vs. Container Architecture” section. Essentially, with a pure serverless architecture the cloud provider (AWS, for example) manages their servers, which means that you don’t have to manage it, but you do have to work with what they give you. With a container architecture, you have to update and maintain your containers, system settings, and dependencies for everything to work properly in place of a server.

With this distinction in mind, I definitely wouldn’t want to rely on an external cloud service, and so a container-based architecture does seem more appealing. Ultimately, though, every tool (and architecture in this case) has its uses, so it’s important to know and understand many architectures so you know what to use when you need to use it.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

Understanding APIs

As a teen, I remember the first time a video game prompted me to share an achievement with my friends through facebook.  How could a game not related to facebook in any way communicate with the servers to make a post?  Connecting applications together is vital for keeping up with the expanding technical world.  This is done with APIs.

Jason Johl does a great job explaining what APIs are and how they are useful in the real world in his blog,  “What Are APIs, and How Does an API Work?”. (https://blogs.mulesoft.com/learn-apis/api-led-connectivity/what-are-apis-how-do-apis-work/#:~:text=Share%20post&text=API%20stands%20for%20application%20programming,the%20response%20back%20to%20you)  He starts of by explaining the importance of APIs and how they enable speed and agility in software.  Then, gives a great example of how APIs can relate to a real life waitstaff at a restaurant.  Followed up by examples of actual APIs used in booking a flight.  Finally, listing different types of APIs, specifically the Web APIs, which I will be exploring more in detail later.

What is an API?

API stands for application programming interface, and is a messenger between software that handles delivery of the request and response.  Much like how a waitstaff in a restaurant is trained to take a customer’s order to the kitchen and then return with the food.  Kitchens take orders a certain way and it is the waitstaff’s job to translate the customers order into a format designed for the kitchen. Customers can’t interact directly with the kitchen, and must use the waitstaff to handle the requests. 

How are API’s Used?

Travel sites are a great way to visualize APIs in work and how they are useful.  The travel site collects information from a user on the client side and is able to take that information and search all different airlines databases to compile available flights.  To do this, the client, in this case a web browser you are using to access the site, sends an individual request to each of the airlines servers through the use of an API.  Then, the API in the airline servers takes that request, and returns all flights that match the fields such as dates and airports.

Common Web APIs

APIs can be designed and used for any software such as Java APIs allowing two objects to communicate with each other.  In most cases, I will be working with Web API’s that communicate between a client and server.  The most common Web APIs are Representational State Transfer (REST), Simple Object Access Protocol (SOAP), and Remote Procedure Call (RPC).

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

Work Smarter, Not Harder

This week I was viewing the syllabus topics and found a short article written by Rosie Faulkner, LAMP stack developer, where she describes the principle of least knowledge relating to software development.

Rosie coins the principle of least knowledge as “One of the most important software design principles” and defines the principle as “loose coupling, in that your code or your class depends on the least number of other classes in order to function.”

Rosie also states that the principle’s main focus is modularity and that a code’s modularity is important as to reduce the chances of code becoming overly complex/opaque and/or causing naturally occurring errors to become a frequent issue. By keeping our code as simple as possible, developers can create and maintain code while being more confident that new changes or updates will not affect/break anything. The less dependent (where possible) your code can become from third-party libraries the more secure and clear your code becomes overall by allowing others to view what is being done directly versus having to familiarize themselves with a new library.

By following the principle of least knowledge a developer can avoid their code from becoming Rigid, Fragile, Immobile, Overly Complex, and/or Unclear (or Opaque). By restraining from using third-party code, you can reduce the reliance on outside systems (where possible) which in turn will help not only yourself but also others in being able to view and understand your code directly. This will allow everyone to meaningfully contribute to whatever the project may be since all will have a proper understanding of what is being done.

An example where this can be displayed, given by Rosie, is a class that allows you to locate a user’s country using the IP of the given user. Rosie states “You could use a third-party class to do so” but security may become an issue over time and unsuspected updates may cause outages resulting in downtime and/or errors for users. Instead, if you create your method to return a user’s country you can directly change and update the code as needed and be able to view and tweak code with more transparency.

I often find when I am coding that I tend to over-complicate whatever I am trying to do. One example would be looking for ways to work around creating functions myself by using external systems instead. After reviewing this article, It’s more prevalent to me that trying to create the least amount of lines for a block of code doesn’t always relate to the health of the code as well. By taking a step back and reviewing what I am trying to complete and what remains to be done, I will be able in the future to partition which code should be used and what should be refactored to create the most healthy and maintainable coding environment possible. This will save me from future headaches due to negating the risk of unexpected changes/updates breaking things.

Article Link: https://medium.com/@faulknerproject/the-principle-of-least-knowledge-in-software-development-499b7a28aa14

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.

Embracing the Future of Coding with Gitpod

In the ever-evolving landscape of programming, developers often find themselves grappling with unforeseen challenges. Recently, I encountered one such obstacle during my computer science class, which eventually led me to explore a game-changing solution – Gitpod. This is the story of how Gitpod came to my rescue when Docker, a crucial part of an in-class activity, failed to run on my M1 Mac Pro, and my professor recommended Gitpod as a solution.

The Problem

As the class assignment required me to work with Docker containers for a web application, I was excited to get started. However, I hit a roadblock when I attempted to use Docker on my M1 Mac Pro. Due to compatibility issues with the M1 chip, I found myself unable to run Docker containers, leaving me perplexed and frustrated. My professor, understanding my predicament, suggested an alternative solution – Gitpod.

A Quest for a Solution

Eager to continue with my assignment and make the most out of the in-class activity, I immediately began researching Gitpod. This cloud-based development environment promised to provide a solution to my Docker woes while offering a host of other benefits. Without further ado, I dived into the world of Gitpod.

The Gitpod Experience

Upon signing up for Gitpod, I discovered the true power of cloud-based development environments. Gitpod provides an intuitive interface that closely resembles VSCode, making the transition remarkably smooth. It offers a wide range of programming languages and frameworks, ensuring that it can cater to almost any development needs. One of the most remarkable features of Gitpod is its ability to create a development environment based on a Git repository, making collaboration with peers more efficient.

Additionally, Gitpod’s integration with GitHub is seamless, as it allowed me to work directly with my project’s repository. This feature made it easy to commit and push code changes, ensuring that my work was well-organized and readily accessible.

The Benefits of Using Gitpod

  1. Compatibility: Gitpod works seamlessly on M1 Macs, resolving the compatibility issues that I faced with Docker.
  2. Accessibility: Gitpod is accessible from anywhere with an internet connection, which is a major advantage, especially for students and developers who are always on the move.
  3. Time Efficiency: Gitpod’s pre-configured environments saved me hours of troubleshooting and setup, enabling me to focus on coding and project development.
  4. Scalability: As my project expanded, Gitpod effortlessly scaled to accommodate my needs without compromising performance.
  5. Collaboration: The collaborative features of Gitpod made working with my classmates on group projects a breeze. We could effortlessly share and collaborate on code in real time.

Conclusion

In the end, the incompatibility of Docker with my M1 Mac Pro might have been a setback, but my encounter with Gitpod was nothing short of transformative. It provided a solution to my immediate problem and introduced me to a world of cloud-based development environments. Gitpod has become a valuable tool in my programming arsenal, and I encourage every developer to explore its capabilities.

References:

  1. Gitpod – The Dev Environment Built for the Cloud
  2. Visual Studio Code – Docker Extension
  3. GitHub – The World’s Leading Software Development Platform

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

CS343 Blog Post for Week of November 6, 2023

SOLID Design Principles Explained: Interface Segregation with Code Examples

This week, I wanted to continue writing about the SOLID software design principles. We’ve reached the letter “I”, which represents the Interface Segregation Principle. I’ve been noticing a theme across the SOLID design principles that as many parts of your software as you can manage should be independent of one another, so that modifications can be made to a part without compromising the whole. The Interface Segregation Principle brings the relationship between the software user and designer into focus.

Once again defined by Robert C. Martin, the Interface Segregation Principle is “Clients should not be forced to depend upon interfaces that they do not use.” This principle goes hand-in-hand with the previously defined Single Responsibility Principle, which declares that “A class should have one, and only one, reason to change.” The goal of abiding by these principles is to produce code that is resilient to future modifications and fostering that resilience by building independent software components.

The article provides the real-life example of a years-old piece of software being iterated on. The designers may want to add new methods to existing interfaces, even though that may introduce new dependencies to the interface and violate the Single Responsibility Principle. The author introduces the term “interface pollution”, referring to the phenomenon of existing interfaces becoming cluttered with new methods that introduce new responsibilities to the interface, rather than building new interfaces that handle those responsibilities.

The author provides a practical example of this principle through another Coffee Machine implementation. A new EspressoMachine class is proposed but requires a new method that the BasicCoffeeMachine interface doesn’t include. The problem of interface pollution is illustrated simply in this example, when a brewEspresso() method is added to the CoffeeMachine interface to support the new EspressoMachine class. No other kinds of CoffeeMachine would use this method. This approach also introduces the issue that BasicCoffeeMachine could try calling brewEspresso(), or EspressoMachine could try calling brewFilterCoffee(), and either case would throw an exception.

The solution in this case is to create new interfaces from the existing CoffeeMachine interface, FilterCoffeeMachine and EspressoCoffeeMachine. This way, only the methods required by either type of concrete CoffeeMachine class can be accessed. This approach strengthens the independence of the concrete classes. If a new CoffeeMachine design demands methods from both interfaces, it can simply implement from both.

I chose to write about this topic because I’m still learning how to assign responsibilities to different parts of my software. Having interfaces that contain too many methods rather than continuing to further specialize them is an issue I’ve faced in software that I’ve written myself. Studying the SOLID principles and actively applying them to my work will help save me a lot of time and effort in my future projects.

From the blog CS@Worcester – Michael's Programming Blog by mikesprogrammingblog and used with permission of the author. All other rights reserved by the author.