https://blog.devgenius.io/what-are-rest-apis-http-api-vs-rest-api-92c2fe2bb136

For this last blog post, I decided to pick this post on the same blog as the last one, blog.devgenius.io. Admittedly I am picking too many REST API blog posts but I thought this one was a good pick because I’ve never dove deep into why we use REST APIs and what they are as well as some other types of APIs. In this blog post titled “What are REST APIs? HTTP API vs REST API” by The Educative Team (which I assume is a team of authors) they go over HTTP APIs, REST APIs, when to use REST APIs, and what to learn next.

First, they go over what an HTTP API is. It’s an API that uses Hypertext Transfer Protocol as the communication protocol between the two systems. HTTP APIs expose endpoints as API gateways for HTTP requests to have access to a server.
They also go over common alternatives to the popular REST API: GraphQL API, Falcor API, and gRPC APIs. GraphQL APIs are the second most popular form of API and seeks to correct common problems with the REST API structure. It’s open-source and designed to hold data in a tree structure. Falcor API uses much of the REST API architecture with paths and references but automates much of the request structure. Lastly, gRPC APIs are a newer API based off RPC APIs. Almost all of the processing of gRPC APIs are done by the server in RPC architectures.

Next, they go over REST APIs. REST API stands for Representational State Transfer and is an architectural pattern for creating web services. REST APIs see widespread use by application developers due to how simply it communicates with other machines over complex operations. REST is a ruleset that defines best practices for sharing data between clients and the server. It then goes into architectural requirements to be considered a REST API: Client-server, Stateless, Cacheable, Uniform Interface, and Layered System.

Lastly, it goes into when to use REST APIs, when not to, and what to learn next. For when to use REST APIs, REST APIs are great for building general-purpose applications to be scalable in the future. As for when not to, REST is a helpful tool in your toolbelt and a good general rule to follow but it shouldn’t be your programming dogma. For what to learn next, you should learn other API types so you can recognize when a situation calls for a non-REST solution.

I thought this was a good blog post to dip my toes more into REST APIs and just APIs in general. When I was working on my homework, I didn’t really give much thought into the work but when looking into the concepts of the homework more, it’s actually interesting to learn about. I also chose this blog post because it went over other API types that I should learn about if I go into front end development and I thought that was a good takeaway from this post.

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

In our modern society videogames have become a

In our modern society videogames have become a ubiquitous piece software that many use as a form of entertainment. They are on everything from dedicated home consoles and PCs to handheld devices and most prominently, smartphones. Videogames as software can range from extremely simple text based games to complex 3 dimensional environments with intelligent AI systems controlling events throughout the game.

Game development can be a great exercise for any upcoming software engineer to practice their skills. A single person is capable of creating a game as was the case originally with the popular game Minecraft. Minecraft, as many may already know is a open world that is famous for its randomly generated terrain and complete freedom in destroying and building in the world around you. In this simple game there is AI controlling the in game monsters, physics that dictate how you jump, fall, and swim. A dataset of different types of blocks that make up the game, and a world generator that utilizes different rules to create a landscape that is random yet results in a world that is cohesive and believable.

In contrast to the random generation and world state tracking done in Minecraft, other games such as portal specialize in their ability to create believable physics as well as their signature reality bending portals. The game allows you to seamlessly move through portals and stand anywhere in between and also involves physics of items and liquids dropping and moving in a believable way. Physics is an important part of the game and can prove difficult in itself to design from a software perspective.

Aside from these however, games can be as simple as a 2 dimensional platformer that only needs to consider at a basic level the act of moving left or right and jumping, or even a turn based game that needs only consider strict choices that are given to the player to interact with the game world. Game development, just like any good software has a development cycle and will go through a development, alpha, beta, and release cycle where the software will take shape and become a finished product over time. As the game becomes more complex, bugs and other problems may arise that must be dealt with and code optimization and organization becomes important. It can involve multiple people and repository management as projects become more and more complex, too complex even for just one person to deal with. Often the gamification of a task can make it more enjoyable and rewarding to practice so why not apply this to software. If it interests you it can be a great way to practice your skills and even discover new practices that can help in other programs you create.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Hello, blog (mood-status: relax), writing this blog after coming home from work, finishing the exams, and submitting assignments. But anyway, on writing about this week-15. I am writing this as my “final” blog for the year 2021 for real. I decided to go on the Syllabus once again to look at the course topics. Then I choose the subject of the Patterns & anti-patterns.

