Author Archives: kylequad

Angular Components

This past week, I began to work with REST API frontend code
using the Angular framework in CS-343. The introductory class activity taught
the basics about setting up and working with an Angular project as well as some
useful properties of Angular (such as *ngIf) that I definitely see myself using
in the future. However, the activity did not go into much detail about how to
create and manipulate Angular components to create more interesting UIs. While
researching Angular on my own, I came across a blog post from Angular
University titled “Angular Components – The Fundamentals.”

The blog can be found here:

As someone who has enjoyed creating UIs in Java using Swing
components, this blog immediately caught my attention. I expected it to help me
create UIs for server-based applications that would be more interesting than
the basic layout I worked with in class. However, while this blog did not go
into too much detail on the creation of UIs, it has certainly helped me to
better understand the fundamental properties of Angular components. The information
I learned from this blog will undoubtedly be useful as I begin to work more
in-depth with Angular components in my final project for CS-343. I decided to
share this blog because I think that others who are new to Angular will also find
it to be a useful introduction to Angular components.

The blog starts by providing a basic introduction to Angular components, as well as browser components in general, using short example code. It then discusses in detail the two main aspects of an angular component, properties and events, and explains when to use them and when to avoid using them. I think the blog did a great job explaining properties and events in simple terms and clearly stating when not to use them. I especially liked how the blog links properties and events to input and output, respectively. This association helped me understand when to make use of properties and events in Angular projects, since I already have experience working with input and output of components in Java. I also think the example code in this blog is simple enough that it can easily be referenced while working on other projects. I certainly see myself referring back to these examples as I start working with Angular components on my own to help myself understand the correct syntax for implementing properties and events. Finally, this blog has demonstrated to me how to create familiar components, such as a scrollable list, and it has taught me how to change aspects of components, such as their color. The information in this blog has helped me understand the fundamentals of Angular components and how to work with them in applications. I will certainly be referring back to this post as I begin to work on my final project this week, as it is a great resource to help new Angular developers to understand Angular components.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

The Single Responsibility Principle

Several weeks ago, we briefly discussed the SOLID design
principles in CS-343. This discussion was supposed to lead into a homework
assignment where we would research a couple of principles, but since this never
happened I decided to research a SOLID principle for a blog post instead. In
this post, I will be focusing on the Single Responsibility Principle, or SRP
(the ‘S’ in SOLID). This principle declares that a class should have only one
reason to change, or in other words, a single responsibility. It sounds like a
simple concept, but actually implementing it can be challenging. My research
into the SRP helped me come across a blog post by Patrick Smacchia titled “SOLID
Design: The Single Responsibility Principle (SRP),” which defines guidelines
that may help make the principle easier to follow.

The blog can be found here:

In the blog, Smacchia explains that the SRP is not as simple
to follow as it sounds, because different programmers may define a responsibility
or a reason to change in different ways. For this reason, he approaches
the principle based on its fundamental purpose of determining which logic
should be in which class. From this approach, he explains several aspects of
the SRP using example code, and he provides a set of concrete guidelines that
can help enforce the principle. I chose to share this post because Smacchia’s
approach to explaining the SRP has helped me understand it better by getting me
to think about it from a more fundamental perspective. I also think his
guidelines would be useful to any programmers, myself included, who intend on
following this principle in their projects.

I certainly intend on referring back to the guidelines
included in this blog to ensure that my future projects follow the SRP. Although
there are a couple I don’t fully understand, such as the one on POCO classes, I
think the others will greatly help me adhere to the SRP. His suggestion to keep
logic related to different functions separated into different classes makes
sense thanks to his Employee example, which I will refer back to when deciding
which functions should be separated into different classes. I found Smaccia’s
discussion on cohesion especially interesting because it exposed me to the Lack
of Cohesion Of Methods metric, or LCOM, which is used to actually quantify how
cohesive a class is. It surprised me that a more complex class can have a lower
LCOM score than a simpler one, and that a class’ simplicity does not represent
its adherence to the SRP. I will definitely refer back to this blog to help me
ensure that my own classes keep a low LCOM score even as they grown more
complex as a way to follow the SRP. I have certainly had issues with classes
getting too large and doing too many things in the past, and I think learning
more about the SRP from this blog will help me avoid this problem in the future.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Adventures in TypeScript

