Anders Hejlsberg is known as the creator of TypeScript. On 2010, he and his team began developing TypeScript, and in 2012 they released TypeScript 0.8 for the first time. There were several versions of TypeScript released since 2012. The last version announced is TypeScript 3.2 RC, which is the release candidate of the next version. According to Anders Hejlsberg, JavaScript is TypeScript, but TypeScript is not JavaScript, which makes TypeScript a superset of the JavaScript language. That means that any valid JavaScript code is also valid TypeScript code.

TypeScript has additional features and does not exist in the current version of JavaScript, supported by most browsers out there. In TypeScript, we have this concept of strong or static typing. If you have worked with languages like C# or Java, you know that in these languages when we define a variable, we need to specify the type of that variable. In TypeScript typing is optional so we don’t have to use this feature. But using this feature makes our applications more predictable and it also makes it easier to debug them when something goes wrong. Typescript also brings Object-oriented features that we have missed in JavaScript for a long time. We have the concepts of classes, interfaces, constructors, access modifiers like public and private, fields, properties, generics, and so on. Another benefit of using TypeScript is that with TypeScript we can catch errors at compile time instead of the runtime, of course not all errors but a lot of them. There is a compilation step involved, and when we compile with TypeScript code, we can catch these errors and fix them before deploying our application. And finally, another benefit of using TypeScript is that we get access to some great tools out there. One thing that I personally love about TypeScript is the autocomplete suggestions that we get in our code editors as we are coding, like Atom and Visual Studio Code.

TypeScript is a beautiful language but the browsers that we use every day don’t know TypeScript, and it is very unlikely that the browsers are going to support TypeScript in the future. So, we need to compile or more accurately Transpile our TypeScript code into JavaScript code.  This is part of building an application. Whenever we build an application TypeScript compiler kicks in and it Transpiles TypeScript code into JavaScript code that browsers can understand.

References: https://en.wikipedia.org/wiki/TypeScript,

https://channel9.msdn.com/posts/Anders-Hejlsberg-Introducing-TypeScript,

From the blog CS@Worcester – Gloris's Blog by Gloris Pina and used with permission of the author. All other rights reserved by the author.

As I take another step towards my journey in software C.D.A. I dive into REST APIs. Where I will be talking about the YouTube video I found “APIs|REST|REST APIs Demystified” from The TechCave. For this weeks blogs I am going to try things different. I will give a very short summary of what the blog talks about and if you are interested in the topic I strongly suggest watching the video it is very interesting and on point to the topic. The video also provides a short example to help you understand and see how rest APIs works using Node.js.

This video talks about what an API is, and how it relates to a web service and/or relates to REST. This is a very interesting video because it seems to cover a lot of basic knowledge needed when dealing with APIs, REST, or RESTful APIs. It also talks about what a person needs to start building APIs. In the video the presenter answers the following three question:

1. What is an API?
   • Also known as Application Programming Interface, that has the ability to give software component a way to communicate with each other.
2. How does it relates to web services?
   • API relates to web services because they both work as a communication sharing base between services or components.
3. What is a REST API?
   • “Is an API that follows the rules of the REST specification”.

for more specification on those question just watch the video by clicking the highlighted link above. I have to say that from this video I found the following tip from the video very useful and interesting… “Questions every API should answer:

1. How can the client tell the service provider which operation it wants to perform?(Method information)
2. How can the client tell the service provider what data to operate on?(Scoping information)”

That is because it helps you understand during building the API it needs to answer those question in order to make sure your API would be successful. This video is not just interesting… it was also useful. From now on when building an API I will ensure that it answer those two questions.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Greetings reader!

In today’s blog, I will be discussing the differences between specification-based testing and code-based testing . I will also explain the benefits of each test, as well as pointing out their distinct features. Without further explanation, let’s begin!

Code based testing is a technique used to see if each line of code has been executed correctly. It corresponds to the testing that is carried out on code development, code inspection, and unit testing in the software development process. The idea is to find out whether any bugs exist in the program by choosing a set of test cases that can create the wanted results. Code based testing involves dynamic testing, static testing, and calculating Cyclomatic complexity.

In static testing, code is not executed; instead it checks the code, requirement documents, and design documents to detect errors.  The goal of this technique is to improve the quality of software by finding errors in early stages of development. Dynamic testing is when you are providing an input, receiving an output, and comparing the output to the expected behavior. Cyclomatic complexity is a mathematical based technique that helps reveal the facts that may be hard to find. It is the calculation of the number of nodes reached and the jump to the next node. It is done with the help of a control flow graph.

