When developing software, creating understandable, readable, and testable code is not just a nice thing to do, but it is a necessity. This is because having clean code that could be reviewed and worked on by other developers is an essential part of the development process. When it comes to object oriented programming languages, there are a few design principles that help you avoid design smells and messy code. These principles are known as the SOLID principles. These principles were originally introduced by Robert J. Martin back in 2000. SOLID is an acronym for five object oriented design principles. These principles are:

1. Single Responsibility Principle – A class should have one and only one reason to change, meaning that a class should have only one job. This principle helps keep code consistent and it makes version control easier.
2. Open Closed Principle – Objects or entities should be open for extension but closed for modification. This means that we should only add new functionality to the code, but not modify existing code. This is usually done through abstraction. This principle helps avoid creating bugs in the code.
3. Liskov Substitution Principle – Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T. This means that subclasses can substitute their base class. This is expected because subclasses should inherit everything from their parent class. They just extend the parent class, they never narrow it down. This principle also helps us avoid bugs.
4. Interface Segregation Principle – A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use. This principle helps keeps the code flexible and extendable.
5. Dependency Inversion Principle – Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions. This means that dependencies should be reorganized to depend on abstract classes rather than concrete classes. Doing so would help keep our class open for extension. This principle helps us stay organized as well as help implement the Open Closed Principle.

These design principles act as a framework that helps developers write cleaner, more legible code that allows for easier maintenance and easier collaboration. The SOLID principles should always be followed because they are best practices, and they help developers avoid design smells in their code, which will in turn help avoid technical debt.

https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design#single-responsibility-principle

https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/

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

This week I read a blog post that I thought really related to the class about why software development is important. The blog is about a deep dive into the career of a software developer. It starts off describing software developers as the masterminds behind computer programs. The blog then gives what different types of software developers do, like how applications software developers are responsible for designing computer or phone apps, and systems software developers are responsible for operating systems level software. Afterwards , the skills needed for software developers are shown. Some of the skills are problem-solving skills, teamwork, motivation, and analytical strategy. The blog ends with the salary of software developers($110,000), and a message to motivate the reader for the future. I selected this blog post because software development is my dream job, and I thought it would be interesting to read about what I should expect for the future job. This blog has a good, in-depth description of how Software Development works, that I think every CS major should read. I think this blog was a great read that I recommend for many reasons. One reason I would recommend this blog is because of how deep it goes into the job of a software developer. The blog goes over what to expect, skills needed, the pay, and does it all at a high level. Another reason I would recommend this blog is because a lot of jobs that we need CS-343 for will all be similar to software development, so even if you do not want to become a software developer, you can still learn something. The last reason I would recommend this blog is because it could get people who don’t like software development into the area by showing them what to expect from the job. Knowing what to expect could really help open the doors for others to be interested in this field. I learned how many of the skills that are needed for software developers I have already like Java, and I also learned the skills that I have not learned yet like DevOps. The material affected me heavily because it showed me what skills to learn, and what to expect if I want my future dream of software development to come true. I will take all the knowledge given to me through this blog into the future by getting better prepared to do this job. Now that I know what to expect from software development, I will try to build on it for the future.

https://www.rasmussen.edu/degrees/technology/blog/what-does-software-developer-do/

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

In our most recent class, one of our in class activities mentioned asynchronicity for a JavaScript function. This function required us to use the “await” keyword for us getting data. I’d thus thought of doing a post on concurrency, but in my experience in using concurrency, I’ve noticed myself and others struggling with the difference between concurrency and parallelism. Hence, in order to clearly understand concurrency, I wish to also describe parallelism. 

An application that is neither parallel nor concurrent is one that is processed sequentially, typically one “where it only has a single job that is too small to make sense to parallelize.¹”

Parallelism is simply the separation of a task into multiple sub tasks. These sub tasks are simply parallel if they are worked on sequentially. If two or more sub tasks are being worked at the same time, the program is implementing both parallelism and concurrency.

Concurrency is the act of an application working on two or more parts of an application at the same time. One thread could be running through an array, while another is doing a separate calculation. If an application is running without implementing parallelism, then it is working on each part of the application.

An application that is both parallel and concurrent can partition parts of the application and executes the program’s sub tasks concurrently. It may also include programs that divide a subtask into further subtasks and run those concurrently too.

