During this semester we have started to use MongoDB. While I did get some general explanations of MongoDB in class, I felt like I needed to get a better grasping of how MongoDB works as a database and how I can better use it. Since MongoDB is a NoSQL styled database and my general understanding of databases comes only from using relational databases, I felt like an article helping to summarize and clarify NoSQL would be advantageous.

https://dev.to/lmolivera/everything-you-need-to-know-about-nosql-databases-3o3h

This article goes into great detail not only the advantages or features of NoSQL but the terminology used alongside with it. It has descriptions of multiple types, how they differ and what they are used for and including some helpful guides around designing these different types of databases.

More specifically my focus is on the type of NoSQL database that MongoDB is which is a document based database.

As the article describes, a document type database stores it’s data inside of a “document” that could contain varied types of data. Even to the point of storing documents nested inside of other documents. Which highlights the advantage of this type of database which is scalability. Being able to store nearly anything inside the database and not needing to force it’s formatting is a great feature. I’m trying to think of a scenario needed for nesting your entire database inside as an object containing your entire database. I don’t seem to be able to think of one in specific, but the concept is interesting to me and maybe it’ll be useful later.

This article also briefly goes into describing how JSON formatted NoSQL databases are structured. This was good to see as this is exactly what I have been using in class as well as in the most recent homework assignment.

It also gave a link to a list of databases who have used Document based NoSQL databases and was interested to see eBay listed their and specifically using the same database MongoDB as we are using in class.

https://www.edureka.co/blog/real-world-use-cases-of-mongodb/

Near the end of the article it begins to describe the CAP Theorem. The theorem as I learned from this article to be a general issue around picking which attribute we focus on for the service. Is it frequently consistent with reads/writes? Does every request have the most recent changes? Does it still perform it’s functions when some of the machines are currently not connected? This concept details that you must pick only two and generally partition tolerance is chosen first as one of the two. The reasoning being that as a service being able to provide it regardless of a particular aspect of the database going down you still want to be able to provide a service.

Overall this article gave me some good general insight on what a NoSQL database specifically is and how it is generally used and will help me in class when referring to the database we have been using MongoDB.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

In last week’s blog, I covered docker compose files and their significance. For today’s blog, I would like to go in depth on docker-files to explain how they are structured. To give a quick review of what Docker Compose is. Docker Compose is a tool that allows developers to create and run multi-container docker applications. Once again, I am referring to The Definitive Guide to Docker compose, posted by Gabriel Tanner. He does a good job of breaking down the structure of a docker-compose.yml file.

Docker Compose File Structure

By using a docker file, you can list the containers you want and all of the specifications as you would in a docker run command. As explained in last weeks blog, almost every docker-compose file should include the following:

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

Docker files are structured upon indentation. Consider the idea of levels of abstraction.

On the top levels are the version, services, and volumes tag. The next level down is where the containers are listed, then parameter tags such as image, volumes, and ports. And finally on the lowest level, the respective rules for each parameter.

Here is a simple docker-compose.yml file:

Let’s take a look at each tag individually.

Version:

The version tag is used to specify the version of our compose file, based on the Docker engine we are using. For example, if we are using Docker engine release 19.03 or later:

Services:

The service tag acts as a parent tag, as all of the containers are listed underneath it.

Base Image/Build:

The image tag is where you would define the base image of each container. You can define a build using preexisting images available on DockerHub. In this case, we are defining a web1 container using the nginx:mainline image. 

You can even define the base image by pointing to a custom Dockerfile:

Volumes:

The volumes tag allows you to designate a directory where the persisting data of a container is managed. Here is an example of a normal volume being specified.

Another way of defining a volume is through path mapping, linking a directory on the host machine to a container destination separated by a : operator.

Ports:

Specifying a port allows you to expose your host machine to the container that is running. In this case, we are defining port 10000 for the host port and we want to expose it to port 80.

Those are all of the main components that you need to structure a Docker Compose file. In this blog post, I simply covered the basic tags and structure. Compose files allow you to manage multiple containers and specify properties to a finer detail. There are tags that I haven’t covered such as dependencies, commands, and environment that Gabriel explains really well. 

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

After doing more work with activities 13 and 15 and working on homework 4, I wanted to read more about how to use the http methods with REST API calls because I was having some trouble understanding how to implement them in the homework at first and wanted to get a better grasp on how they work to set up my endpoints and paths.

I have decent understanding of each of the methods and how they correlate with the paths and endpoints we have been working with so far. The main source I used for reading more about the methods was the REST API tutorial about http methods. It goes over each of the methods and gives a summary at the end which is a table. It also gives a brief glossary over some terms used and references to other sources. It gave good explanations for each method and was divided in evenly sized sections.

The main five methods used that we are familiar with are GET, PUT, POST, DELETE, and PATCH. GET is used to find and return an item or object based on the parameters we choose, like a name or ID. POST creates an object and posts it to the data. PUT updates and replaces data for an object. DELETE removes/deletes an item/object. PATCH is used for minor/partial updates. We have not used PATCH in our activities yet, but it did show up as a method in an example given for activity 12 for how http methods work with urls.

Going more into the methods, GET methods are considered safe methods because they do not make any changes to the data, and they are also idempotent because they are expected to allow multiple similar requests with the same results. The other methods all change the code or data in some way, so they are not considered safe. DELETE is the other idempotent method because the result of each DELETE is a removed object. PUTs and PATCHs seem the same because they both are used to make changes to existing data, but they differ how much they update. PATCHs are for smaller and partial updates, while PUTs are for bigger updates and usually involve replacing existing data.

