Last week in CS-443, we did a class activity on static testing tools. These tools are able to detect issues in a program without executing the code. Previous activities had focused on dynamic testing, which does involve code execution, so static testing was definitely new to me. However, I had a hard time learning about the tools due to problems I had with the activity. One of its early parts involved building and running a batch file for the project we were working with. This batch file refused to run properly on my computer, so I was unable to progress with the activity and thus did not get to work with the static testing tools for myself. I observed what my group’s technician did with the tools, and it was interesting to see them in action, but I had a hard time understanding what the tools were doing since I was not working with them myself. Today, I decided to address this problem by revisiting the activity on my own and doing extra research into static testing.

Unfortunately, I was unable to get the batch file to run on my computer. No matter what I tried, it always failed to find or load the main class of the project. After about an hour of messing with file directories, I decided it was not worth spending more time trying to get the batch file to work. I was able to run the project using the gradle run command, and I decided to move on so I could actually try working with a static testing tool. The tool I worked with was Checkstyle, which looks over the code and makes sure it complies with the style guidelines specified in an xml file. I found it interesting that the tool is fully customizable, as the guidelines it checks for can be changed by altering the xml file that the tool uses. The tool is also extremely simple to add to a project, as it only requires a few extra lines in the build.gradle file: one to add the plugin, one to state which version to use, and one to declare which xml file contains the style guidelines.

Although I was able to figure out Checkstyle, I still was not sure I understood the fundamentals of static testing. I decided to do more research instead of continuing with the activity, and I came across an article from Guru99.com about the basics of static testing and testing review. I think the article does a great job introducing the concept of static testing and explaining why and how it is used. It is from reading this article that I learned the difference between static and dynamic testing. It also explained to me why static testing is used and introduced me to different types of static testing, such as manual reviews. I won’t go into every detail about the article here, but it definitely helped me make more sense of static testing and I certainly recommend it to anyone who is also confused by it.

You can find the article here:

https://www.guru99.com/testing-review.html

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.

As there are now just a few weeks left in the semester, it
is time to start working on my final project for CS-343. This project is to
develop a Single Page Application in TypeScript using the Angular framework,
which we have been learning in class over the past month. From now until the
end of the semester, I will be making weekly posts documenting my progress with
this project and what I learn while working on it.

My final project began with a proposal, for which I was to
create a conceptual design for a Single Page Application using a wireframe. This
helped teach me how to design a layout for an application’s components before
programming it. My idea was to design a layout for a customizable puzzle game. When
it comes to software development, my main interest is in making games. For this
reason, I thought that using this project to make a basic game while also
learning about creating Single Page Applications in TypeScript would be
something I’d enjoy.

My current concept involves some kind of grid-based puzzle game,
such as minesweeper. The user would be able to interact with a variety of components
in an options menu to change the size of the grid as well as other aspects of
the game, like the difficulty and time limit. Changes made to these options
would update the main play area in real time without the need to reload the
page. I also included a help menu that would contain instructions and potentially
a hint button for extra interactivity in my proposal.

I drew my wireframe layout for this application concept on
paper. You can take a look at it right here:

I still am not certain that this is the idea I want to go
with for my project. I think it is a rather simple idea due to its lack of
communication with a back-end server. I also have yet to decide on the details
about the puzzle game itself, and I don’t know if such a game is even possible
to make with angular components. I will have to do more research about Angular
and TypeScript to help solidify my plan. Despite my doubts, I am looking forward
to learning more about writing applications in TypeScript, and I will definitely
get development started during Thanksgiving break.

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.

Recently in CS-443 I was introduced to testing using
mocking. Mock testing makes use of a mocking framework (we used Mockito in class)
to create mocks which the place of regular objects. A mock can call the methods
of its associated class or interface, but it will return a default value of 0
instead of actually running the behaviors specified in the class’ methods. It
is also possible to tell the mock to return specific values other than the
default to make sure that different methods return different results. It was
interesting to learn about implementing Mockito and working with mocks in my
projects, but there was one question that I kept asking myself: What is the
point? Why go through the trouble of setting up mocks when you could just
finish writing the code and test its actual behavior? I decided I would search
for an answer to these questions on my own, and in doing so I came across an
article by Michael Minella titled “The Concept of Mocking.”

The article can be found here:

https://dzone.com/articles/the-concept-mocking

Unlike the example in class, this article teaches mocking
and its purpose clearly and simply. This purpose, as the article explains, is
to test functions without executing other functions that they depend on. The
article demonstrates this with a simple example which includes a doLookup
method that calls a lookupByKey method. By using mocks, it is possible to test
doLookup without needing to make sure lookupByKey is also working correctly. This
extremely simple example has helped make the point of mocking much clearer to
me. It still seems better to me to write tests based on the actual code of a
project, but I can see mocking being useful in situations where the code a project
depends on is not all accessible. I think the example in class may have been
too complex an introduction to mocking, and the difficulties I had getting the
example code to work made it difficult for me to understand the basic concepts behind
mocking. The simplicity of this article enabled me to see the purpose of
mocking, which I think will make it easier for me to apply what I learned from
the class activity.

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.

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:

https://blog.angular-university.io/introduction-to-angular-2-fundamentals-of-components-events-properties-and-actions/

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.

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.

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:

https://blog.bitsrc.io/new-features-in-typescript-you-didnt-know-exist-54b7ab8d0b4f

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

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 2⁵³.
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
feature.

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

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.

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:

https://airbrake.io/blog/design-patterns/creational-design-patterns-singleton

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.