Patterns

Patterns are part of everyday language, but it’s essential to discuss algorithms to understand their importance in software engineering. An algorithm performs a daily task like sorting a list of items, storing data for efficient retrieval, or counting occurrences of an object within a data set.

 Algorithms are among the most used fundamental concepts in software engineering. It mainly highlights proofs of its solutions and its only code samples in obscure, ancient languages such as Algol or MIX Assembly. Despite much covered: singly- and double-linked lists, trees, garbage collection, etc. The details are hiding in problematic libraries, but the concepts are the same. These algorithms have remained reasonable solutions to common software engineering problems for more than five decades and are still going strong.

A “pattern” can be a general structure of an algorithm. In algorithm focus on a specific programming task, a pattern challenges beyond that domain and areas such as reducing defect rates, increasing code maintainability or allowing large teams to work more effectively together. Some standard practices include:

• Factories
• Pub/Sub
• Public-key Cryptography
• Agile
  

These are four common patterns in the industry; it ranges from highly technical to broader, more process-oriented points. Factories are very code-oriented, while pub/sub is more architectural. While public-key cryptography has general importance, libraries to support its operations are available for almost every programming language in everyday use, making it generally short of implementation.

At the other end of the expanse, “Agile” remains unavailable: a point and a tool among developers, project managers, and other stakeholders about precisely what it means and how it should be implemented. From Narrow or broad, technical or process-oriented, excellent working knowledge of these patterns is an essential component in a technologist’s toolbox.

What is an Anti-Pattern?

A “pattern” is a known-to-work solution to a common software engineering problem (anti-pattern). Anti-patterns do not incorporate the idea of failure to do the right thing, including options that seem right at face value but direct to trouble in the long run.

Note the reference to “a common response.” Anti-patterns are not a few mistakes; they are familiar and always followed with good choices. As with regular patterns, anti-patterns can be broad or very specific, and there may be hundreds to consider in the realms of programming languages and frameworks.

From the blog Andrew Lam’s little blog by and used with permission of the author. All other rights reserved by the author.

https://blog.restcase.com/top-5-rest-api-design-problems/

For this week, I wanted to stay on topic of REST APIs because I was still working with REST APIs this week. Also, I just think REST APIs are a fun topic for me to learn about since it’s so foreign to me. Anyway, in the blog post by Guy Levin from a blog that focuses on “Architecture, Programming, Ideas and Thoughts about microservices, APIs, cloud technologies and more” linked above, he writes about the top 5 REST API design problems. The 5 problems consist of: Using body in GET requests, usage of wrong or lengthy names for parameters, defining own error code and error message, ignoring caching, and returning too much data and long response times.

To summarize the 5 problems,
Using body in GET requests: add parameters inside the body, instead of in a URL. Many servers might not even look at the body of the request when it comes to GET method.

Usage of wrong or lengthy names for parameters: Since the URI already should state what is the resource, like project, there is no need for a long name like project_id, but only id.

Defining own error code and error message: Don’t use the approach of returning a response code 200 when something went wrong, make use of standard HTTP error codes.

Ignoring caching: Try not to ignore caching and use it, caching is very useful and gives several advantages like saving network bandwidth since this the server does not return content body but relies on the browser for that.

Returning too much data and long response times: Nobody wants to call an API and get a response after 2 minutes. Start designing your REST APIs with support for pagination, sorting and filtering.

I thought the problems Levin listed were simple mistakes that he wrote about to emphasize that these are easily missed. These problems seem to come up often if he has to write about them. I picked this blog because I thought it would be more complex problems but I think the blog post was a good post to reinforce REST API fundamentals. Looking back at these problems, I don’t think I really encountered much of these problems when I was working with the backend of the pantry API. Other than caching, all of these problems I didn’t encounter which I thought was good since the pantry backend was my first encounter with REST API stuff so I was already exposed to good fundamentals.

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

