With CS 343’s final project beginning, I have looked into some ways of displaying data. For this week, I will focus on Angular’s CDK. In Netanel Basal’s article “Creating Powerful Components with Angular CDK,” Basal describes the process of making an overlay in angular. He starts with creating a Popover service, Popover being a component from the CDK. This component is used for creating popup overlays, such as info that pops up while the mouse is hovering over something. Basal then creates the PopoverRef and its Injector. The PopoverRef is then injected into a ComponentPortal which is then attached the origin page. Portals dynamically render UI to the page. For the portal, the author creates a custom component to receive the contents to be displayed and how to render them. The article then covers three types of content the PopoverComponent can receive: text, template, and component. With that, the article’s example is completed. Now let us get a little more in-depth.

Let’s start with the Popover service. This service creates an
open() method that creates the overlay, its contents, and its injector. This
service is injected into the Popover component, where the open() method is
utilized in a show() method in the app component that is called on when a
button is clicked in the root component HTML. From what I understand, this
service handles the creation of all the parts needed to make the popover with an
open() method.

Next up is the PopoverRef, a class that receives a
overlayRef, content, and data, and creates a close() method to dispose of the
overlay. It seems that this class is used for the storage of the parent
overlay, the content, and the data, and the close() method that removes the popover.

Since Basal wanted to use a custom component, he needed to
create an Injector for it. The injector is created in the Popover service in a
createInjector() method, which converts the custom injector to a PortalInjector.

The author then attaches the soon-to-be-created Popover
component to the overlayRef in the popover service. This is done by overlayRef’s
attach() method, where a new ComponentPortal containing the PopoverComponent is
attached to the overlayRef.

The Popover component’s job is simple, just to inject the
popoverRef and render its contents. This article’s example provides multiple
rendering methods depending on content type. The three content types being template,
component, and text.

For all three types, a show() method is added to app
component that injects PopoverComponent and creates a Popover from popover service.
The only difference between the content type’s show() is what the content in
Popover is set to. This method is called on in the app component’s HTML where
it is attached to a button.

Reading through this article and examining its code has helped me towards learning how to create popup overlays. I feel I have a more solid grasp of how angular components interact with each other. I will undoubtedly use knowledge I gained from the article, “Creating Powerful Components with Angular CDK” by Netanel Basal, in my final project.

Article Referenced:
https://netbasal.com/creating-powerful-components-with-angular-cdk-2cef53d81cea

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

For this week’s post I read through Michael Karén’s article, “Game Development: Tetris in Angular.” As the name suggests, this article demonstrates how to make a Tetris game in Angular. This is a great example project that shows many of Angular’s functionalities without being too complex. It covers topics introduced in CS 343: components and templates, and other topics like styles and event listeners. The author’s project code can be viewed on GitHub for further examination.

The project contains three components (with @Component
decorator): app, board, and piece. The app component is the main component that
uses the board component as a template. The board component handles the board
UI and injects the game logic from GameService. And lastly, the piece component
handles the UI and properties of the Tetris pieces.

Templates are used in two ways in Karén’s game. The app-root
which uses another component as its template by using the custom tag
<game-board></game-board>. The game-board uses a URL as a template,
which is defined in the board component’s HTML file. This HTML file defines how
both game-board and, by extension, app-root are rendered on the page.

The injectable class (with @Injectable decorator)
game.service contains much of the game logic. As an injectable, game.service’s
methods are accessible to board.component when game.service is injected in
board.component, located at the example code’s line 72 with “constructor(private
service: GameService) {}.” This is useful as it is cleaner to separate the responsibility
of the game logic and the UI logic from each other.

The styles are defined in a Cascading Style Sheet or CSS file.
The CSS file is used to define how some of the HTML elements are designed. CSS makes
HTML design simpler with its more intuitive interface.

I learned a new decorator from this article, @HostListener.
This decorator can be used to define the program’s response to user
interaction. In this article’s project uses @HostListener to define how the game
board responds to the specified keystrokes.

The JSON methods stringify and parse were also new to me. JSON.stringify will convert an object into a string. JSON.parse on the other hand, converts a string into a JSON object.

Reading through this article and examining the project’s
code has helped my understanding of Angular and HTML tremendously. I recommend Michael
Karén’s article, “Game Development: Tetris in Angular,” to those who are
looking for a fun example of an Angular program.  Being able to see all the parts of the
program and how they work together has made Angular more accessible for me and
has provided an excellent resource for possible projects in the future.

