Throughout this semester, the most interesting topics to me are those relating to how to produce good code. While I like learning about and implementing API requests in either the frontend or backend, regulating code utilizing something like the SOLID principles is interesting to me because it can be applied in many different situations and programming languages. We discussed the SOLID principles earlier in the semester, and while I walked to discuss them on this blog, I never got a chance to.

The Single Responsibility Principle states that a class should only have one job. The below article uses the example of shapes, namely a square and a circle. The Square class has the length of a square, and the Circle class has the radius of a circle. Another class, AreaCalculator, contains the logic that deals solely with adding the area of the different shape objects.

The Open-Closed Principle states that “Objects or entities should be open for extension but closed for modification”. If a programmer would like to take an existing class and add functionality to it, the existing class should be developed in such a way as to allow easy inheritance, and the programmer should add his implementation in an inherited class. In the article’s example, the author adds an area() function in the shape classes to calculate each shape’s respective area, then changes the design to implement a shape interface, which is implemented by the shape classes. The AreaCalculator then checks the instances of Shape Interface, and calculates that way.

The Liskov Substitution Principle states that every child class should be substitutable for their parent class. This means that a child class acts in the same way as its parent class, in this case, providing similar functionality and returning in a similar format. The article uses the example of a class called VolumeCalculator, that inherits from AreaCalculator. Both VolumeCalculator and AreaCalculator must be consistent, such that its implementation is the same.

The Interface Segregation Principle states that a client should never be forced to implement an interface that it doesn’t use, or depend on methods they don’t use. Building on the author’s example, if we needed to calculate the volume of a sphere, a class shouldn’t manage both a circle and a sphere, but segregate them into two different classes.

The Dependency Inversion Principle states that “entities must depend on abstractions, not on concretions”. In the author’s example, one class connects to the database, whereas another class depends on the connection class, thus they cannot decouple. Instead, we should implement a class using an interface, which is the parent class of the connection class. Abstraction is now applicable in both high-level and low-level classes.

Going through this article has been informative. I would also like to practice implementation and classes in Java or C++ to gain a better understanding of these principles.

Link:

1. https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design

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

Hello Everyone! Hope all of you are doing well and Goodluck with your finals as we are in the last week of the semester. Today in this blog I want to talk about technical debt, it may sound like a financial term, but in the case of software development, technical debt is the idea that certain necessary work gets during the development of a software project in order to hit a deliverable or deadline. Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code. It is basically the extra coding work that a software development company has to do because they took a shortcut route to finish and deliver the product in time without making sure if it works properly or not.

Is technical debt bad? The simple answer is it’s neither good nor bad, it’s debt. Several software companies today are under pressure from the market and competitive forces to develop and ship fast. Startups especially feel this “ship or sink” pressure. This need for speed leads many product and software development teams to make the tradeoff between taking on technical debt or launching later. There is sometimes unintentional technical debt with various software development teams such as the team who follows Poor practices, this leads the works done during the project to be messy which then makes the teamwork on it later which lead to technical debt, Software development teams being Inexperience with new coding techniques leads to the delay of the coding process or in some cases making the code messy which than later lead to technical debt. For example, a design approach that ends up containing many errors is unintentional technical debt. This sometimes occurs as the direct result of poor communication with the organization or misalignment between the developers and operations teams.

I choose this article because this article gives a very easy definition of technical debt and it also contains a video that explains technical debt in detail, this article also talks about what are the good reasons for technical debt and the bad reason for technical debt which makes the concept clearer. And having a major in Software development, it is important to know about the concept of technical debt as it will help in the future as a software developer.

Article: https://www.bmc.com/blogs/technical-debt-explained-the-complete-guide-to-understanding-and-dealing-with-technical-debt/#

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

This is a brief video detailing “PubSub“, also known as a Publish-Subscribe pattern in software architecture. This is an extremely common pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorize published messages into classes without knowledge of which subscribers, if any, there may be.

A better way to visualize and understand this concept is displayed in the video. Alex Young codes a simple “clicker” style game in JavaScript where you get a certain amount of “xp” that fill up a progress bar per second. You can increase this gain by clicking a button that adds xp. Once your progress bar fills up, you move on to the next level and the progress bar resets. The way that PubSub fits into this is by publishing an xp_changed event and having the game’s User Interface subscribe to that event in order to update the progress bar and update the current xp. He also publishes when he “levels up” so that the game can recognize that it needs to reset the progress bar and progress the player on to the next level.

