Let’s start by discussing javascript a bit. Javascript is currently a must know programming language in the computer science world. It is widely used for web development on both front-end and back-end development. Javascript can also be found in many other fields of development including mobile apps, desktop apps, and game development. 

Javascript language is quite user friendly and can even be considered easy to learn but it doesn’t come without its concerns of course. The same code you’ve written may work differently when used in different browsers such as Google Chrome versus explorer, or safari, for example. Javascript is also very stripped down so it can be easy to create errors by mistake especially for beginners. An example of this is that Javascript is dynamically typed. Programs don’t know the types of variables until they are assigned at runtime and then they must do an awful lot of referencing to figure out the type depending on the size of the program. Since types are not required there are no compiling errors or messages to tell you what you are doing wrong. It leaves a hard traced error if or not careful when working with your code. 

Now moving on to Typescript!

Typescript is a superset of Javascript which means it contains all the same functionality of Javascript as well as added features. Typescript compiles to plain Javascript so any code you write in Javascript will run just fine in Typescript, as long as you have written it correctly of course. The big additions of Typescript are type annotations, interfaces, and classes. 

As opposed to Javascript, which is dynamically typed, Typescript uses static typing. Static typing means that things like variable types can be checked at compile time since variable annotations are available. The code will still run if you have an error but you will receive a message warning you about the specific error that was detected. Also depending on your IDE it may offer the function of displaying errors to the user while they are typing. If you want to take advantage of this functionality then you can check out the Visual Studio Code IDE, which contains that function.

I chose to blog about this subject because I am a newcomer to this language and material. I figured if I did some research on my own and actually typed out the words then it would all become more clear to me what the relationship of Typescript was to Javascript and what they are used for in the real world. I feel now that I have this general overview and understanding of the language and its use that I can now conceptualize my own uses for it. I’m looking forward to implementing what I have learned about Typescript into my own projects.

Lease, Diana. “TypeScript: What Is It & When Is It Useful?” Medium, Frontend Weekly, 31 Jan. 2018, medium.com/front-end-weekly/typescript-what-is-it-when-is-it-useful-c4c41b5c4ae7.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Integration testing is the second step in your overall testing process. First off you will perform you Unit test, testing each individual component to see if it will pass. However, your testing process is just getting started and is not ready for a full system test. After the Unit test and before the system test you must run an integration test. This test is the process in which you combine all your units to test for any faults in the interaction between one another. Yes each individual unit might pass on its own but having them work together simultaneously in an integral part of the program. 

These are the many approaches one can take to Integration testing:

• Big Bang is an approach to Integration Testing where all or most of the units are combined together and tested at one go. This approach is taken when the testing team receives the entire software in a bundle. So what is the difference between Big Bang Integration Testing and System Testing? Well, the former tests only the interactions between the units while the latter tests the entire system.
• Top Down is an approach to Integration Testing where top-level units are tested first and lower level units are tested step by step after that. This approach is taken when top-down development approach is followed. Test Stubs are needed to simulate lower level units which may not be available during the initial phases.
• Bottom Up is an approach to Integration Testing where bottom level units are tested first and upper-level units step by step after that. This approach is taken when bottom-up development approach is followed. Test Drivers are needed to simulate higher level units which may not be available during the initial phases.
• Sandwich/Hybrid is an approach to Integration Testing which is a combination of Top Down and Bottom Up approaches.

I think this part of the testing process is the most interesting. Once you have individually working components it’s like making sure the puzzle pieces fit. 

Integration Testing. (2018, March 3). Retrieved from http://softwaretestingfundamentals.com/integration-testing/.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

The c4 model is a tool used by programmers to articulate their software designs in a translatable manner. Using this model a programmer should be able to communicate their design easily to those outside the professions, say a stakeholder for example, and also to their programming team. The model should have levels and using “abstraction first” the levels should show different amounts of complexity that overall allow you and your team to implement the data. A great example of the overview of the c4 model is to think of google maps and their zoom feature. If you are looking at a country and are zoomed out so that you can see it in its entirety, then you may only see the name of the country and what is surrounding it. Then if you zoom in a bit you may see the states that make up the country. Zooming even more, you can see the cities, towns, and you may zoom all the way in to a specific location and see what is there. This allows the viewer to utilize the abstraction to avoid being overloaded with information and instead look at the data in layers of complexity. 

C4 models are implemented to represent the three levels of design. The three levels are known as:

“System design refers to the overall set of architectural patterns, how the overall system functions—such as which technical services you need—and how it relates to larger enterprise contexts. System design is shown in a Context diagram.

Application design refers to the combination of the services that are needed and how to implement them. Application design is shown in a Container diagram.

Service design refers to the patterns and considerations that are involved in implementing specific services. This type of design starts to emerge in a Component diagram”.

Relating these three levels of design to the google maps example starts to make things clear. The system design would be the view of a country in its entirety without too much detail, or in other words the big picture. Application design is a bit zoomed in and could show the states that makeup the country and helps to show the relationship between data inside the big picture. Service design would be the specifically zoomed areas where you can see in much more detail and see the function of data.