Article referenced:
https://blog.angularindepth.com/game-development-tetris-in-angular-64ef96ce56f7

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

The topic for my post this week is Angular. CS 343, Software construction, design, and architecture, introduced REST API frontend last week. I did not have a good grasp of what Angular is, so I read the article “Angular Tutorial: Getting Started With Angular 4”, by Shubham Sinha. The article breaks down Angular into easy to understand parts which are then explained thoroughly.

The article begins with describing the general history of
Angular and why it was designed. Originally AngularJS, Angular was designed for
the use in designing SPAs (Single-Page Application). SPAs are useful as they do
not require an entire page to be refreshed. Instead SPAs only refresh necessary
components. This allows for SPAs to act similarly to desktop applications.

The article then begins its tutorial, though I would describe
it as an overview of the details of Angular projects. The author goes into the
different parts of Angular and describing them each in detail.

• Modules:                           
  Chunks of code with a specific task, such as classes.
• Components:                   
  Code that use API to control sections of the screen. Contains instructions for
  client-side GUI.
• Templates:                        
  HTML tags that describe how to render components.
• Metadata:                          
  The code that informs Angular on how to process a class.
• Data
  binding:                   
  The connection used to tie parts of a template to parts of a component. An easy
  connection for data state and data events.
• Directives:                         
  Logic code for manipulating data: adding, removing, changing.
• Services:                             
  A wide category for encompassing anything an application my need.
• Dependency
  Injection: 
  Allows Angular to create new instances of a class with all its dependencies
  that can be “injected” into another class.

From what I understand, the page code will be divided into
modules. The page view will be divided into components that use templates and
metadata to determine how to display the component. Directives are logic code
that manipulate data. Data binding allows for easy access to a data’s state and
events. Dependency injection inserts an instantiation of a class with all its
dependencies. Finally, services are simply anything an application may need:
value, function, feature.

I found that after reading this article I have a better
understanding of Angular. Angular can be used for client-side rendering of
data. By separating the page into several different components, Angular can create
SPAs that are dynamic and responsive. This article is informative and accessible,
I highly recommend this article to anybody who is getting acquainted to
Angular.

Referenced Article:
https://www.edureka.co/blog/angular-tutorial/

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

This week I have chosen to deepen my understanding of REST API. The article, “RESTful API Design Tips from Experience” by Peter Boyer, goes over good RESTful design practices. The article covers many topics, including some I do not have experience with but are still useful for a greater understanding overall.

The article proposes that the API should state its version
in the URLs. The author suggests adding a prefix to all URLs to specify API
version. This makes the eventuality of version updates easier to handle.

A simple tip mentioned in the article is the use of plurals.
When designing endpoints, plurals should be used instead of the singular form.
This is to avoid possible misunderstandings of what the endpoint is used for.

Example:             /orders/customers          VS           /order/customer

Another tip in the article is to use nesting for
relationship filtering. From what I understand, it is better to have multiple
path variables for filtering than the use of query strings. The example in the
article is very clear on the tip. Following this advice will make your
endpoints easier to read.

The author advises to keep your API as flat as possible. He
suggests that creating and fetching data should have a longer resource path
than updating and deleting data. I do not really understand why this is the
case. My best guess is the shorter path reduces unnecessary processes.

The next tip I found interesting was the important, if not
obvious, idea for pagination of results. When working with larger databases, requests
can have thousands of results. Since it would be impossible to display all the
data, it makes sense to partition the results into pages and return one page at
a time. Pagination can also significantly reduce the expense of a request.

The last tip I will mention from the article is the usage of
status codes.  HTTP status codes should
be used consistently and properly. This means the status should use the proper
code and provide additional details when necessary: an error code with a
message of why the error occurred.

Overall, I found Boyer’s article to be very informative. I
only mentioned a few of the topics raised in his article but all the topics are
interesting and useful. Reading through this article gave me a better
understanding of the nuances of RESTful API design and has helped me comprehend
my current coursework (CS343) better. I suggest to anybody that is new to REST
to read this article.

Article Referenced:
https://medium.com/studioarmix/learn-restful-api-design-ideals-c5ec915a430f

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

For this week’s blog, I have decided to go over the SOLID set of design principles. The blog article “SOLID design principles: Building stable and flexible systems” by Anna Monus describes SOLID and gives solid examples of each design principle with code and UML diagrams.