This application of a PubSub pattern was especially helpful for me in understanding a practical way to use an extremely popular pattern and also allow me to visualize how I might use it in the future. Coding in JavaScript is something I’m rather unfamiliar with but this video does a good job of describing the process in simple terms and showing how each change affects the game.

I chose this particular video because in the video I detailed in my previous blog post, the author spoke in depth on PubSub patterns and how prevalent they were in Software Architecture. I wanted to learn more about how they work and practical basic uses that I may encounter so I found a brief video showing a concrete example of how PubSub functions in JavaScript.

One thing that I found was particularly enlightening was actually in the comments of this video. Another viewer compared PubSub in JavaScript to event listeners in Vue. Since we were recently learning about Vue, I was able to use my understanding of Vue to better understand the examples in JavaScript.

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

Rest, an acronym for Representational State Transfer, is a type of API for web services that have a client-server architecture where clients request for data and servers return data in plain text formats, such as JSON, XML, and YAML. In my software engineering course, designing Rest API requests was the most difficult challenge I faced because I did not understand the parts of a request and their purposes. Because understanding a request’s components is fundamental to designing Rest APIs, the goal of this post is to explore the parts of a request. To help me achieve my goal, I will be using the article, “Rest API: the basics,” which explains the three components of a request: its method, uniform resource locator (URL), and body.

The request method is a procedure a client wants to make. The available methods include GET, PUT, POST, and DELETE. Because they are the same methods used by computers to download pages (or hypertext documents) from a web server, they are called Hypertext Transfer Protocol (HTTP) methods. The GET method is used to get one or more items from a server; the PUT method is used to update an item in a server; the POST method is used to create and add an item to a server; the DELETE method is used to remove an item from a server. Given the methods, a client can make requests to only create, read, update, or delete data.

The URL is an address to a resource, a unit of an item, in a server. The URL is made up of an endpoint and path. The endpoint is a reference to a web server, whereas the path is the identifier of the resource in the server. Given the URL, “https://twitter.com/justinbieber,” the endpoint is “https://twitter.com/,” and the path is “/justinbieber.” The endpoint is the reference to Twitter’s server and the path is the identifier of Bieber’s Twitter page.

The body is an optional section where a client specifies the data it wants to send to a server. It is only used with POST and PUT methods because the server would need data to update (put) or create (post) items. The format of the body must be in the format of the response. In other words, if the server returns items in JSON format, the client must input data in JSON format.

To bring my understanding full circle, I will be breaking down and interpreting the components of a request I defined and called for a food pantry software in my course.  The request is

“GET http://localhost:10001/orders/61b16887ca02e000073ceabc.” I used the GET method because the request is intended to retrieve all orders of a given ID from an Orders database. “http://localhost:10001,” is the reference to my webserver, which I hosted on my local computer. “/orders/61b16887ca02e000073ceabc,” is the identifier for specific type of order in the database.  The components make up the request to fetch all orders of a given ID.

https://towardsdatascience.com/rest-api-the-basics-d91859537c9d

From the blog CS@WORCESTER – Andy Truong's Blog by atruong1 and used with permission of the author. All other rights reserved by the author.

For this week’s post, I am refining my definition of an API and exploring the reasons why an API might be used. When I was learning to program in Java in CS140, the course textbook described the Java API as a library of prewritten code programmers can use to add functionality to their programs. Because the textbook described an API as a library, I defined APIs as libraries of reusable code. When CS343 reintroduced me to APIs, my instructor described an API as a link between two applications. Because his definition of API conflicts with my definition of API, I feel as though my knowledge about APIs is unsound. To polish my understanding, my post’s goal is to explore APIs and the reasons they are used. To help me achieve my goal, I will be reflecting and adding to MuleSoft’s article, “What is an API? (Application Programmable Interface)”

An API is how two applications can share information. To explain an API, Mulesoft uses an analogy; Mulesoft states, in a restaurant system, a waiter is an API for a customer and the kitchen. In other words, the waiter is how a customer can communicate his or her order to the kitchen. Mulesoft then transitions to APIs in software development by introducing flight search applications, such as Priceline, Kayak, and Expedia. The flight search applications aggregate information from various airlines, including Worcester Regional Airport and Boston Logan International Airport, by using APIs. In other words, flight search applications collect flight information from airline applications through an API. Both examples show that APIs are used to share data.

