Author Archives: dlivengood

Understanding Angular with Tetris

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:

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.

Testing Doubles

When testing a system, known as the System Under Test or SUT,
the system needs to have access to its dependencies but often the access given
is just clever mimicry. Testing doubles are used to replace a system’s dependencies
with varied functionality. The article “Test Doubles — Fakes, Mocks and Stubs,”
by Michal Lipski, explains three out of five of the types of testing doubles defined
by Gerard Meszaros, fakes, stubs, and mocks. The author provides diagrams and
code examples with explanations for the testing doubles.

The first testing double described in the article are fakes.
The article provides the example of a SUT that depends on a Data Access Object
or DAO. In this case, a fake is used to replace the DAO so that the SUT can be
tested without the need of using a real database.

Stubs are the next testing double type discussed in the
article. Stubs are the simplest testing double type as they only provide canned
responses. These responses are predetermined and are used in place of actual

The last type in the article are mocks. Mocks are used for Behavioral
Testing. Mocks allow for testers to be able to verify the system is behaving
correctly, correct methods called at correct times. A simple case for a mock is
when a SUT depends on a method that does not return anything that can be
verified. The mock object will record when its methods are used, so that the
behavior can be checked.

I found the example diagrams in “Test Doubles — Fakes, Mocks
and Stubs,” by Michal Lipski, very helpful in understanding the differences of
the testing doubles. While this article does not go over two types of testing
doubles, dummies and spies, the three types that are discussed are described well.
Ultimately, when testing a system, it is imperative that the system can test
all its behaviors without relying on actual data.

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.

Getting Angular

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
    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

    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

Referenced Article:

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.

Time for some more REST

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:

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.

Getting a solid grasp of SOLID

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.


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

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:

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.

REST and RESTful

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

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

Fielding’s Dissertation:

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.

An Introduction

This blog will be a look into my point-of-view of pursuing a career in Computer Science. This blog was started as a requirement for a couple of my CS classes but I intend on using it for non-school content as well. The classes that will be referenced in some of my posts are Software Quality Assurance and Testing and Software Construction, Design, and Architecture at Worcester State University.

I am a senior at WSU pursing a Bachelor’s Degree in Computer Science. I have been to several colleges over the last decade. I took my first CS course in my first semester of my freshmen year but I did not decide to major in CS until several years later. I was very indecisive in my early college days. Music, Engineering, Astronomy, Physics, and Game Design were all potential degrees I pursued for some time. In the end, Computer Science was the perfect mix of what I am skilled at and what I am interested in.

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.