This week in CS-343, I was introduced to TypeScript, a
scripting language that uses typed variables to prevent coding errors caused by
mismatching data types. My introduction to TypeScript was my first time working
with a scripting language, and I am really looking forward to learning more
about it and using it to write new kinds of programs. However, the tutorial I
did in class was rather simple, as it only showed how to set up a basic project
in TypeScript. To learn more about this new language, I decided to research
TypeScript’s other features. I eventually came across a useful blog post by
Nwose Lotanna titled “New Features in TypeScript You Didn’t Know Exist.”

Link to the blog:

As the title suggests, this blog post discusses several
features of TypeScript that were introduced between versions 3.0 and 3.4. Each
feature has a short description that explains why it is useful, and many are
also demonstrated using example code. The post seems to be targeted at developers
who are experienced with TypeScript, which made it difficult for me to
understand every feature it discusses. However, there are a few features listed
in the blog that I could definitely see myself and other newcomers to TypeScript
making use of even in simple programs. I chose to discuss this blog to help spread
information on these useful but often overlooked features.

The first feature discussed in this blog is project
references. As of TypeScript 3.0, it is possible for one TypeScript project to
reference another by referencing its tsconfig.json files. This feature is
heavily reminiscent of the import feature in Java or the #include
feature in C, which have proved invaluable in my experience. Having the ability
to reference code in other files helps keep projects simple and organized, which
will undoubtedly be just as important in TypeScript as it is in other

Another feature discussed in the blog that caught my
attention is TypeScript’s BigInt object. BigInt was introduced in
TypeScript 3.2 and allows programs to use numbers greater than 253.
While I can’t recall a time where numbers that large were necessary, it is nice
to know that the option exists in TypeScript. There are certainly potential
uses for such large numbers, such as the Fibonacci function that Lotanna uses
to demonstrate the feature. Should I ever need to write a program that uses
numbers of this magnitude, I would certainly take advantage of TypeScript’s BigInt

A third TypeScript feature that I expect to be useful is the
const assertion. Since TypeScript 3.4, it has been possible to declare
arrays and objects as read-only constants using the syntax demonstrated by the
example code in the blog post. Though the syntax is different, this feature
seems to function just like C’s const and Java’s final keywords.
Having used these features frequently, I expect TypeScript’s const
feature to be useful in many programs to ensure that the values of certain variables
cannot be changed.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.


The latest in-class activity from CS-343 introduced me to Representational
State Transfer (REST), which is an architecture used by Client-Server APIs. The
activity was helpful in explaining standard HTTP methods which are used by REST,
specifically GET, PUT, POST, and DELETE, but it didn’t really focus on
explaining what REST actually is and how APIs that use it are structured. For
this reason, I decided to further look into the fundamentals of REST and how to
use it. While researching, I came across a blog post by Bivás Biswas titled “How
not to blow your REST interview.” The post can be found here:

While this blog does indeed give interview tips, it also helps
explain REST and the design principles it follows. Biswas focuses on five main
principles of REST that RESTful APIs follow, which include the contract first
approach, statelessness, the client-server model, caching, and layered
architecture. I chose to share this blog post because its organization of its
information on REST helped make it easy to follow and understand. For this reason,
I think the blog is an excellent resource for learning about REST, and I could
see myself coming back to it as a reference if I work with REST in the future.

I liked that Biswas opened the blog by acknowledging common
misconceptions about RESTful APIs that he has heard in interviews. One of these
misconceptions was that RESTful APIs simply follow the HTTP protocol, which is
a misconception I may have developed myself due to the aforementioned class
activity being focused on HTTP. The fact that this was immediately stated as
incorrect helped indicate to me that REST was more detailed and complex than I
understood from class.

