For this week’s blog post I have found a blog on Unified Modeling Language (UML). UML is an object-oriented modeling language. This has become a normal standard for documentation of a software system. It is a pictorial description of classes, objects, and relationships. It represents a plan that defines the working hardware or software system. For example, we can use a UML diagram to show what is going on in a three-class software system. For this example, the names of the three classes will be Student, Classroom, and Teacher. For each class, a box is used in UML to show the entire class with three lines separating class name, methods, and instance variables. Each variable is listed as the variable type and name separated by a colon (for example, String : Id). While the methods are listed as method name with parameters (if any) and the return variable type (if any) separated by a colon (for example, getId() : String)  Now if we wanted to show that the class named Class borrows objects from the student class, we would draw a arrow pointing from student to Class. If we wanted to show that it extends the class, we would draw a dotted arrow instead.

UML was designed and created back in the 90’s. This was a period where object-oriented languages (OOL) such as C++ were being used to build complex but compelling systems. The issue during this time was that we had complex systems but no good way of showing on paper what the system is doing. This was until in 1994 when software engineers Grady Booch, Ivar Jacobson, and James Rumbaugh of Rational Software created the UML language. This development of the language was finished two years later in 1996. Each of the designers came together to find a language they will reduce the complexity. According to Study Section, the website with the blog, they say on their process of reducing this complexity, “Booch’s method was flexible to work with throughout the design and creation of objects. Jacobson’s method contributed a great way to work on use-cases. It further has a great approach for high-level design. Rumbaugh’s method turned out to be useful while handling sensitive systems. Behavioral models and state-charts were added in the UML by David Harel.” (Study Section) In 1997, the Object Management Group (OMG) acknowledged UML as a normal language. They now are responsible for maintaining the UML language and updating with new languages that come out.  

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

https://swagger.io/resources/articles/best-practices-in-api-design/

The article I’ve chosen is based on Rest API Design, a topic that we are currently working on in class. Many important parts of Rest API Design are talked about throughout the article some of them being Rest API Design characteristics, collections and their resources, HTTP methods and more. According to the article a good api should be easy to read, complete/concise and hard for a user to misuse which is all important not only for integration of the api but also when using an api with any kind of application that it was designed for. Collections, resources and URLs are also very important to designing an effective Rest API as collections and resources allow the passing of data throughout the API and its functions. Using the proper URL helps you manipulate which data is shown at a specific time whether its the data of a specific user or an error code.

Describing the purpose or function of resources is also very important and it is done through the use of different HTTP methods. The methods listed in the article include get, post, put, patch and delete. Each of these HTTP methods is used to retrieve, create, update or delete resources. ANother way to develop a good rest API according to the article is by providing feedback for users by implementing error codes when the API is used incorrectly whether there is error in an entry by the user or if the user uses the incorrect operation when entering data. The responses you provide or error codes can help users and yourself understand your API better which will also help you when testing the functions of your API so you know how any commands or entries should be formed during use. The author also highlights that using examples in your get methods is important as it shows exactly what the user can expect when they “successfully call the API function”.

I chose this article as I found it helpful with our current class topic and it outlines all the basics of Rest API design and helps student developers like myself and my classmates better understand how to effectively design a Rest API. This article helped me understand the use of HTTP methods further as well as the importance of examples and resources which helps greatly with our current class subject. The article helps put the design of Rest API’s in an easily presentable state for students or other people in general who are interested in developing such an API.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Docker is an open source technology which enables the easy use of containers for software development. Steven J. Vaughan-Nichols, in his article “What is Docker and why is it so darn popular?”, writes that “… over 3.5 million applications have been placed in containers using Docker technology and over 37 billion containerized applications have been downloaded.” Needless to say, Docker is quickly becoming industry standard with “… almost 40 percent market-share growth in 12 months.” For anyone looking to get into software development, it is an absolute requirement to learn how to use Docker or something very similar.

Docker containers attempt to copy a virtual machine setup without actually running an entire virtual machine. The main difference is that Docker containers all run on a single operating system instead of emulating multiple different operating systems. This allows for much more efficient usage of resources, and it is estimated that between four and six times as many applications can be run on a Docker system as opposed to the traditional virtual machine setup.

One major reason why Docker is so versatile is that it allows your project to be packaged with all of its requirements on the container; because of this you would not need to pre-install dependencies on each machine you wish to run your application on. This also allows you to run your applications on cloud services very easily; in fact, Docker is specifically tailored to run on cloud services such as Puppet, Chef, Vagrant, and Ansible.

Since Docker is easily integrated on cloud servers this means that it is also easy to emulate a live server build. When a developer wants to test a change on a live server they can simply run a container which is set up in the same way as a live container. These containers can be tested very fast and safely, and it is reported that developers who used this method had “three times lower rate of change failure”.

