What is a Rest API? Well first lets discus what an API is. Application Programming Interface, API, enables to applications to communicate with each other. The example given in the blog post is when you visit a webpage your browser sends a request to the server where the site is located, and their API is what receives the request and interprets it. What is useful about APIs is that large companies can give access to their code in an API for developers to use and implement in their programs. An example would be using Google maps API to build a navigation application. Essentially APIs are a public extension of code that developers can use.

                Then what is a REST API? Well REST stands for Representational State Transfer and what that means is creating an API that has a specific rules for developers to follow. According to the Blog post those 5 rules are:

  1. Client-server architecture. The API should be built so that the client and the server remain separate from one another. That way they can continue to develop on their own, and can be used independently.
  2. Statelessness. REST APIs must follow a ‘stateless’ protocol. In other words, they can’t store any information about the client on the server. The client’s request should include all the necessary data upfront, and the response should provide everything the client needs. This makes each interaction a ‘one and done’ deal, and reduces both memory requirements and the potential for errors.
  3. Cacheability. A ‘cache’ is the temporary storage of specific data, so it can be retrieved and sent faster. RESTful APIs make use of cacheable data whenever possible, to improve speed and efficiency. In addition, the API needs to let the client know if each piece of data can and should be cached.
  4. Layered system. Well-designed REST APIs are built using layers, each one with its own designated functionality. These layers interact, but remain separate. This makes the API easier to modify and update over time, and also improves its security.
  5. Uniform interface. All parts of a REST API need to function via the same interface, and communicate using the same languages. This interface should be designed specifically for the API and able to evolve on its own. It should not be dependent on the server or client to function.

When using a REST API you will be using predefined features like: GET, POST, PUT, or DELETE followed by a root path to call those features on and then fill out the body if the feature requires it. With this you can easily fill a data base or call on other features of API. This Blog post looks to use the WordPress API which I will look into and see if I can get to work.




Well Halloween has come and gone and you know what holiday is next.  Thanksgiving that’s right and you need to decorate quickly before it is time to switch to Christmas decorations! Well if you had to do something similar in the coding world you would use the Decorator design pattern. The decorator design pattern is a design blueprint that seeks to eliminate complex hierarchy’s and allow the programmer to define the object at run time. The upside to the decorator pattern is the easy of adding new components. You essentially create an object as an interface and then create extensions of the object through a decorator class that implements that interface. Which allows you to set all the methods, or information that you want the object to have like price, or description and define that addition price or description with a decorator object. To visually think about this design pattern you can think of a rubber band ball. It has one bouncy ball in the core that is the interface, and each rubber band added to the ball is surrounding that interface object the ball. As you add more rubber bands the object is still a ball, but it is “decorated” in rubber bands. The rubber bands are now an additional quality of the ball, and extension of the ball.

Consider now your house the dining table if you wanted to create a decorator pattern for the table for the next two holidays you could do it easily with the decorator pattern. Your base object or interface would be the table. From there how you decorate it is up to you if you create a thanksgiving table cloth object you can at the time of creating the table add the thanksgiving table cloth in the creation of the table. Then when you are ready for Christmas on November 23 at 00:01 you can just create a Christmas table cloth decorator object and apply it at runtime for it to be added to the table. Then additionally you can create other decorations to be added and you don’t even need to delete the class for the code to work you simply just don’t need to call it at run time.

Overall the decorator pattern helps to avoid an inheritance tree that relies heavily on the parents. This lets you define objects that may or may not be used and call them at run time to decorate your object. For additional information you can check out the link below for additional research that I have done on the topic of the decorator pattern.


The Automatic Test Pyramid

Ham Vocke in his blog about The Practical Test Pyramid says “Traditionally software testing was overly manual work done by deploying your application to a test environment and then performing some black-box style testing e.g. by clicking through your user interface to see if anything’s broken. Often these tests would be specified by test scripts to ensure the testers would do consistent checking.



It’s obvious that testing all changes manually is time-consuming, repetitive and tedious. Repetitive is boring, boring leads to mistakes and makes you look for a different job by the end of the week.”