After this reading and doing more work with REST API, I have a better idea on how to implement them in code and continue with the activities and homework.

https://restfulapi.net/http-methods/

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

https://www.vogella.com/tutorials/JavaConcurrency/article.html

This article discusses the use of Concurrency in Java. As defined in the article Concurrency is “the ability to run several programs or parts of a program in parallel”. Concurrency is meant to cut down on time and make a program or programs more effective and easier to use together. The article describes how Java uses several threads to “parallel process” or behave asynchronously which ultimately makes the application run faster and smoother. Concurrency is all about the performance gain in the application, this gain can be calculated using “Amdahls Law” which tells you the maximum performance gain.

According to the article a Java program runs its processes in one thread (by default) through javas “Thread Code” which is also capable of allowing multiple threads through the Thread class. Through threads you use the synchronize keyword in order to define which methods or code should be executed by one single thread. The synchronized keyword provides specific sections of code with a “lock” and any code protected by this lock will be executed by one thread instead of multiple. The memory of threads communicates with the memory of the application through the “java memory model” which also allows the thread memory to refresh itself with the main memory.

I chose this article as it goes into depth about the subject of Concurrency and helps students like myself understand what exactly concurrency is and what the purpose or use of concurrency is. Concurrency is a complex subject as it involves the thread class which isnt commonly used by beginners in java and it involves new keywords not previously learned. The article goes into detail about threads and what exactly they do/why they are important and it also tells you the exact purpose of concurrency which is program efficiency i.e. speed, correctness, etc.

I actually learned quite a bit from this article. I already knew the general idea/concept of concurrency and what it is but as far as the more in depth information which was provided like threads, synchronize and volatile I never knew exactly what each part was and what they each entailed. This article was organized very well and provides the reader with the necessary information in order to learn about and work with concurrency in their own code. Overall the article was very helpful and I would recommend it to other students as it explains the subject very well.

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.

These weeks, I’ve been learning about APIs and back-ends. I also had the opportunity to practice with an API in my current homework. However, I am very confused about the relationship between API and back-end. I don’t understand how the API is related to the back-end, what the API and back-end are used for.

To answer those questions, I tried to search for some information about API and back-end. Back-end API development introduction, written by Cesare Ferrari, is a resource that I have found useful. The website has clear definitions of back-end and API; and their relationship is also described in detail, which helps me get better understanding of the two new terms. From the website, I know that back-end is a service that will send data to the front-end which interacts with the end users. On the other hand, API, Application Programing Interface, is a set of definitions and protocols for building and integrating application software. API can be also considered a back-end component, which is typically used by front-end applications to communicate with back-end applications. In other words, the API is used to outline all the requirements or functions that will interact with the end user. The back-end will rely on the API to create endpoints that fulfill all the requirements designed in the API. There are different types of APIs, but the REST APIs, which stands for Representational State Transfer, is one of the most popular. It communicates via HTTP requests to perform four basic functions known as CRUD. These are creating data (post), reading data (get), updating data (put), and deleting data (delete).

Moreover, the website also provides a general information of Node.js and Express to explain more how to create and use back-end applications. Node.js is used to execute a Javascript on the back-end without the browser. Express is a library or a Node.js application is used to create and send HTTP requests.

All in all, I think the website is a good resource because it’s short, concise, and provides the essential information I need. It gives me a general idea of what the back-end and API are, and how the back-end and API relate to each other. By understanding the two new definitions, I was also able to understand what I was supposed to do in each one. Based on what I read from the site and what I did with my API homework, I can envision the API as an interface class and the back-end as my concrete class that will implement all abstract methods from the interface class.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

REST APIs have become increasingly popular over the last few years, and for good reason. REST has less of a learning curve than other API models, has a smaller footprint, and parsing of JSON is less intensive than traditional XML parsing. There are a few key standards to REST, including utilizing certain requests like GET, POST, PUT, and DELETE, for example.

When a call is made using REST API, there are a few things that go on within the call itself. First are the endpoints, which is a unique URL that is used to represent objects or groups of objects of data. Every API request has its own endpoint. In addition, there are also the methods used for the request. These include those I listed above, like GET, POST, and PUT. A header contains the information that represents the metadata associated with the REST API request. The header also indicates the format of the request and the response, and provides information about the status of the request. Lastly, the request also consists of data, which is also referred to as the body, that is usually used with the POST and PUT commands and contains the information that will be updated or created.

Another important part of REST APIs are parameters. When someone is sending a REST API request, they can use parameters to narrow or further specify their search request. These are valuable tools, since it allows you to filter the data being received in a response. Some parameter types include path, header, cookie, and the most common, query. Query parameters are located at the end of a URL path and can either be required or optional. This can be useful if, for example, you are using a base GET command to get all of the objects in the database, and you can have an optional parameter to specify which of all those objects you want, using something like ID or name, depending on your implementation.

Source

I chose the above source because it gave good additional information on REST APIs, compared to other websites I visited. This helped me further understand how REST APIs differ from other web APIs, and what helps make REST different and usually better. REST APIs definitely have their many uses, and allows ease of use with their standards of requests, using easy to understand methods like GET, POST, and PUT, to name a few.

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

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

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

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

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