Personally, I believe Docker is the future of software development. There are many benefits to using Docker with very few drawbacks, if any. Although Docker may take some time to learn and get used to, it most certainly will make developers’ jobs much easier in the long run. I anticipate that Docker will quickly become industry standard due to the many benefits listed above. Docker is a great software which will allow designers to run more applications, on a multitude of different machines, with quick turnaround on updates and fixes.

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

REST is an acronym for Representational State Transfer, and is an architectural style for distributed hypermedia systems. There are guide principles and constraints that need to be met for an API to be referred to as “RESTful”. In total, there are six principles/constraints for the REST API. These include Uniform Interface, Client-Server, Stateless, Cacheable, Layered System, and optionally Code on Demand.

Having a uniform interface allows one to simplify the overall system architecture, and helps to improve the visibility of interactions. Within this principle of uniform interfaces, there are four constraints that must also be met to be RESTful. These include identification of resources, where each resource must be uniquely identified, manipulation of resources through representations, so that resources must have a uniform representation in the server response, self descriptive messages, where each resource representation should have enough information to describe how to process the message, and hypermedia as the engine of application state, where the client should only have the initial URI of the application, and the application should drive all other resources and any interactions through the use of hyperlinks.

Client server is much simpler, as it only refers to the separation of concerns, so that the client and server components can evolve independently of each other. This allows one to separate the user interface from the data storage, and allows independent improvement of each without interrupting the other.

Statelessness refers to each request from the client to the server containing all of the necessary information required to completely understand and execute the request. In addition, the server cannot take advantage of any previously stored context information on the server.

Cacheable refers to a response needing to implicitly or explicitly label itself as cacheable or non-cacheable. If a response is marked as cacheable, then the client application can reuse response data later for any equivalent requests to help improve overall performance.

A layered system allows the architecture to be composed of many hierarchical layers by constraining the behavior of the components. For example, each component in a layered system cannot see beyond the layer that they are interacting with.

Lastly, REST optionally allows for client functionality to extend by downloading and executing code in the form of scripts. By downloading this code, this reduces the number of features that are required to be pre-implemented in the server.

Source

I chose the above article because I wanted more information on what it meant for an Application Programming Interface to be “RESTful”. The above article went above and beyond what I could hope to find and provided a lot of information on exactly what it meant for an API to be RESTful. Because of it, I now know exactly what it means for an API to be RESTful.

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

Recently, I worked with bash scripts and docker-compose files in order to run a set of containers. While both seemed to be valid ways of running multiple containers in Docker, I wanted to look into docker-compose files further to understand the possible advantages and use cases. A resource that I found quite helpful was The Definitive Guide to Docker compose, a blog post by Gabriel Tanner. Inside, he explains why we should care about Docker-compose and the potential use cases.

Docker Compose

Let us first go over what Docker Compose is. According to the Docker Compose documentation, “Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration.” Instead of listing each docker run command in a script, Compose utilizes a docker-compose.yml file to handle multiple docker containers at once.

Here’s a sample docker-compose.yml file:

You might be able to recognize some of the labels such as image, ports, and volumes. All of which would normally be specified in a docker run command. And as you can see, each individual container is listed under the services tag. The docker command equivalent to run web1 would be something like: docker run -it –name web1 -p 10000:80 -v ${PWD}/web1:/usr/share/nginx/html -d nginx:mainline

Tanner explains that almost every compose file should include:

• The version of the compose file
• The services which will be built
• All used volumes
• The networks which connect the different services

Now that we have a brief understanding of the docker-compose file structure, let’s talk about the use cases for Compose and their benefits.

Portable Development Environments

As opposed to running multiple containers with a separate docker run command, you can simply use docker-compose up to deploy all the containers specified in your docker-compose.yml file. And it is just as easy to stop all of the containers by running docker-compose down. This provides developers the ability to run an application and configure the services all within a single environment. Since the compose file manages all of the dependencies, it is possible to run an application on any machine with Docker installed.

Automated Testing

A beneficial use case of a docker-compose file is with automated testing environments. Compose offers an isolated testing environment that closely resembles your local OS that can easily be created or destroyed.

Single Host Deployments

Compose can be used to deploy and manage multiple containers on a single system. Because applications are maintained in an isolated environment, it is possible to run multiple copies of the same environment on one machine. And when running through Docker Compose, interference between different projects are prevented.

Conclusion

Hopefully this blog post helped you learn more about Docker Compose as much as it helped me. For the most part, docker-compose files make it possible to run multi-container applications with a single command. While researching this topic, I’ve come to believe that docker compose files will be the standard for running applications through Docker if it isn’t already. I’d like to write more about this topic, and I think a blog post going in-depth on the structure of docker-compose files would be useful.

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

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.