Journey into REST APIs

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.

Machine Learning vs. Deep Learning

Summary

In the article Machine Learning vs. Deep Learning Explained, Bartek Ciszewski explains the difference between Machine Learning (ML) and Deep Learning (DL). He gives a quick overview these two terms are and also talks about the broader field of Artificial Intelligence (AI). He also gives examples of what machine learning and deep learning can be used for as well as providing real world examples of DL, such as Google’s Go playing program, which is capable of inventing its own moves.

Reaction to Content

I chose this topic because it was an interesting topic that I had looked into in the past but haven’t really done much research on yet. This article in particular was mainly useful as a refresher, providing a basic overview of the difference between machine learning and deep learning. Some of the real-world examples that he brought up (AlphaGo, self-driving cars, early automatic cancer detection, etc.) are definitely things that I think would be interesting topics to read about in order to get a deeper understanding of how deep learning works.

Overall, this article didn’t change how I thought about this subject. For those who haven’t seen these concepts before I think this article would be a useful place to start. The examples he provided for machine learning algorithms are helpful for understanding what it could be used for, but it seems like it’s very difficult to provide a simple example of what a deep learning algorithm could be used for due to how complex of a topic it is. As Ciszewski stated in his summary, neural networks are usually “black boxes,” so even the people who created the deep learning algorithms don’t entirely understand how the machine is able to do what it is being designed to do.

This video How Machines Learn, by CGP Grey, is another useful resource that helped me understand the topics discussed in the article better, by providing more use cases for them as well as giving a visualized high level overview of how these algorithms work.

I think in order to truly understand how deep learning works, I’ll have to look into example algorithms and go from there.

Source: https://www.netguru.co/blog/machine-learning-vs.-deep-learning-explained

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

test | prueba | thử nghiệm

CS SERIES (10)If you happen to be reading this page translated from English to another language, hello there, you are one of the main characters of this blog post. Without linguistics, the study of language and its structure, we probably would not be able to figure out how to communicate everything we need to globally while being able to understand it at the same time while testing. There are so many online resources that cover what a specific country or region in a country uses in terms of data formats for their computer systems.

Stickyminds featured an article from Mukesh Sharma on Linguistic Testing: Setting Up Your Software for Global Quality. Sharma dives in by explaining what exactly linguistic testing is–which is testing not only localization but also internationalization. These words basically mean everything we are testing on the software either is or would be fully functioning across the globe.

I found this content thought-provoking as I never specifically thought about how developers and testers would have to consider culturally-aware attributes like the formatting for texts, dates, and currencies. As more and more people are gaining access to the internet across the world, that means there are even more and more platforms to test for gauging market readiness.

An example of a situation that could happen in real life I can think of when testing functionality on websites is for international shipping addresses. If a user, we’ll call him Zayn, from London, England is ordering something from a company based in Boston, Massachusetts (USA) and puts in his shipping address, it should not require him to select a “State” under one of the fields after he selects “United Kingdom / England” as his country option. If that field still requires Zayn to select a state when his country location does not have states, there is a problem.

This will change the way I think when I work as when developing code to solve problems or create something new, I will have to think about if the market or target audience goes beyond the USA. When testing the code, of course every possible scenario must be tested already but there will have to be more details to make sure it all goes smoothly–especially since international errors or problems usually take up more effort to fix as communication plays a big factor.

Article: https://www.stickyminds.com/article/linguistic-testing-setting-your-software-global-quality

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

Specification-Based vs Code-Based Testing

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.

The Decorator Design Pattern

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.

The Builder Design

For this week’s blog post I will be taking a look at the Builder Design Pattern and how it is effectively implemented and used within a Java program. The Builder Design Pattern is designed to provide a flexible solution to various object creation problems that may arise within object-oriented programming. The pattern is used to separate the construction of a complex object from its representation. The Builder pattern is a creational pattern.

For this pattern we will use a common class, the Employee class. Suppose you have an Employee class with multiple instance variables some of which are required and others that are not. What type of constructor is required for this type of class?  One could follow the telescoping constructor pattern, which would require multiple constructors all with different forms of required attributes as parameters, but this is tedious and inefficient.  Having multiple constructors with varying parameters can lead to confusion of which constructor to invoke when, the default values of the parameters, and what could happen if you pass the wrong value to a constructor.

This leads us to the Builder Pattern. In order to implement the Builder pattern for this example, you would need to create a public static nested class which contains all the instance attributes from the outer class. The outer Employee class will have a private constructor that takes the EmployeeBuilder object as an argument. The builder class will have a public constructor that has all the required attributes as parameters defined as “final”. The builder class will also have setter methods to set the optional parameters. The final step is to provide a build() method in the builder class tat will return the other class object to the client. The method will call the private constructor in the other class, passing the Builder object as the parameter to this private constructor. The Employee class will only have getter methods and no public constructor. This means that the only way to get an Employee object is through the nested EmployeeBuilder Class.

The Builder pattern is useful in situations where a class has multiple attributes that may be the same type or optional. Instead of creating multiple constructors, we can build a separate class that will build the object and provide setter methods to set the optional attributes.

 

Article: https://dzone.com/articles/the-builder-pattern-for-class-with-many-constructo

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

Using the Decorator Pattern

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.

Understanding about the Testing Boxes

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.

Prototype Design Pattern Episode 2 : Attack of the Clones

 

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.

Test Driven Development And Unit Testing

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.