For many assignments in a recent class, I had the opportunity to use and learn about REST (Representational State Transfer) API in relation to simple web applications. In working with REST, I was unsure about some of the syntax and conventions used with the API, namely the difference between different response types (JSON vs String response for instance).

I looked into finding some more information on good practices for REST API projects, and according to a helpful blog post I found on Stack Overflow (https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/), REST APIs should generally both request and send responses with JSON (JavaScript Object Notation). I had a number of issues with sending and receiving data which was not in this format (needed to send/receive strings in POST methods within an endpoint). This was causing problems such as information not being sent and received properly (name field of an item not being sent or received in the right places) as well as issues with the functioning of the web application itself (endpoints belonging to unrelated services would cease to function properly if the requests and responses were not JSON.

Furthermore, according to the author, JavaScript has baked-in methods to handle interacting with JSON entities, which makes it easier to use overall especially if there are other JavaScript based technologies being used within the structure of the project, so it makes sense to use JSON within requests/responses. So in future projects involving REST, I will attempt to primarily use JSON objects for responses and requests to ensure compatibility and easy access through JavaScript.

Another point which was discussed was the importance of using nouns in naming conventions, rather than verbs (specifically nouns which are highly representative of the destination or object being affected) when naming endpoint paths. IE: instead of POST: /orderPizza/, use POST /order/ when trying to create a new order. This makes sense, as the HTTP methods typically describe the action or verb being enacted on an object, so you needn’t describe that within the endpoint path.

Finally, I want to discuss the topic of HTTP status codes; the author of this article describes the meaning of many common error codes and why you might return them as a response. This was especially helpful for me as I had been using these codes within a REST project, but had no idea what the majority of them actually meant. According to the article, a code of 400 indicates a client-side validation error, 401 represents an authorization or permissions error, and 404 represents an inability to find a particular resource. Out of all of these errors, 404 is definitely the most common from my experience. I have frequently seen this while using the internet whenever a page would couldn’t be found on a website/web application, it was pretty neat to learn more about.

Overall, after reading this article I feel more informed about the way REST API services work, and will be more prepared for the next project I work which makes use of the framework.

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

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

When working with larger projects, a unified system or pattern can be useful in keeping things organized and cohesive over time. Design patterns can be applied to general problems in software development, such as creating many similar objects with slight differences from a factory class which handles object creation within the program, or using decorators in a program to add specific attributes or behaviors on a per-object basis. But while these design patterns are helpful for solving singular problems, they often lack the scope necessary to layout and plan the entirety of a project or large program or application.

Architectural Patterns

I found an article written on the blogging platform Medium https://medium.com/@nethmihettiarachchi484/common-software-architectural-patterns-in-a-nutshell-7df312d3989c which briefly explained the concept of Architectural patterns, which refer to higher-level guidelines and decisions made regarding a piece of software as a whole, rather than one specific problem within the code. This was confusing at first, but as the article provided brief explanations (and examples) of various architectural patterns, I was able to grasp the concept more conclusively. Now I will go into detail regarding two patterns I found likely to be useful and the kinds of programs they would be most applicable to.

The Layered Pattern uses a system of layers to group together similar functionality for ease of access and organization. Layers can set access rules for other layers (layer C has access to layers A and B, layer C only has access to layer B). For example, imagine a solitaire program, one layer controls drawing and taking input for interface components (windows, buttons, score etc) while another layer could contain the logical rules of the game solitaire, mechanics and random distribution of the cards (things the user would never need to access directly). For applications where there are a lot of similar behaviors which could be easily grouped into layers, the layered pattern makes a lot of sense.

Additionally, the Multi-tier pattern also concerns layers, in this case, entire systems (complete features, ie: user-input for input related features, display for display features) are grouped into tiers. A tier is a grouping of elements within the program which are interrelated, and seem most often used in web-related capacities or in online applications with various segments to consider (web browser, web, front-end and back-end could be potential tiers). Since each component or feature can only be part of one tier, individual tier choices will need to be carefully considered. Another major drawback is the amount of setup that goes into the process of implementation, since each of the tiers needs to exist as a grouping before the components can be assigned. I think this pattern would be most useful for large projects spanning multiple languages and technologies in the real world (web-applications for example, with front-end, back-end, browser components).

While I only highlighted two of the patterns discussed in this blog post, I think that layered and multi-tier patterns will be most useful for small-medium (layered) and large projects (multi-tier) in general.

Site referenced: https://medium.com/@nethmihettiarachchi484/common-software-architectural-patterns-in-a-nutshell-7df312d3989c

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

Oftentimes, when programming in an object-oriented language, I have the issue of unintended redundancies. I write things to be too verbose; long variable names (studentClassId, carManufacturerName), with unnecessary complications, methods and variables that could easily be removed from my code without losing anything. My reasoning in these cases is always ‘this will make my code easier to read’, or ‘specificity is always a good thing’, but more often than not, this results in messy code with complicated loops and if-statements, where a simpler approach would be much easier to work with in the long run. Over time, larger projects can get to be a huge issue, the more convoluted the code becomes, the harder it is to look at and understand after a few days.

A good example of this problem would be to imagine a simple program which simulates various cars. Instead of having a central car class which handles the definition of a car, (wheels, doors, engine etc), I might have a car class which has instances of wheel, door, and engine classes, which have their own instances of ‘wheelTireType’ (which can be one of three types of wheels), and also similarly needless complication for the doors and engine.

While being specific can be a good practice some of the time, I tend to take it overboard sometimes and end up making classes like ‘carDoorType’ when I could have just as easily had an integer ‘numberOfDoors’ variable and gotten the same effect without introducing an extra, functionally useless class.

When reading an excerpt from Google’s testing blog, I found the principle of YAGNI (“You Aren’t Gonna Need It”) to be of interest. The idea is that you should keep an eye out for unnecessary code and remove it/refactor your code without the unneeded parts. The blog post gives a good list of “code smells” associated with the YAGNI design principle, including code which never executes (“Just in case” code), code which is only executed by tests, and is never used in the actual running of the program, and variables which are redundant.

Out of all of these issues, I definitely struggle the most with redundancy, and recognize that it is something I need to work on overall. Many times while writing Java code, I have created methods and classes simply out of the belief that I “may” need them later on and that this saves me time spent creating these classes later. While this makes sense at the time, coming back to the code later I just end up with a lot of unused classes which end up getting deleted anyway, negating any time savings.

I suspect that going back to some old projects and attempting to refactor them with the YAGNI design principle in mind would be a good way to practice. While it seems rather self-explanatory at first, I think that approaching projects with the intent of preventing redundancy will produce considerable improvements in any future designs going forward.

Site Referenced: https://testing.googleblog.com/2017/08/code-health-eliminate-yagni-smells.html

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

In web development, the development of web applications (software accessed through a web browser) and even game development, JavaScript is used to add interactivity and function to what would otherwise be static webpages, and to create software which runs entirely within users’ web browsers. And while JavaScript is undoubtedly useful in the contexts of web and software development, there are some aspects of the language which I feel are somewhat lacking compared to other programming languages.

For one, compared to its namesake Java, JavaScript is somewhat lacking in terms of its ability to create objects. While objects are a part of JavaScript, creating classes is very nonspecific compared to Java. For example, say I want to create an apple class in Java and in JavaScript, for Java, I would need to create a separate class file:

public class Apple {
   String color;
   public Apple()
      {
       color = "red";
       System.out.println("I am a " + color + " apple!");
      }
}

Whereas with JavaScript, it would look something like this:

class Apple {
  constructor() {
   this.color = "red";
   console.log("I am a " + color + " apple!");
  }
}

While not being strongly typed does have advantages (flexibility of variables, ability to write code which returns a different type depending on context/necessity) I prefer the strong typing of languages such as Java and C#. Strong typing helps to make code more readable, without specifying the type of a variable before using it (ie: var fruit = “apple”;), it can be unclear what a variable is intended for at first glance (especially if there are many similar variables storing similar values). With strong typing, you are always clear on what type of data is meant to be stored inside of a particular variable, (int studentID is clearly only meant to store integer values, while String studentName is only meant to store String values).

JavaScript continues to grow and develop as a language, and new features are constantly being implemented. When reading about some of these new features being added to JavaScript this year, I found a blog post discussing some of the more interesting features which were implemented in 2020. The post served as a good introduction, and offered clear information about each of the new additions discussed.

Private & Static Fields

Something which was absent from JavaScript was the ability to use access modifiers for fields. This year, the ability to use private, or static fields was added to JavaScript; private fields will allow for greater security and the ability to ‘wall off’ access to certain fields, while static fields will allow for the creation of ‘class-scope’ attributes.

BigInt

Another complaint which I have had about JavaScript is the fact that JavaScript only has one number type. While the introduction of the BigInt type does not solve this issue, it does allow for larger numbers to be represented in JavaScript. It functions similarly to the Java ‘Long’ datatype, in that it can store very long number values.

While JavaScript is still missing some features which I enjoy from other languages, these recent additions make it more versatile than ever, and JavaScript continues to be the de-facto language for developing anything interactive on the internet.

Site Referenced: https://www.telerik.com/blogs/latest-features-javascript-ecmascript-2020

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

When I was first learning about programming and writing code, I never stopped to consider issues like effective layout, efficiency, or structure in my programs. At these early stages, it was enough for me that the code worked and ran without crashing. Now, as I have been studying design patterns in one of my University classes, I have seen the value that design patterns, and taking consideration to layout and structure can bring to a program.

I think that following a structure or a framework of some kind can definitely bring some much-needed order to what would previously have been organized solely by necessity and convenience. Without a design pattern, my code would often be organized based purely on instinct and whatever seemed easiest in relation to the particular functionality I was currently in the process of implementing, without taking into account the effects this would have on the rest of the project.

This brings me to an article I found relevant to the topic, a post from the personal blog of a software developer (https://madhuraoakblog.wordpress.com/2017/03/01/design-patterns-revisiting-gang-of-four/) which talks about each of the different Gang of Four design patterns, (of which I was surprised to learn there are a total of 23). This post goes into sufficient detail for each of the different design patterns, without inundating the reader with excessive information. The author provides a simple explanation of each of the design patterns originally presented in the book Design Patterns: Elements of Reusable Object Oriented Software. Many of these patterns were unfamiliar to me with the exception of the creational patterns and maybe half of the structural patterns, which I had worked with for class assignments prior.

Of these 23 design patterns, I want to highlight one specifically which stood out to me in terms of versatility and overall usefulness.

Bridge pattern

The bridge pattern is used to separate an abstract class or method from the class implementing it, by using inheritance/hierarchies. The example given by the author is of an abstract feedback class, with two sub-classes: questionnaire and comment, with each utilizing the same variable reviewable which was previously defined by the parent class, thereby acting as a bridge to separate the sub-classes from each other (both can be changed without it having any effect on the other as a result of the separation). I think this concept is useful because it keeps sub-classes notably separate from each other, while allowing them to each retain important aspects from the parent abstract class, so you can have each subclass be completely different besides the bridge aspects of the program which link them together.

I can see this being especially useful in programs where there are large amounts of specific functionalities added on to more centralized base abstract classes which define boilerplate functions and basic attributes.

Overall, I think that the Bridge pattern will likely be useful to me in the future, and combined with another pattern like decorator could be used to build a program with highly specific sub-classes which elaborate on functionalities defined in a central base abstract class. I believe this combination would be helpful in building GUI style projects, word processing applications, or anything where high flexibility and customizability is warranted.

Post Referenced:

https://madhuraoakblog.wordpress.com/2017/03/01/design-patterns-revisiting-gang-of-four/

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

Whenever I find myself working on a website, one of the more time-consuming aspects of development is often the CSS (cascading style sheet) code which controls the layout of the site. While CSS properties often have names which are self-explanatory the various formatting tools in CSS can oftentimes be confusing to me.

In the past, using the float property and various div classes to control different sections of the website was my go-to when building webpages for practice. This has since been proceeded by a number of new layout systems now baked into CSS functionalities as more recent versions of CSS have worked to better support modern web-development concepts. As I am looking to improve and modernize my web-development skills to prepare for contract work in the future, it was important that I start looking into the newer layout systems provided by CSS.

The newest layout system introduced by CSS, CSS Grid, is a fairly recent invention. I was looking for a good reference to introduce me to the idea, and I found a great resource on the website css-tricks.com (https://css-tricks.com/snippets/css/complete-guide-grid/), which focuses on providing relevant information regarding various CSS standards and techniques. The article provides a complete introduction to the idea of Grid, starting with it’s various properties (display: grid to begin using the layout, various grid-template properties and grid-column/grid-row to control the particular layout of content) and moving further to discuss more specific techniques associated with Grid. I felt that the information about defining gutters (spaces between grid items) was extremely helpful, as gutters vs. borders in web design has been a hard topic for me to wrap my head around for a while, and this page put it into a really easily-understandable format in my opinion.

CSS grid is absolutely what I would use for a modern website design if I were making a site for someone in 2020. Although there exist frameworks such as Bootstrap and Skeleton, a lot of the inner-workings of the page and its layout can be obstructed in a way, and I feel like Grid makes it easy enough to make a great layout without relying on an external framework. Keeping things simple in web-design has always made for a more manageable website in my experience. I would certainly recommend this article to anyone looking to explore CSS Grid as a layout option for a website, the plentiful examples and images make concepts easy to visualize, and the explanations provide a good level of information without seeming overwhelming to someone unfamiliar with the topic.

With CSS grid, I think web-development (in terms of front-end) has become much more accessible, and building a functional and aesthetically pleasing website has become far easier than in the past when reliance on outdated layout formats made things a lot more difficult.

Site Referenced: CSS-Tricks.com

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