I picked this particular source because it articulates the difference between concurrency and parallelism, rather than just one or the other. It also has a section that shows the permutations of implementing concurrency, parallelism, both, or neither. Even though I know about parallelism and concurrency, this article in particular helped me visualize them. I did not know that one could implement concurrency without parallelism. 

I feel as through this article will help me understand some elements of homework #5, because it will likely include functions that are asynchronous, and therefore require us to acknowledge it by properly implementing the “await” keyword. While this article was oriented towards locally run applications, this will also aid with applications that are executed to and from servers, by which the topics of parallelism and concurrency will still render useful.

I have also created a program that attempts to implement concurrent execution between multiple sub tasks that exist from implementing parallelism, which this article helped me understand. Specifically, I generate a vector with integers, then split the vector into subtasks which are then run concurrently. Each vector sub task gives the average sum of their respective sub task. 

Links:

1. http://tutorials.jenkov.com/java-concurrency/concurrency-vs-parallelism.html (the proper article sourced for the information)
2. https://github.com/Chris-Archive/Vector-Parallelism-Concurrency (my GitHub repository of the example I used above in C++)

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

Hello everyone and welcome to my blog! This week I decided to write a blog on design smells. In programming, we write a lot of code and even a small mistake in the code tends to break the whole program which brings down the efficiency of the code. Design smells refer to the mistakes in the code that had to do with the way the programmer wrote the code which then tends to make a lot of problems due to the design on how the code is written. Design smells are structures in the design that indicate a violation of fundamental design principles and negatively impact design quality. If a programmer focuses less on code design, later the program tends to break easily even if a small feature needs to be added to it. In the article, Mr. Fowler says code smell is a surface indication that usually corresponds to a deeper problem in the system. Design smells are easy to spot if we know about them and what they are, hence, some of the common design smells are:

Rigidity: The program breaks if a single change is made in the code, hence had to go back, and make several changes to make the code work.

• Immobility: the parts of the code if can be used in other system can’t be moved because of the high risk of breaking the original code.

• Fragility: changes in the code that could make error in the different unrelated parts to the program, hence making it difficult to even change small section of the code.

• Viscosity: Making the changes in the program in a right way is harder hence, code is easy to be broken.

• Needless Complexity: having the code that is not useful and make the code hard to understand.

• Needless Repetition: Various Repetition of functions in the code can be removed by refactoring the program.

• Opacity: The functionality of a system or feature is unclear, or the code is unclear and very difficult to understand.

I choose this article because as a programmer above things are something we don’t want in our code, by learning about design smells one can know where to find it in the code and once you find it following the best practices such as refactoring can help solve design smells. As a programmer in the future knowing about these design smells helps me later in my everyday task in my job.

Links used:

https://martinfowler.com/bliki/CodeSmell.html

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

My experience with APIs outside of classwork is very limited, so I wanted to take this opportunity to further familiarize myself with them. After a discussion in class, I am especially eager to learn more about REST APIs and how they might differ from other APIs. Jamie Juviler’s “REST APIs: How They Work and What You Need to Know” is a very good start.

Introduced in 2000 by Roy Fielding, REST APIs are application programming interfaces that follow REST guidelines. REST, which stands for representational state transfer, enables software to be able to communicate over the internet in a way that is scalable and easily integrated. According to Juviler, “when a client requests a resource using a REST API, the server transfers back the current state of the resource in a standardized representation.” REST APIs are a popular solution for many web apps. They are able to handle a wide variety of requests and data, easy to scale, and simple to build as they utilize web technologies that already exist.

REST guidelines offer APIs increased functionality. Juviler states that in order for an API to properly take advantage of REST’s functionality, it must abide by a set of rules: client-server separation, uniform interface, stateless, layered system, cacheable, and code on demand. Client-server separation addresses the way a client communicates with a server. A client sends the server a request, and the server sends that client a response. Communication cannot happen in the other direction; a server cannot send a request nor can a client send a response. Uniform interface addresses the formatting of requests and responses. This standardized the formatting and makes it easier for servers and softwares to talk to each other. Stateless requires calls made with a REST API to be stateless. Each request to the server is dealt with completely independent of other requests. This eases the use of the server’s memory. Layered system states that, regardless of the possible existence of intermediate servers, messages between the client and main server should have the same format and method of processing. Cacheable requires that a server’s response to a client include information about if and for how long the response can be cached. Code on demand is an optional rule. It allows a server to send code as part of a response so that the client can run it.