Specification-based testing technique is also known as black-box testing because they view the software as a black-box with inputs and outputs. Black box testing is a testing method in which there is no access to the source code or the internal structure of software. The main goal is to check to see if everything works well from the view of a user.  Black box testing focuses on incorrect or missing functions, data structures errors, any graphical user interface errors, faulty software performance, and for any control flow errors. The testers have no knowledge of how the system or component is structured inside the box. Specification-based techniques are applicable at all levels of testing where specification exists.

Types of Specification Based Testing Techniques

1. Equivalence Partitioning
2. Boundary Value Analysis
3. Decision Tables
4. State Transitioning

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

This week I will be looking at the decorator design pattern. This post discusses the advantages of using a decorator design pattern over inheritance in Java and gives examples of its implementation. The main advantage being a significantly less number of classes are needed when adding functionality using a decorator versus using traditional inheritance. It also mentions that the decorator should be added so that it is natively supported by programming languages. I think that this is the most interesting part of the entire article. I agree that languages, and in particular Java should start natively adding support for these design patterns. By doing this, as the article says it makes it much easier for beginner programmers to implement. I agree with this and I find that this can be challenging when you are first learning about design patterns and especially if you are starting out programming. In addition, I agree that a native implementation makes this design pattern, and others much cleaner to implement. As the example of the implementation in this article shows it would require a lot less work and code if it was implemented as they have it with just having a decorates statements instead of implements when creating a new class. I find this approach would encourage me and others to use this as it would be easy to use and not require repetitive typing, which as the article states would lead to better programs. I think this point of native support should also go beyond just this particular design pattern. I think that Java and other object-oriented languages should add native support for some of the other popular design patterns as well such as strategy or singleton. This would make it easier to experiment with different patterns earlier in the stages of learning to program and would let people see the benefits without struggling on the implementation necessarily. I would have found it much more encouraging to use one of these patterns as the article suggests if it was natively supported versus creating my own implementation based on text-book examples. Overall this article and what I’ve learned in this class have taught me to prefer using a design pattern over basic inheritance in most scenarios when building programs and that adding native support for these patterns would make it even better to use.

Source: https://dzone.com/articles/is-inheritance-dead

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Derek Banas has a youtube channel dedicated to java tutorials and higher level software development concepts. In his video series of design patterns, he describes the value and how to use the Decorator Design Pattern. Banas begins his tutorial by explaining the utilization of the decorator pattern, and then applies it by using a simple example based on a pizza making simulator.

The purpose and value of using the decorator pattern according to Banas is it allows you to dynamically modify an object, without having to hard code additional features. By extension, this allows us to add to old code without having to rewrite the program. Banas suggests to use the decorator pattern in situations where we would want to use inheritance, but where the classes need to be flexible enough to add features to during run time, so inheritance itself is not sufficient. By applying this pattern we are able to favor composition over inheritance.

Banas applies this pattern in an example of a program used to add toppings to a pizza, and display a description and cost. He first implements the solution to this problem using inheritance, hard coding each type of pizza subclass with a preset description and price. However, Banas notes how by using inheritance, we would have to implement an infinite amount of subclasses for each combination of topping. Furthermore, the change in price of a topping would necessitate changing every subclass using that topping. So regular inheritance is not sufficient for this program.

From here out Banas implements the decorator pattern using a Pizza interface, a ToppingDecorator abstract class with a Pizza instance variable, and PlainPizza concrete class. By creating topping classes that extend ToppingDecorator, he is able to add toppings dynamically to a PlainPizza object, calling a string of constructors for each topping (Pizza myPizza = new TomatoSauce(new Mozzarella)…).

I highly recommend Derek Banas’ youtube channel, as he is adept at breaking down high level software design strategies into simple examples anybody can understand, and he is skilled at illuminating the benefits of design patterns over more basic, intuitive implementations. The structure of his videos are easy to follow as well, starting with a high level discussion, moving down to a UML diagram, and finally implementing the solution. This strategy is very helpful for anyone learning or needing clarification on design patterns.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

For this week, I have decided to read “Black box, grey box, white box testing: what differences?” from the NBS System blog. The reason I have chosen to read about this is because while I do understand the basics of what each box does, I have the need to find out more about the benefits and the perspectives of using them. I believe this will help in understanding the purposes of utilizing each one and why do some tend to use them for a certain amount of time.

This blog basically goes over as the title implies what do the boxes do and what do they offer for possibilities. Black box consists of reviewing only the functionalities of an application or rather what it does it is what is supposed to, no matter how it does it. The user needs to know what the role of the system is and its functionalities but does not need to know its inner mechanisms. For white box, it consists in reviewing the functioning of an application and its internal structure. All of the internal components of the software or application are tested through the source code, which is the main work base of the user. Grey box testing complies both of the previous approaches: testing both of the functionalities and functioning of a website. This means that a tester gives an input to the system, checks to see if the result is the expected one, and checks through which process the result was obtained from. It is vital with these kind of tests to make sure the product is complete, secure and efficient.