Single responsibility

Each class should only have a
single responsibility, such as handling data or executing logic. While this
increases the number of classes in a program, this will allow easier
modification of the code and code clarity.

Open/Closed

Classes should be open to extension
and closed to modification. This means that new features should be introduced
through extension and not through modifying existing code. The open/closed
principle allows programs to expand with new features without breaking the old.

Liskov substitution

Named for its creator Barbara
Liskov, the Liskov substitution principle states that a subclass should be able
to replace its superclass without breaking the properties of the program. This
means that a subclass shouldn’t change its superclass’ characteristics, such as
return types. Following this principle will allow anything that depends on the
parent class to use the subclass as well.

Interface segregation

Interface segregation states that
classes should not have to implement unused methods from an interface. The
solution is to divide the interface so that classes can implement only the
desired methods. I found this principle to be easier understood from a visual
example and I found the article’s UML diagram for interface segregation useful
for this.

Dependency inversion

High and low-level modules should
depend on abstractions. It is common to think that high-level classes should
depend on low-level classes, but this makes expanding the code difficult so
it’s best to have a level of abstraction between the two levels. The article’s
UML example for this principle shows how the abstraction level allows for easy
expansion.

The SOLID principles are important for code architecture as
it makes code expansion simple and easy to understand. I have found myself
applying SOLID principles to a project I have been playing with, a simple GUI
animation. Originally, I had drawn objects handling their own draw and movement
methods, but by using the single responsibility principle I separated the
movement-based code to its own class and used composition between classes. This
allowed for me to be able to use the movement code (contains position,
velocity, and acceleration values and methods) for all the different objects
that I make. I also made use of the O, L, and D of SOLID to handle the drawn
object hierarchy allowing my frame class to depend on an abstraction of all my
drawn objects. I use a loop to cycle through all drawn objects in a linked list
that’s type is an abstraction of all drawn objects. I can tell that the
structure of the code has made adding new functionality easy and intuitive.

Article Link:         https://raygun.com/blog/solid-design-principles/

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

The article, “REST vs. RESTful: The Difference and Why the Difference Doesn’t Matter,” examines the Representational State Transfer pattern, or REST, and its implementations, RESTful services. The author, Eric Goebelbecker, mentions REST pattern’s creator Roy Fielding, and provides a link to Fielding’s dissertation.

 The article then
defines REST’s architectural constraints. Client-server architectural style,
separating responsibilities between client-side and server-side. Client-side
will handle user interaction while server-side will handle data and state. This
allows for the two sides to evolve independently of each other. Stateless, the
server is not responsible for a client’s session state and instead, the client
keeps the session state. Cacheable, the server must classify their responses as
cacheable or not. This improves performance by allowing the client to store
cacheable responses for later, equal requests. Uniform Interface, possibly the
most important constraint, requires the use of a uniform interface for
components. This simplifies the architecture by taking advantage of the
software principle of generality. The final constraint mentioned in the article
is a layered system. A layered system is a hierarchical system that
encapsulates components to layers that can be independent of each other. This
can be used for security and performance such as load-balancing. These five architecture
constraints are what defines the REST pattern.

The article then gives an example between remote procedures
calls (RPC) and REST. The difference being that RPC manipulate data by remote
calling the server functions and REST, instead, shares the data between
client-server. Put simply, in REST the URIs work with data and not remote
methods.

The article then mentions the Richardson Maturity Model.
Richardson’s model classifies RESTful services into four levels of compliance. Level
0, the use of RPCs. Level 1, sharing resources between server and client. Level
2, the proper use of HTTP verbs. And level 3, exporting hypertext with objects
to aid with API discoverability. The author of the article brings up that Fielding
would only consider level 3 to be true REST.

Before I read through this article, I had only a rudimentary
understanding of the REST pattern (I had missed the class that introduced it).
I now understand REST and RESTful, the architectural pattern and its
implementations. REST focuses on data sharing and a uniform interface to make its
data the emphasis of the pattern and not its specific implementations. This
allows for easier understanding with generality and assists with scalability.

 I read some of
Fielding’s dissertation and highly recommend it to anybody who is learning REST.
The descriptions of the architectural constraints are clear and provide simple
examples.

LINKS:
Article: https://blog.ndepend.com/rest-vs-restful/
Fielding’s Dissertation: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.