From this thought you ask yourself how you can make something boring not boring. Well as a great computer scientist you decide to “pawn” that work off on the computer. This automation was thought up by Mike Cohn in his book Succeeding with Agile

Mike Cohn’s original test pyramid consists of three layers that your test suite should consist of (bottom to top):

  1. Unit Tests
  2. Service Tests
  3. User Interface Tests

Although this pyramid can be overly simplistic it still serves as a good rule of thumb to follow when establishing your own tests. The names of the layers may not stand out to everyone specifically Service Test, but given the shortcomings of the original names it’s totally okay to come up with other names for your test layers, as long as you keep it consistent within your codebase and your team’s discussions.

Ham Vocke offers an extremely detailed and long blog entry that goes into much more detail. I plan to introduce more ideas from this blog as a continuation, but the main idea to grasp from this first post is the idea of automated testing, and introduce the metaphor of the pyramid. If you want to read ahead of my post check out his entry at the link below.

-Computing Finn

Andrew Finneran




Keep it Clean for the Rest of your Team.

While reading Petri Kainulainens blog (https://www.petrikainulainen.net/writing-clean-tests/) it reminded of something we had learned in class. What we were told was keeping clean and concise names is vital to the testing process. This is reiterated in the blog by Petri clean code is described as a universal understanding of the code for everyone involved. What happens is everybody can create code that makes sense to them, but words can mean something completely different. I think a good example of this would be the use of acronyms if you use GCD to get the greatest common divisor but don’t clarify this of course you can make sense of it, but what about the programmer that comes to write code for your test? This is where the problem would come into play, and the importance of clear code is vital. Along with the avoidance of confusion Petri makes two more points:

  • If our tests are easy to read, it is easy to understand how our code works.
  • If our tests are easy to read, it is easy to find the problem if a test fails (without using a debugger).

On the post is also offered a list of other blog post about writing clearly that I plan to explore at a later date. However the reoccurring theme is short, clear, and concise is the best way to write your tests. Through the tools offered by Petri, and further knowledge learned in class I plan to evolve my testing clarity to be immaculate. After all if you keep it clean it’s in the best interest of the rest of the team.


Stick to the Plan Stan

               Coding is at its very core an art piece. If we think of coding as a work of art why is it that some people expect to sit down and code a “master piece” in one sitting without thinking about what they want to code. True art take meticulous planning; sketches, rough drafts, concept art, and experimenting are things that make paintings and art so perfect in their final form. What needs to be don’t to make a programmer an artist?

                Well with our recent focus on UML diagrams it got me thinking about a similar planning stage to coding like that of an artist. After all UML diagrams show code as an image and flow chart in an eye pleasing way. With a bit of research I found that a lot of coders, and teachers believe that planning before writing code is much more effective than just trying to get it done as you go. I stumbled upon Khan Academy which is a website that I have always respected and thought highly of. Anytime I have problems or questions with any subject Khan Academy was always my go to for information. When I saw that Khan Academy actually had a lesson plan for how to set up coding before writing any code I was intrigued. Turns out like their other lesson plans the steps were all set up clean and backed with reason to why this strategy works.


Khan Academy laid out these steps that I believe when thinking about your coding structure can really help:

1. What do you want to make?

2. What technology will you use?

3. What features will it include?

4. But what features must it include?

5. How will you implement it?

6. What’s your timeline?

                I believe planning is important to the success of your code. The examples that Khan Academy use look similar to a mock UML diagram. You come up with the function each class will need the variables, and don’t implement them, but rather conceptualize what your code should do. The author offers a sample of what the concept would look like. Disregarding abstract and interface classes the layout would be easy to transfer to a simple UML rough draft.


  • Brick (.isHit())
  • Paddle (.move())
  • Ball (.move())


  • Start
  • Game
  • End


  • Ball-brick collision (function, use bounding box)
  • Paddle-ball angling (function, invert angle)

User interaction

  • Keyboard-paddle movement (keyPressed)
  • Buttons for scene changes (mouseClicked)

User data

  • Ball deaths (array)
  • Ball hits (array)

In the end I think the information we are learning about UML Diagrams, and keeping neat and organized work flows is vital to thinking about planning out your code. Create a plan and stick to it Stan.


-Computing Finn

Programmers Hate Him: The Top Coding Trick You Have To Know!

Recently I have been creating coding projects, and ideas of my own in my spare time. Currently I am working on a text based RPG that revolves around one character you, and trying to save the princess. Cliché I know. Right now it doesn’t stand to be much more than a few methods that I have begun to write. The end goal would be a combat system, multiple “branches” of story line to go down, character enhancement, and much more. A daunting, but simplistic task that I look forward to working on. A strategy that I am implementing, and that top coding trick, is TDD or Test Driven Development.

Test Driven Development is a way of programming that involves writing your test methods before writing your actual code. Ideally you would know everything you want your program to do and be able to write all the tests for all the features you plan to implement.

                FOR EXAMPLE

If I was creating an addition program that took two inputs. I would first create a test class that would input 2, and 2. Then the expected outcome would be 4. From here I would go create my actual program and if the test passed then my method would be working correctly.

What I find particularly appealing about this type of programming is that you can catch mistakes much earlier than if you coded everything, and built the tests after. It saves time overall, and also helps keep you focused on objectives that you have to complete.

In regards to my experience I have adapted it in a slightly different way. I will write one test, then code, and then repeat that same cycle until I am finished. What this does is helps me be able to avoid having to go back and rewrite lines, and lines of code. The coding method of TDD is something that surely interests me, and I look forward to increasing me knowledge, and honing in on it as a skill that will benefit all my future endeavors.

If you care to find out more information on Test Driven Development you can visit the website below.




Custom Library Making Life Too Easy?

Post Referenced: https://keaplogik.blogspot.com/2013/04/java-developers-need-to-be-using-lombok.html

This particular post is in reference to the java library Project Lombok, and can be downloaded here https://projectlombok.org/download completely free. The tool can also be supported by donations and directly through their patreon page https://www.patreon.com/lombok.

Billy Yarosh describes Lombok as “a java library meant to simplify the development of Java code writing.  He then goes on to show an example of the library in use:

public class Animal {

    private String name;

   public String getName() {       

   return this.name;    


public void setName(String name) {       

this.name = name;   



With the use of the Lombak library you can turn all of that code into something much smaller:

public class Animal {    

@Getter @Setter private String name;


I was impressed at the simplicity that this library would bring to the java language. As I always thought that Java was a bulky code that had a lot of writing involved. Especially since learning C I think about how overly complicated Java can be. The question that I raise is: does a library like this promote laziness, or does the good outweigh the bad? Personally I think a library like this is the perfect thing to have in your coding “arsenal” because it would save you valuable time to achieve the same result. However I do think that it would be important to still learn the original Java created form first, and master that understanding before using the library. Lombak should be used as a shortcut to pass monotonous material that adds up, and not to just do something easier.


Other advantages that Billy lists are as follows: “

  1. No more overriding toString
    • We can now annotate our class with a @ToString and lombok will override our toString method and print out the classes fields.
  2. No more overriding equals and hashCode methods.
    • Annotate class with @EqualsAndHashCode for easy generation of equals and hashCode methods at compile time.
  3. Generates constructors based on class annotations.
    • @NoArgsConstructor used for creating a no argument constructor.
    • @RequiredArgsConstructor used for creating constructor that takes one argument per non final/ non-null fields.
    • @AllArgsConstructor used for creating constructor takes in one argument for every field.
  4. Use @Data shortcut for @ToString, @EqualsAndHashCode, @ RequiredArgsConstructor, and @Getter / @Setter (on all non final fields). ”


Learning of a tool like Lombak has me thinking of the other libraries that may be out there to help save programmers time, and plan to look into them more in the future. Have you had any experience with Lombak, or other libraries? What were your thoughts on them?

-ComputingFinn (CS 343)