What I think is useful about this blog is that it provides the benefits and drawbacks for each box like for black box, it has simplicity and redundancy listed down and gives an explanation based on it. There is also the example of penetration testing to give an understanding of each box in a real-life situation. From this blog, it goes from the general definition to the boxes, explaining how the boxes works from one perspective to the next, benefits and drawbacks of the boxes, and finally a penetrating testing example.

Based on the content of this blog, I would say that this blog is a good introduction to knowing the boxes in concept.  I do not disagree with this content since it does try to give readers the information needed and provide great examples to get a clear understanding overall. For future practice, I shall try to get familiar with the examples the blog uses for the boxes in real-life situations.

Link to the blog: https://www.nbs-system.com/en/blog/black-box-grey-box-white-box-testing-what-differences/

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

For this week’s blogpost I will be looking at yet another design pattern called the Prototype Design Pattern. Creating objects can take a lot of time and can be an expensive affair so in order to save time and money we can dive into cloning to solve this problem. You would want to use this pattern when the cost of the object to complex or expensive. After all, the clones in Star Wars were made to be cheap and expendable ultimately, the same goes for the idea behind the cloning pattern. Trying to keep the number of classes at a minimum is also a great time to use this object. Another big reason to use this pattern is when the client is creating objects that are required which are very similar to already existing objects, hence cloning. Essentially what this pattern allows you to do is make new instances by creating copies of existing instances. The result is a cloned object which is different from the original object, causing the state of the original to be the same as the clone right after the time of cloning. Therefore each object may undergo some state change, modifying the objects to perform different things after this is easily done. The structure of this pattern comes when the prototype class declares an interface for cloning itself by implementing the clone able interface and using the clone() method. Concrete Prototype then implements the clone method for cloning itself. After this the client class creates a new object asking the prototype to clone itself rather than using a new keyword. You need to instantiate the original class A(the class you are cloning) before using it. Then the client requests the prototype class for a new object of the same type as class A. This patterns great for scenarios where multiple profiles need to be created. In turn we can store the data in a single call and cache it in the session for further processing. Another more prominent example of cloning would perhaps be in the form of a bank account. Where you would want to make a copy of the object that holds your account information, perform transactions on it and then replace the original object with a modified one (a clone). The blog then goes on to list some more interesting points of the design pattern as well as some benefits and drawbacks. One of the drawbacks of the pattern is that classes with circular references to other classes cannot really be cloned. But a benefit of this pattern is that client can reduce subclassing with this immensely. All and all this pattern seems like something I would use actually quite often.

From the blog CS@Worcester – Matt's Blog by mattyd99 and used with permission of the author. All other rights reserved by the author.

Software developer John Sonmez writing for simpleprogrammer.com gives a narrative of his experience as a lead developer, and how he applied the practices of test driven development and unit testing in his article What is TDD? What is Unit Testing?.  Sonmez stresses the definitions in these concepts and illustrates how they are applied in the development process.

Somnez begins by asserting that the purpose of a unit test is to verify the functionality of the smallest possible unit of code, usually on the class level. The author calls unit tests an “absolute specification”, and he explains that the value of a unit test is verifying that the smallest possible units of code function properly in isolation.

According to the author, by making sure unit tests are absolute specifications on the smallest possible units of code, unit testing can highlight problems in the design. Sonmez backs up his claim by describing how unit tests help developers discover tight coupling, and issues with cohesiveness, as the process of testing classes in isolation highlights these issues, since most programs have complex dependencies.

Sonmez moves on to define test driven development as the opposite of the traditional waterfall methodology of testing, where complete specifications were provided up front and tests happened at the end of development of a component. In test driven development, tests are written before any implementation, and only minimal code is written to make that particular test pass. After the tests pass, the developer refactors the code. This process Sonmez describes as “Red, Green, Refactor”, alluding to the red/green color of the unit tests.

The value of test driven development according to Sonmez is that tests are the best form of specifications, they either pass or fail; there is no room for interpreting the specifications. Furthermore, the author asserts that this development style is important because it forces the developer to understand the function of the code before implementing it. If we can’t describe exactly what the test should verify, then we need to go back and understand more, helping prevent errors before they happen.

I enjoyed this article and highly recommend it to anyone confused about how these concepts apply in the industry, as you can tell Sonmez’s professional experience has enlightened him in these areas. He is very good at simply describing concepts and the practical situations and uses of applying them.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.