This c4 model stands out to me because it helps to bridge the gap between those involved in the field and those who are not. It provides a concise and organized way of communicating project ideas and patterns to your team  and to whom you are working with that may not understand the other diagrams programmers use. For example, UML diagrams are great for programmers but you don’t want to present that to someone who isn’t a programmer. They will have no clue what they are seeing, but with a c4 model you can capture the big picture and have the details on hand as well.

(n.d.). Retrieved from https://www.ibm.com/garage/method/practices/code/c4-model-for-software-architecture/.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

This past week in my Software Testing course I learned about edge Testing. I think when I was first learning about this subject I was more apt to lean towards boundary testing because my thought process was that everything that is supposed to work in a program should work and that’s what is important to test. Anything outside of that can just be blocked and is time consuming and tedious to check because those values will fail. However, I was intrigued by edge testing because it made importance in all values across the domain as well as out of bounds. I saw that it wasn’t enough to just assume the failures, you had to also know why they are causing a failure in order to combat them. Some problems are not easy to find but it is just as important to test the failures as it is to test the correct values and functions. Edge testing is a much more thorough and logical approach. This article was a nice pep-talk and helped persuade my thinking, check it out!

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Refactoring is an inevitable location that all programmers reach eventually. Working on any project there is bound to be changes and new ideas or concepts on how to structure the code. With constant updates and inventions coming about everyday for the software world it simply is something we will all have to deal with. We create a program and find that we need to pass different parameter types to achieve a different outcome well now we have thirty plus methods to go back and change one by one. Now while that may be a necessary actions there is another concept to consider, that is adaptation! A good analogy of the Adapter Design Pattern is to consider a program is a cable you use to plug in an electronic device. Imagine that you travel to another country with your device and cable and now you run into the issue of a different wall socket. Your plug won’t fit even though it works just fine back home. Do you go out and buy a whole new wire to make it work with the new power source. No! Simply buy a wall adapter and your cable will work just fine(Of course you should check the voltage in real life, but the idea is the same). Perhaps there is nothing wrong with the structure of you code, you just need it to execute with different data types. By writing an adaptation class you could save a lot of frustration and time refactoring your original code. The adapter and adaptee could function by both implementing an interface and therefore the adaptee would only need to have an “implements … ” statement. In doing this you now have the ability to create any number of adapter methods instead of changing your original code. 

A nice simplistic example I found from an online article is that of the Rectangle class. Suppose you write a display() method to display the parameters of the rectangle to the user and the method expects the parameters x, y, w, h. However, the user wants to pass x1, y1, x2, y2 but this will cause an error in the display() method. If an interface is created that hold the display() method then if can be adapted in many ways and fix this issue.

My question to you is; do you think that adaptation is in fact refactoring. According to google the meaning of refactoring is “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure”. Think about this, although I’m sure there is a clearcut textbook answer.

Design Patterns and Refactoring. (n.d.). Retrieved from https://sourcemaking.com/design_patterns/adapter.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

SOLID is an acronym for a set of important design principles. Paired together they create a framework for worry free code, and by “worry free” I am speaking of code that would trouble you if any changes needed to be made. In the world today things are constantly changing and being updated and so should your code. If that’s the case then any code you write should have the ability to be edited without causing a complete overhaul of your whole program. Basically what you want to avoid is trickle down effects, and unlike trickle down economics, this is real. If you change one thing or responsibility of a class or variable and that causes a cascade of continuous changes and troubles, then you are experiencing this trickle down effect. To help with this issue is the first design principle in the acronym, Single Responsibility Principle.

Single Responsibility Principle is exactly what it sounds like. Give your classes and methods a sole responsibility so that if they are changed it will only effect that method or classes responsibility. If a class or method handles multiple responsibilities then changing the design of one part may be cause to change the entire entity. 

A crude example would be a Rectangle Class. Let us say you have a constructor to build a rectangle object and all it does is take arguments for height and width. However, you also add if and else statements in the constructor to see if the dimensions make a square and printing a confirmation message if it is. Perhaps you even write “if (myShape.isSquare())..” to send the object to a method to, but this is giving the constructor more than one responsibility. If you decide to change the placement of the square check then there will either be duplicated code or you will have to edit the constructor to pass the isSquare result to other methods. Doing any of this would result is test case changes if you were testing the code. In this scenario it is best to have the constructor just be the constructor and to dedicate the square check to its own method like isSquare. In this case if changes were made then only a single class would require changes and not several that are connected in a convoluted fashion.

I think the Single Responsibility Principle is a must know. I remember beginning coding is CS140 and Data Structures and I would try to get as much done in as few methods as possible by cramming in multiple functions into them. I thought the less methods the better but I was so wrong, it’s worth so much more to have many separate methods and classes that each have a sole function. This way code is organized, easy to arrange, and simple to implement or change.

SOLID Design Principles Explained: The Single Responsibility Principle. (2018, December 17). Retrieved from https://stackify.com/solid-design-principles/

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.