I picked this source because I thought the information was valuable. Again, I have very limited experience with APIs, even less with REST APIs, and I struggled somewhat to understand them. Jamie Juliver provides a very thorough yet easily understood overview of REST APIs. I was not aware that what sets a REST API apart from a regular API was its adherence to a set of rules. This article helped me better understand REST APIs, and I am eager to put this knowledge to use in future coursework and projects.

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

This is a topic that I have been wanting for a while to write about but never really got around to doing so until now. For this week, I am going to review a post made by Martin Fowler. In the first part of the blog post, Mr. Fowler explains what the acronym stands for and where the term comes from. Mr. Fowler than walks the reader through an example of when we could apply YAGNI. In the blog post, the example that he uses is a company having two teams work on two different components of a program (one for sales and the other one for pricing). The pricing team then predicts that in six months’ time, they will need to create software that handles pricing for piracy risks and Mr. Fowler argues that this violates the principle of YAGNI. He argues that because the team is making assumptions based on something that has not happened yet, the feature the team builds might be wrong or worse not needed or used at all. In which case, this will mean that the team wasted a lot of time, energy, and effort analyzing programming and testing something that may or may be useless. In the amount of time the team spent developing the precaution for piracy, they could have used that time working on a different required feature of the program. Furthermore, the feature they build could handle the problem incorrectly which means they might have to refactor this feature later down the line. It also adds an extra layer of complexity to the program and adds more items for the team to repair and maintain. In addition, Mr. Fowler argues this is a bad habit for people to get into. The habit of making precautions in advance because it is impossible to predict all possible outcomes and as he put it even if we tried, we would still end up getting “blindsided”.

I wanted to write about this topic now because when I was doing the intermediate assignment for Homework 4, I was thinking about how my approach was violating the single-responsibility principle because one of the methods was doing three different things. When realizing this, I started thinking about my other bad programming habits. One of which was I tended to think ahead and code things that I think the program would need and how it violates YAGNI. So, I decided to read and review a post on YAGNI because I wanted to learn more about why you shouldn’t code things in advance so that the next time that I code, I can avoid those mental pitfalls. I think reading about this blog post would help me a lot because sometimes I have a hard time making these realizations on my own unless someone brings it to my attention in discussion.

https://martinfowler.com/bliki/Yagni.html

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

When designing an API it is extremely important to get it right the first time. API calls are the backbone of you application, and without well designed endpoints your frontend will not be able to communicate with your backend effectively, if at all. If you do not design your API with forward thinking in mind, you may end up redesigning many of your endpoints and a good portion of your application as well. The good news is that API design is usually left to experienced developers; the bad news is that experienced developers still mess up from time to time.

Since designing a good API is so important, there are many standard practices which will help you with your design process. “REST API Best Practices – REST Endpoint Design Examples” is an article written by Kolade Chris which outlines nine best practices that you should keep in mind whenever you are designing an API.

To begin with the simple practices, it is important to use JSON format for sending and receiving data. Firstly this is a good practice because it is industry standard, but more importantly it is designed to be used with many of the most common frontend languages, such as JavaScript, PHP, and Python.

Practices two and three are similar since they both relate to naming convention; use nouns instead of verbs as endpoints, and name your collections plural. The reason you should use nouns as endpoints is because the verb part is contained in your HTTP request such as POST or GET, so you can do GET /items. The reason you should use plural collection names is to indicate that it is in fact a collection and not a single item.

The fourth practices Chris mentions is to follow industry standard status codes. This is very important, but also not difficult to do; simply look up standard status codes and follow those.

Practices five and six are also similar to each other; they both relate to narrowing your search. When designing an API, you should use nesting to indicate how things relate to each other, and you should also use filtering, sorting, and pagination to narrow down a request which returns multiple values. For example, if you wanted to find a specific blog post by title you could design your endpoint like this: https://blog-website.com/users/userId/posts?title=query. This indicates that the post exists within the user endpoint, and also queries based on title.

An easy but important practice is to use SSL with your endpoints. When using SSL you will have https// instead of http//. The increased security is definitely worth the expense you might need to pay.

The final two practices are the most important: use semantic versioning and provide adequate documentation. It is important to use versioning when designing an API so that users are not forced to use the most updated version, and it is important to provide documentation so that users know how to actually use the API.

Following these practices does not guarantee that your API will be designed well, but it does ensure that you won’t have basic problems with it.

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

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.