I also thought that Biswas’ approach to explaining the five
principles of REST was particularly effective. He makes use of analogies and
examples to demonstrate each concept instead of relying on technical terms that
newcomers to the topic, such as myself, would likely not understand. For
example, he explains the contract first approach with a mailbox analogy by
suggesting that applications can get the same data without changing URIs in the
same way that people can get their mail without changing mailboxes. Similarly, layered
architecture is explained by comparing an API’s Gateway layer to a bed’s
mattress. Much like a bed frame can be changed without affecting how the
mattress feels, changing the fundamental layers of a RESTful API does not
change how applications interact with the API’s Gateway. Analogies and examples
always help make complex concepts easier to understand for me, and their use in
this blog greatly helped increase my understanding of REST and its 5 core
principles. I am by no means an expert on REST just because of this blog, but
it has certainly helped prepare me to learn more about it in the upcoming class

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

The Singleton Design Pattern

Recently in CS-343, I have been introduced to the concept of
design patterns. These are essentially code-writing techniques that help make
code easier to describe, modify and maintain. There are a wide variety of design
patterns, each with different benefits and drawbacks. My last class on Thursday
ended as we began to cover the Singleton Pattern, and so I decided I would look
into Singleton in advance of our activities next class about it. My research
led me to Andrew Powell-Morse’s blog post “Creational Design Patterns:
Singleton,” which can be found here:

This post, as you may expect, is focused on explaining the
Singleton pattern to the reader. Powell-Morse accomplishes this by using real-world
analogies to describe the concept of Singleton and a programming example to show
how the pattern can be implemented in code. I chose to write about this blog
not only because it explains Singleton well, but also because I found the
programming example interesting. The purpose of the Singleton pattern is to
ensure only a single instance of certain classes can exist at a time, which Powell-Morse
clearly states right at the start of the blog. This is a simple enough concept
to grasp, but Powell-Morse elaborates further by explaining that Singleton
should be thought of in terms of uniqueness rather than singularity. He uses real-world
examples of uniqueness, those being individuality in people and a unique deck
of cards used for poker games, to describe situations in which Singleton can be
useful. These examples, especially the deck of cards, have helped me understand
that Singleton is useful in programs that only require a single instance of a
class, and I could definitely see myself applying this concept in future
projects to help reduce memory usage from unnecessary objects.

Since I found the deck of cards analogy especially helpful, I was pleased to discover that it was the focus of Powell-Morse’s programming example. However, the example’s complexity made it somewhat difficult to understand at first. Instead of simply demonstrating how Singleton is coded, Powell-Morse applies the concept to a program using multiple threads that separately remove card from the same deck instance. I have not written many programs myself that use multi-threading, and this lack of experience made the example confusing initially. The example is also written in C#, which is a language I am not nearly as experienced in as I am with Java. Despite my initial confusion, I eventually understood the example and grew to appreciate its complexity. The use of multi-threading in the example helped demonstrate a major drawback of Singleton and how to work around it in C#. The example not only taught me how to implement Singleton into my future coding projects using static variables, but it also showed me how to work around Singleton’s issues with multi-threading. This blog post also taught me more about a language that isn’t Java, which is always welcome.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

About This Blog

Hello, and welcome to my new blog!

As you might expect from the title, I will be using this blog to make posts about Computer Science. I have specifically created it for use with the following courses at Worcester State University:

  • CS-343: Software Construction, Design, and Architecture
  • CS-443: Software Quality Assurance and Testing

As such, for the time being, I will mainly be posting about software development! My interest in software development was the main reason I became a Computer Science major, and I am looking forward to discussing a topic I enjoy while attempting to blog for the first time. It should all be very exciting, so be sure to look forward to my future posts!

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.