https://stackify.com/typescript-vs-javascript-migrate/

Given that we have been working with Typescript I wanted to find a blog post that compare and contrasts these languages to grasp a better understanding of their benefits. First we should define what the languages are. Typescript is an open source “syntactic superset” of JavaScript that compiles to JavaScript. Typescript offers the developer a static type checking for JavaScript to be compiled. Where JavaScript is almost the opposite of this; JavaScript uses type less variables that can be assigned any data. That is a basic understanding of the two languages that are based from Java.

From here lets discus the benefits of using Typescript language as stated above Typescript allows for the assignment of static types. This prevents complications like data being changed if not meant to, or faulty variable assignment to begin with.

An Example:

Typescript when a is an int:  a = 1;

Javascript when a is typeless: a = “1”

The thing is that JavaScript would allow you to assign the value to string 1, but Typescript would not allow you to make the same assignment. Additionally Typescript also adds other features to JavaScript like: Interfaces, Generics, Namespaces, Null Checking, and Access Modifiers.

Interestingly the blog talks about how type values are not the only reason to use typescript, or at least the exclusive reason. When deciding to use typescript the blog offers this advice:

TypeScript

• Prefer Compile Time Type Checking: It is entirely possible to perform runtime type verification using vanilla JavaScript. However, this introduces additional runtime overhead that could be avoided by performing compile-time validation
• Working with a New Library or Framework: Let’s suppose you’re taking up React for a new project. You are not familiar with React’s APIs, but since they offer type definitions, you can get intellisense that will help you navigate and discover the new interfaces.
• Large Projects or Multiple Developers: TypeScript makes the most sense when working on large projects or you have several developers working together. Using TypeScript’s interfaces and access modifiers can be invaluable in communicating APIs (which members of a class are available for consumption).

JavaScript

• Build Tools Required: TypeScript necessitates a build step to produce the final JavaScript to be executed. However, it is becoming increasingly rare to develop JavaScript applications without build tools of any kind.
• Small Projects: TypeScript may be overkill for small teams or projects with a small code surface area.
• Strong Testing Workflow: If you have a strong JavaScript team who is already implementing test-driven development, switching to TypeScript may not give you enough to make it worth the associated costs.
• Added Dependencies: In order to use libraries with TS, you will need their type definitions. Every type definition means an extra npm package. By depending on these extra packages you are accepting the risk that these may go un-maintained or may be incorrect. If you choose not to import the type definitions, you are going to lose much of the TS benefit. Note that the DefinitelyTyped project exists to mitigate these risks. The more popular a library is, the more likely the type definitions are to be maintained for the foreseeable future.
• Framework Unsupported: If your framework of choice does not support TS, such as EmberJS (although this is planned and is the language of choice for Glimmer), then you may be unable to take advantage of its features.

The author Jared Nance goes on to say that Typescript isn’t the best tool out there for coding, but presents the information as best as possible. When considering to use Typescript or JavaScript the suggested reasons above may be good guide lines in making that choice.

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

https://presencepress.presencepg.com/javascript-and-node-js-continue-to-eat-the-world-d41918a0615b

For me working with Node.js is a new and exciting journey we have ventured down. You can see from simple webapps the ability that Node.js has at influencing Javascript code. According to Dale Knauss in his blog about the NodeSummit2016 that opinion was shown as fact. As Walmart one of the largest retailers in the world primarily uses Node for its Walmart.com traffic. 98% of that traffic is directed through Node APIs. Accompanied by their sister company SamsClub who 100% of their traffic is through Node. The exclusive use by such a massive company surly speaks for the viability of Node. The reason that Walmart is exclusively using Node is so that their development team can all develop for their “entire stack”. Allowing for faster speeds of updates, and web retrieval. Dale states the major change is: “Where before they needed dedicated front end, back end, mobile, and devops developers, they now are able to have each member of their team work on any of those positions.” Another exciting prospect of Node is that NASA is beginning to use it in non-mission critical methods. The government agency that sends people to the moon is using a Node program that we are beginning to implement. Major companies are beginning to use Node or fully switching over and for good reasons.

Those reasons according to Dale are the empowerment of developers, it’s perfect for micros services, its lightweight and scalable, constantly improving, and its performance. Developers are being empowered because frontend is being handled by Javascript as well as reusable tools that developers can all use. The best tooling for micro services in the industry is developed and implemented by node. Micro services paired with rapid development and open source library that makes Node lightweight is what really streamlines development with Node. Node is also updating and being consistently maintained as well so the service is always up to date. To attest to the performance the example that Dale really puts it into perspective “ PayPal, moving their mobile servers from Rails to Node resulted in going from 30 servers to just 3 and performance that was up to 20x faster.” After reading over this article and seeing how relevant and powerful Node is I am excited to be diving in and exploring the uses for myself.

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

https://blog.angular.io/angular-schematics-unit-testing-3a0a9aaab186

Recently as we have been working more with Angular I was interested in what king of testing was available for Angular code. The blog post on angular website does a good job of explaining how to get these tests done. To get started you need to mimic the application environment and set up the object you are testing in the case of this blog post they use a tree. Now it is time to actually set up the tests and that begins with an “it” statement.

AN EXAMPLE OF THEIR CODE:

it(‘fails with missing tree’, () => {

      expect(() => testRunner.runSchematic(

      ‘simple-schematic’, {name: “test”},

      Tree.empty())).toThrow();

});

               This code example asserts that an error was thrown because of an invalid tree. You can also assert invalid parameters as well with additional code shown in the blog post. The actual code for testing the outcome is the “expect()” function which can be used to test your code. Inside of the () is where you put the test you are running. In the case of this example we test to make sure all the expected files that’s are expected to be created with the expect(tree.files).toEqual([(files)]) to makes sure all created files are added to the array.

You can follow the blog for a direct example of the testing in Angular it is a bit complex in comparison to Java because you have to do a lot of set up instead of just creating a junit test. Over all I can see the benefit of wanting to test parts of your webapp without having to load up the app every time, but without a bit of practice Ill be hitting the refresh button a lot.

-Computing Finn

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

                 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.

https://www.codeinwp.com/blog/wordpress-rest-api/

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

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.

https://gitlab.com/AFinneran/homework3-decorator/blob/master/Homework%203/343hw.md

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

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

https://martinfowler.com/articles/practical-test-pyramid.html

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

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.

-Andrew

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

               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.

Objects

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

Scenes

• Start
• Game
• End

Logic

• 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

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

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.

http://agiledata.org/essays/tdd.html

-ComputingFinn

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.