While Mulesoft explores only one reason why developers use APIs, developers use APIs to also

hide complexity. Ride-sharing applications, such as Uber and Lyft, are examples of how APIs are used to hide complexity. They use the Google Maps API to display a map and generate routes for drivers and riders. I know they use the Google Maps API because after installing Uber or Lyft, the application asks for permission to use Google Maps. The API hides complexity because Uber and Lyft developers do not need to create a map and define pathing algorithms. Uber and Lyft show that developers can focus on building upon the capabilities of another application by hiding complexity.

A third reason why developers use APIs is to extend functionality. Online stores that accept Paypal payments, such as BestBuy, eBay, and Etsy, are examples of how APIs are used to extend functionality. They use Paypal’s API to provide a Paypal login form and collect money. The API gives online stores the ability to accept Paypal payments. By adding functionality, end-users will have multiple payment options.

Returning to the conflict that inspired this post, the Java API is a library and an API. It is a library because it provides reusable code. It is an API because it allows two programs to communicate with one another. The library is simply part of the API.

https://www.mulesoft.com/resources/api/what-is-an-api

From the blog CS@WORCESTER – Andy Truong's Blog by atruong1 and used with permission of the author. All other rights reserved by the author.

I decided to review a topic previously discussed during our second homework assignment this semester in Software Design and Architecture; Design Patterns. This is a much shorter video that serves as more of a refresher of five different design patterns and their main uses, advantages, and disadvantages.

Software design patterns are described as a general, reusable solution to a commonly occurring problem within a given context in software design. This is far too general to be applicable in any meaningful way. What this video provides is much needed context for what each pattern is and in what context would it be useful.

The author of this video is named Jack Herrington and he works for Nike as a Principal Software Engineer. He has written six books and is a verified authority on Software Design. The first pattern that Herrington describes is the Singleton pattern. The Singleton pattern is described as a pattern that restricts the instantiation of a class to one “single” instance. Herrington says that this pattern is very good for use in a database driver or, if you’re over on the client, the data store with the current state of the application. The pro of this pattern is that you can go and get to that data whenever you want, you just have to get the singleton and away you go. The con is that it’s very difficult to back out of a singleton pattern and that it can be very restrictive.

The second pattern discussed is the Facade pattern; this pattern is an object that serves as a front-facing interface masking more complex underlying or structural code. This can improve readability but may also mask some functionality, thus requiring the consumer to do a bit of work to access the feature that they want. Third is the Adapter pattern; which allows the interface of an existing class to be used as another interface. Herrington uses his camera as an example, how the body of the camera serves one main purpose and is then modified by the interchangeable lens. The main draw of this is that it can be applied to almost any app and allows for additional functionalities, only limited by the “body” of the app. The pitfall is that many developers overuse this pattern and complicate too much of the app, thus damaging the quality.

These were the first three and I highly recommend you watch the video to learn more about each of them. I plan to take this knowledge with me and keep an eye out in my career for different uses of each of them and try to better understand why each pattern is used in professional settings and what each of them accomplish differently.

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

Self-Directed Professional Development Post #7

For my last blog post, I’ve decided to review an article titled, “HTTP Methods” from the website, https://restfulapi.net/http-methods. The reason I picked this article is because 1. it directly relates to one of our course topics, “REST API Design” and 2. it helps me further prepare and review for my upcoming final exam. In addition to the resources that I have from the class POGIL activities, I wanted to find another resource to solidify my understanding of HTTP methods. In this post, I will start by going over the 5 HTTP methods and the information I’ve gleaned by reading this article, and then I will move onto a reflection on how effective this article was in helping me learn this course topic.

In the list of review topics for my upcoming exam, I’m asked to know what the HTTP methods are used for and how they differ depending on whether I am referencing an entire collection or a single element in a collection. In the article that I’ve selected to read, the HTTP GET method is discussed first. I’m reminded that the GET method is used to retrieve information and that it can be used for both a collection and a single resource. This lines up pretty well with what we have learned from our class activity 12 (see table in Wikipedia citation below). Next, HTTP POST is brought up in the article and we learn that it is used to create a new resource in a collection. We are encouraged not to use POST on a single resource/element and this corresponds with the information from activity 12. Subsequently, the article discusses the HTTP PUT method. We learn that PUT is used to update an existing resource or create it if it does not already exist. PUT methods can be used on both elements and collections (this also matches up with the information learned in activity 12). In fourth place, the article discusses the HTTP DELETE method, one of the more straightforward methods, that can delete single elements or an entire collection. Lastly, with HTTP PATCH, we learn that it can be used to make a partial update on a resource and that it is usually used on elements. Personally, I preferred the description of this method over the one given in activity 12 but the article did support the point that PATCH is not usually used on an entire collection.