Traditional web applications function by having single pages that need to be refreshed when data has to be updated or submitted. You can likely recall using a website where each time a form was submitted or a link was clicked, you had to wait for the data to process and a few seconds later a new page appears. This process feels very cumbersome and discourages the use of the service.

Modern-day web applications are single-page, meaning data is dynamically added and removed from the HTML without the page needing to be redownloaded. To do this, a virtual dom is created through javascript and rendered as HTML to the page. When the virtual dom has a change, the actual dom is updated only in the area that is needed, without reloading everything. This change in design improves speed, reduces the amount of data to load, and improves user experience. Most services used online today are single-page applications and when they are not, it feels old and outdated.

There are three main web frameworks that are used to create single-page applications and these are React.js, Angular, and Vue.js. Of these frameworks, Vue has the fastest-growing developer userbase. A main benefit of Vue is that it is an easy-to-learn framework. In Vue, the virtual dom has a two-way data binding. To dynamically control the webpage, Vue uses user-created components that are linked together in a hierarchy. Each component is abstracted and allowed to have variables passed to it to make it display specific data. This feature allows custom HTML components to be reused, reducing repeated code and unmanageably long HTML files. A benefit to Vue components is that they can be easily unit tested, as only a small portion of the web application will be tested at a time.

In each component, it can contain state variables, which are like javascript variables that are tied to an element on the webpage. When a state variable is changed, its value is updated on the webpage. The process of watching a variable for a state change and updating the virtual dom then rendering the update to the webpage is called data-binding. This process happens nearly instantaneously and is what makes using Vue-built applications feel seamless and snappy.

I have used React.js in the past and I am familiar with the structure of combining html and javascript together. I am interested in learning more about Vue and what benefits this framework has to offer. Vue separates out the style, structure, and logic of each component which forces developers to keep their code cleaner than in React.

Source: https://www.altexsoft.com/blog/engineering/pros-and-cons-of-vue-js

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

Before constructing a project, we must picture out an image out or possibly draw it out to get a better grasp. This way tends to make a smother software as writing our code. But overtime we must face challenges along the way, which regards to maintaining software and keeping it maintained and readable. I have found this website which is called https://flylib.com/books/en/4.444.1.47/1/. This website is a library is all types of information regarding a library of books in different areas such as SQL, programming languages, interfaces, etc. I believe this website can aid me and any other developer to get a wider insight on the information they desire to seek. 

Design smells are basically violations regarding poor designing and that can be spread among other parts of one’s code and/or project. Which is why we have types of code smells to determine on how to seek and resolve it before it becomes an issue. The design smells are divided into seven principals.

Rigidity design is where you make a small change in your code could make huge, unexpected changes in other areas of the software. Fragility design is almost like rigidity, but this is where is when you alter a change in your code and broken code starts to erupt in. this is a sneaky design smell because we do not realize it sometimes and it can potentially make it through the production phase. Immobility design is common due to the fact of parts that are deemed useful are also harder to separate as it can pose a risk. Viscosity designs are also common when deciding between a not good choice that is convenient other than a good one that is not convenient. Needless design comes in two forms which are needless complexity and needless repetition. Needless complexity is straight forward of making your code overly complicated than it needs to be that consists of redundancy. Needless repetition is composed of unnecessary repetition. For example, when we make copies of classes to do the same thing and adding more classes on top which result in a developer’s laziness. Lastly, we have opacity design where readability becomes harder to read and takes time to understand the code which waste time on a developer. 

After gathering information on design smells and seen examples of each type of design smell in my CS-343 class. I understand that it is crucial to refactor code where it can stay readable and keeping it maintained. When starting a project, we always want to make a visual image to make it easier to implement. Also applying the rules and avoiding design smell as much as we can but sometimes, we can miss them and are able to determine the type of smell and find a solution. 

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

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.