Finally, once I was done reading/taking notes on the article, I felt even more confident in my understanding of HTTP methods. I thought the article was both straightforward and educational, and therefore effective. The language was easy to understand and it provided me with another perspective to learn the class material. I would recommend this article to anyone else who is learning about HTTP methods for the first time or simply needs a refresher on the topic.

Article:

• https://restfulapi.net/http-methods/

Wikipedia link:

• https://en.wikipedia.org/w/index.php?title=Representational_state_transfer&oldid=866461276

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

https://www.dossier-andreas.net/software_architecture/fsm.html

A finite state machine is an abstract model of computation. In the context of software development, it can be used as a way to control and conceptualize the flow of a program.

Finite state machines consist of a number of states, each representing a particular behavior of the system. These states have transitions between them, defining when the system may change from one state to another. Transitions can be thought of as connecting the states like a graph (specifically an ordered graph, with two states that can change to each other represented by two separate transitions). The graph is not necessarily complete or acyclic. The state transition also defines what actions must be taken to change the system from one state to another.

I like most of the articles from this blog, but I found this one a little lacking. In particular, the “Examples” and “When should you use it?” section, which really don’t say anything meaningful.

The examples section states two examples without elaborating: A coffee machine and “Games” (just, in general I guess). Here’s how I would model a coffee machine (knowing nothing about how they actually work and just going off how I’m used to them behaving):

The coffee machine begins off. In this state, it can only be turned on, which starts it in the “awaiting input” state. From there, you can press a button to have it actually make the coffee. For the sake of simplicity, giving it water and coffee grounds are handled by a human and heating the water is rolled into the “dispensing water” step (I would place it in between “dispensing water” and “awaiting input”, connected to both of them and also to “off”). A sensor would detect whether there is actually enough water to make coffee and move to either the “dispensing water” or “error” state accordingly. The “dispensing water” stage just pours the coffee and either moves to the “awaiting input” state when finished or the “error” state if it runs into some kind of problem. The error state simply displays a message and then returns to the awaiting input state. At any point, the machine can be turned off, but once turned on can only start at the awaiting input state.

Note that this is not really helpful at all for building an actual coffee machine. It is, however, helpful for simulating a coffee machine programmatically, and a similar thought process can be used to break down almost any kind of behavior.

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

In this week’s blogpost, after seeing a piece of code in a previous assignment I wanted to learn a little bit more about what it actually was. The piece of code in JavaScript used async and await, and me being a novice in JavaScript didn’t exactly know what it was, but did a little bit contextually. At first glance they seem like timed functions to synchronize something. In exploring what these were I came across this article on error handling in JavaScript.

https://www.valentinog.com/blog/error/

This blog goes into great detail over error handling in JavaScript, and I’ve learned quite a bit more as well as answering the async and await question.

First off, I did not know that JavaScript was single threaded, meaning that it doesn’t utilize multi-threaded processes to handle certain bits of logic simultaneously. The article gives a good example with a timed error throw with an error catcher to demonstrate how the try/catch will already execute before the error would ever be called.

I was also introduced to some new interesting features of JavaScript like Promise. Promise is indicative of it’s name and is basically like a promise of the code to catch up with each other later. Promise uses “.then”, “.catch” and “.finally” where the only real difference is in name for “.then” as it’s the counterpart to “try”. It also has some more singular uses like “.all”, “.any” and “.race”. These are just different methods for finding an error. All will take an array of “promises” and find any of the errors from the promises and return the promises that resolved. Any will give you the first of the “promises” that resolved. Race is basically just a race to see who completes first regardless of error or not.

Asny and Await are two functions that you generally prefix to another function. Async forces the function to return a promise which allows us to use the Promise “.then”, “.catch” and “.finally” to resolve outside the function. But it doesn’t also mean that we can’t use try and catch as with “await” it allows us to literally wait for a function to resolve and with try and catch we can handle the errors inside of the current function.

Overall this article was very helpful. My intention was to just find an explanation as to what async and await meant, but I ended up with a little crash course on interesting ways of handling errors in JavaScript, as well as clear meanings behind each one.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.