Category Archives: Week 8

Code Smells

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.


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


Throughout the semester, we talked about microservices here and there and went over them in several activities and look to continue working with them in the coming weeks. This blogpost will be dedicated to them and their architecture. I have chosen an article written by Alyssa Walker that takes what we have already seen in previous activities and takes them into a greater level of analysis than previously looked at and also includes information about SOA I had not known about. This I deemed good enough to write a blog post about.

In summary of what I have read from the article, microservices is a type of architecture pattern in which services are provided to other parts from applications. Alyssa goes into monolithic architecture and compares the two in detail with a focus on the cons of monolithic architecture and pros of microservices. Microservices have several advantages such as with the start of time and the allocation of resources in different sectors is much easier to manage than with monolithic. The separation of the services make it much easier to work on making changes to the program in cases of faults in which availability will be there unlike in monolithic. She also includes talking about service oriented architecture in general and how microservices are an implementation of SOA.

This article has taught me several things about the different kinds of architecture we have and some reasons for why we are using microservices instead of monolithic in our activities. Microservices also seem to be a relatively newish idea, coming to fruition somewhere in the 2000s, which makes sense as how the computing world changed quite rapidly during the past few decades and how docker is a tool used for microservices. The advantages are quite useful to us such as with team members as we are not exactly a large team working on this project in which a larger team would be needed for a monolithic style project. Also considering the nature of this project and how it is being helped developed by students, there are probably going to be numerous faults that need to be fixed in which microservices would benefit better due to its separated services. It also makes me wonder of the issues that would arise in our food pantry program if we were to use monolithic architecture instead. This information in general will help me understand our work down the line as we work on the LibreFoodPantry program eventually and in the future as we develop into our careers and work with microservices in other places.


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

Software Frameworks

What are they?

A software framework is a structural or conceptual platform that allows developers and users to selectively specialize or override common code with generic capabilities. Frameworks are libraries that have a well-defined application program interface (API) that may be used anywhere in the product being developed. Software frameworks are adaptable, resilient, and efficient because they are frequently designed, tested, and optimized by numerous skilled software engineers and programmers. Developing apps with a software framework allows you to concentrate on the application’s high-level functionality. This is because the framework handles all of the low-level functions.

Top Frameworks


Angular is an HTML and TypeScript-based platform and framework for creating single-page client applications. TypeScript is used to write Angular. As a set of TypeScript libraries that you load into your apps, it implements core and optional functionality. An Angular application’s architecture is based on a few key ideas. The Angular framework’s fundamental building pieces are Angular components, which are arranged into NgModules. NgModules are functional groupings of linked code; an Angular application is defined by a set of NgModules. An application must include at least one root module to facilitate bootstrapping, and many more feature modules are common. Some popular website that used Angular are Netflix, Youtube, Django etc

Apache Spark

Apache Spark is a large-scale data processing engine with a unified analytics engine. Using Apache Spark, you can easily create apps in Java, Scala, Python, R, and SQL. Apache Spark can handle data from Hadoop Distributed File System (HDFS), NoSQL databases, and relational data stores like Apache Hive. Spark can do in-memory processing to improve the efficiency of big data analytics applications, but it can also perform traditional disk-based processing when data sets are too huge to fit into system memory. Some top companies that used Apache Spark are Amazon, Microsoft, Oracle, Visa wtc


Torch is an open-source machine learning tool based on the computer language Lua, while PyTorch is a Python machine learning package based on Torch. PyTorch, which was created by Facebook’s AI research lab, may be used with both Python and C++. PyTorch is a programming language that is used for computer vision and natural language processing (NLP). The following are some examples of popular websites built with PyTorch: Comcast, Exelon, Trifo, Quadient etc

Why this topic?

I’ve been hearing about frameworks for a long and have even had talks about them while not understanding anything about them. I learned what frameworks are, how they function, and which frameworks are most commonly utilized by well-known firms. I’ve also learned that as a developer, it’s important to understand what frameworks or programming languages I will need to create the application I desire.


From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.


In class, we did some activities about design smells, their definition, and what they do. So I was interested and decided to dig deeper and learn more about different design smells. I was curious because as a computer science major, I think knowing about design smells is very important especially how to avoid them.

In computer programming, design smells, also known as “code smells” are structures in the design that indicate a violation of fundamental design principles and negatively impact the design’s quality. Code smells are not bugs or errors. Instead, these are absolute violations of the fundamentals of developing software that decrease the quality of code.

Code smells indicate a deeper problem, but as the name suggests, they are sniffable or quick to spot. The best smell is something easy to find but will lead to an interesting problem, like classes with data and no behavior. Code smells can be easily detected with the help of tools.

How to get rid of code smell?

Code smells can lead to a serious defect in a program, failure of the whole system, and many others.

Once all types of smells are known, the process of code review begins. Two or more developers may use the primary method, the ad-hoc code review process to try and identify such smells manually. Many smells are not possible to be found by manual reviewing and automated code review tools are used for identifying such bad smells.

Code smells knowing or unknowingly are introduced in the source code, and may also form if you are solving other smells. Developers discard most of the smells consciously because they seem to have a marginalized effect or are just too hard to explain.

When developers find smelly code, the next step they do is refactoring. Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the software yet improves its internal structure. It may be the single most important technical factor in achieving agility. The goal is to stay within reasonable operating limits with limited continual damage. By staying within these limits, you keep costs low, because costs relate nonlinearly to the amount of repair necessary. Refactoring is a process in which the code is divided into smaller sections according to the identified smells.

A decision is then made to either remove them or replace them with a better series of code that may increase code quality and enhance some nonfunctional quality simplicity, flexibility, understandability, performance. After refactoring, run tests to ensure things still work correctly. Sometimes this process has to be repeated until the smell is gone.

I chose this topic because, as a computer science major with a concentration in software development, knowing about code smells is very important. When writing codes, we are supposed to be aware of this, so when it happens we know what to do to get rid of them.

What is a Code Smell and How to Get Rid of It? – QATestLab

What are Code Smells? | How to detect and remove code smells? (

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

The Four Principles of Object-Oriented Design

A programming language supports object-oriented design when it contains features that allow programmers to apply four principles: abstraction, encapsulation, polymorphism, and inheritance. When my class was reviewing the principles, I realized we were struggling to define and provide real-world examples of them. Because an understanding of the principles is fundamental to applying them, the goal of this post is to review and provide real-world examples of them. To review the principles, I will be reflecting and adding onto ParTech’s article, “Basic Principles of Object-Oriented Programming,” which defines and describes the principles.

Abstraction is the process of packing details of a real-world phenomenon into a simplified representation. ParTech describes the process of making coffee with a machine as an example of abstraction: “You use a button defined interface to make coffee, without needing to worry about the internal working of a machine.” In other words, a coffee machine’s button hides (or abstracts) the science the machine carries out to make coffee. A button on a coffee machine is an effective example because we only need to know what button to press to make coffee rather than the machine’s internal systems, such as its circuitry and fluid transfer apparatus.

Encapsulation is the process of packing data and operations that manipulate the data into objects.  ParTech describes a medicine pill as an example of encapsulation: “All the medicine(objects) are stored inside the pill (class) and you can consume it whenever needed.” In other words, a pill and its contents are analogous to a class and its data members respectively. While ParTech is not wrong for using a pill as an example of encapsulation, I believe they explained it as a comparison rather than an example. A pill is an effective example because it has qualities (data) and operations humans can perform on it. Its qualities include a name, expiration date, and composition. Its operations include purchasing, disposing, and consuming.

Polymorphism is the state of having many forms. ParTech uses method overloading and overriding as examples of polymorphism. While method overloading and overriding are effective examples of polymorphism, they are not real-world examples. A real-world example of polymorphism is a person because a person can be a student, husband, and chef at once.

Inheritance is the practice of giving the data members of one class to another class. ParTech does not provide an example of inheritance. To understand inheritance, one needs to recognize that many objects are of the same classification. For example, a student, husband, and chef are people. The student, husband, and chef have the characteristics of people plus other distinct characteristics. If we were to implement my example in code, inheritance is the feature that will allow us to give the people characteristics to the student, husband, and chef without rewriting the code for it.

With a stronger recognition of how the object-oriented principles apply in real life, I can better translate them into software during my course and career.


From the blog CS@WORCESTER – Andy Truong's Blog by atruong1 and used with permission of the author. All other rights reserved by the author.

Blog post 3 – REST API

After spending some time in class working with the REST API, I found myself still having questions regarding what it is and how it works. I decided that I should do some further reading on my own, and I thought that I should make a blog post explaining my findings. I read several articles, but one article in particular by IBM I think describes REST API the best.

Before we delve into REST itself, we first have to understand what an API is. API stands for application programming interface; it is a set of rules that define how applications or devices can communicate with each other. It’s a mechanism that allows applications to access resources within other applications. The application that is utilized to access the other application is called the client, while the application that contains the resources being accessed is called the server.

REST API is an API that uses REST principles. Unlike other APIs which have pretty strict frameworks, REST is pretty flexible. The only necessary requirement is that the REST design principles, or architectural constraints, are followed. These are:

  1. Uniform interface – All API requests for the same resources should be the same regardless of where the request came from.
  2. Client-server decoupling – The client and the server need to completely independent of each other. The client should only know about the URI, or the Uniform Resource Identifier, and the server should only pass the client to the requested data via HTTP.
  3. Statelessness – All requests need to include all the information necessary to process them.
  4. Cacheability – Resources should be cacheable on both the client and the server. The server should also know whether or not caching is allowed for a delivered resource.
  5. Layered system architecture – The calls and responses go through different intermediary layers.
  6. Code on demand – Usually, REST APIs send static resources, but in some cases, they can also contain executable code. In such cases the code should on run on-demand

I didn’t know that REST API had design principles, so this was new information to me. However, so far, I only discussed what REST API is, we still need to understand how it works. REST APIs communicate using HTTP, Hypertext Transfer Protocol, requests to perform basic functions in databases like creating, reading, updating, and deleting data inside a resource. For example, a GET request would retrieve data, a DELETE request would remove data, a PUT request would update data, and so on. All HTTP methods are able to be utilized in API calls. Another thing to note is that the resource representation can be delivered to the client in virtually any form including JSON, HTML, Python, and even normal text files. Finally, it’s important to note the request headers, response headers, and parameters in calls. They’re important because they contain vital identifier information such as URIs, cookies, caching, etc.

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

Docker Compose

For this week’s blog post, I am reviewing a blog post made by Gabriel Tanner. Mr. Tanner is a software engineer at Dynatrace and in this blog post, he talks about the characteristics of Docker Compose, why we should use Docker compose. Mr. Tanner starts the blog post about why we have/use Docker.

“With applications getting larger and larger as time goes by it gets harder to manage them in a simple and reliable way.”

The first feature about Docker compose that Mr. Tanner talks about is its portability and how it can construct and destruct a development environment using the docker-compose up and docker compose down commands respectively. The blog post also goes common uses of Docker compose and common reasons why people use Docker compose. Some examples of common uses of Docker are its ability to run several containers on a single host and to run your program in an isolated environment. An example of a common reason why people use Docker compose is people might want to run their program in an environment similar to the one used in the production stage. The post also goes on to talk about volumes and the different types of volumes and their syntax, networking so that our containers can communicate with one another and many other different topics.

The entire blog post is basically one big tutorial about Docker compose. It defines the features of Docker compose, gives examples of its uses, and explains why we should use it. I think this is a blog post that is worth reviewing for this class because I think it could be a really good resource to have in the class. The post is a little long, but it is very thorough. I think it would be a good way to review Docker compose before a midterm or final. In addition, the blog post also covers a lot of information that we have not done over in class, so it also provides a way for us to investigate and learn more deeply about the topic. For the first half of the blog post, it covers material that we have already covered in class but in the second half of the blog post, it covers a lot of features about Docker that we have not yet covered in class such as using multiple Docker compose files by passing an optional override file. This is a feature of Docker that I can see myself using in the future and is a feature that I wish I had learned sooner. A couple semesters ago, I was doing a project in MatLab and Java and was running several large programs on one computer. This made the project very time-consuming and difficult because it took a long time to run all of the programs, generate and collect all of the results. Had I known what I know now about Docker, I would have done a lot of things differently.

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.

Anestiblog #2

This week I read a blog post about the top 10 most popular software architecture patterns, and I thought it really related to this class. The blog starts off going into what software architecture patterns are, and why it should be focused on. The blogger describes the patterns as an outcome of the design principles architects use and the decisions they make. The blogger thinks it should be focused on because it enables a software system to deliver its business, operational, and technical objectives. The blog then gives some tips on how to know if your patterns are good, and then lists the 10 most common patterns. The blog ends on how to evaluate which pattern is best for your project. I selected this blog post because from last week I wanted to go deeper in the world of software architecture, and I thought the different patterns was a good way to go. I think this blog was a great read that I recommend for many reasons. A huge reason was that it really is good at giving background information before really getting into the list, so that you understand what a software architecture pattern is. Before I read the blog, I had no idea what it was, and that made me want to learn more, and this blog helped with that. Another reason I would recommend reading this blog is because it gives the top 10 most common patterns. That is important because for a career in this field, you have to know the most common patterns because those are the ones that will be used the most in future jobs. If anyone is thinking about a career in this field then they should definitely know the 10 patterns. The last reason I will mention is that in the end, the blogger explains that to get the right pattern for your application, software architects with that skill are the most sought after, so it really should be a big reason to learn more about patterns because you can really use it to your advantage. I learned what the software architecture patterns are, and that the software architecture models make it easy to reuse them in other projects since you now know the decisions and trade-offs. I also learned that the interpreter pattern, and the layered architecture pattern are two of the most well-used patterns, as I think I have done something similar to them before. This material affected me hugely because it showed how important the patterns are to software development, so it showed that I will be needing it if I ever want to become a developer in the near future, so it is really great to know this stuff. I will take all of this knowledge with me as I continue in my career. Everyone who wants a career in software development just has to read this blog as well.

link :

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.

YAML (You Always Make Logs)

While working with YAML files is a relatively new concept for me, I must say that the structure is somewhat similar to another style of coding I am more familiar with: CSS. The two are not exactly the same, however the “key: value” format makes coding with YAML files that much easier. As noted later on, the importance of indentation in YAML reminds me of Python, a familiar programming language.

As part of the title, I have decided to make my own acronym for YAML: (Y)ou (A)lways (M)ake (L)ogs. This is because I view YAML files almost like logs for a certain state of a project; each one consists of all the different elements that make up a certain level of a SemVer state. In fact, YAML files consist of all the different materials that have been seen in this course before; ports, images and more make up a YAML file. In addition, these files are often used with preview software (such as Swagger) to create visualizations of APIs.

In the link below, one can find a video that explains the structure of YAML files. This information is alongside applications of the files, and even a tutorial for setting up a YAML extension in Visual Studio Code. I have chosen to watch this video on YAML files for two reasons: first, I need more practice with YAML, and in my opinion, increasing my exposure to it is the best way to gain more experience. Second, videos are a preferable source of educational media in my opinion; having visual examples helps to get the idea across better than simple discussions.

An example of a very simple YAML file. Notice how it starts with “version: (SemVer Value)”.

YAML files can be simple, like the one shown above; they can also be thousands upon thousands of lines of code. Traditionally, they start with the version number, and are also dependent on proper indentation (similar to Python). Features of a YAML file can be as significant as a docker image, such as nginx; features can be as focused as making an element “read-only” within an API endpoint.

Among everything else, it is important to emphasize and take away this lesson from YAML files: these files are a core component of software design, connecting several familiar aspects together. By learning about YAML, I can figure out a way to run images, map ports and even more, all within a single file called by the “docker-compose up” command. Personally, I feel as though YAML will be an invaluable resource in future IT endeavors; while software such as Git focuses on the level of version control, YAML focuses on what exactly goes on in that level.


From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

UML Diagram

UML stands for Unified Modeling Language. It is a way of visualizing a software program by using a collection of diagrams. The main aim of UML is to define a standard way to visualize the way a system has been designed, it is not a programming language but rather a visual language. In 1997, UML was adopted as a standard by the Object Management Group (OMG) and still it has been managed by it. UML diagram is used with object-oriented programming and is organized into two distinct groups which is Structural diagrams which represents the static aspects of the system and behavioral Diagram which represents the dynamic aspect of the system.

The Class diagram is a kind of Structural diagram, it shows how the code is being put in the system and one can know the different aspects of the code just by looking at the class diagram. While looking at the class diagram there are three sections: Upper, Middle, and Bottom. The upper section contains the class name, The Middle section contains the attributes of the class and The Bottom section includes class operations (methods). The Class has different access levels depending on the access modifier (visibility) and they have symbols such as Public (+), Private (-), Protected (#), Package (~), Static (Underlined). These symbols help one to identify the visibility of different attributes just by looking at the symbols. Classes are connected with each other in different ways such as Association, Multiplicity, Aggregation, Inheritance, Composition, Bi-directional, and so on. This helps if a class has been inherited from different another class by using the sign by which it connected the other class, which helps the viewer to understand the UML diagram easily.

I used this topic because it helped me a lot in understanding how the UML diagram works and the different properties. Homework 1 was based on the UML diagram; this article goes over everything you should know to create UML diagrams. It also has links that explain more about the subject matter and makes things clear. And because I am interested in software development, UML is one of the main tools for software engineers. In the future, the class diagram is important too, since it’s object-oriented and helps when working on a big project. The topic provided examples that made it easy to understand different concepts of UML diagrams such as the visibility of attributes, arrows that show how classes are connected to each other which makes the whole concepts of the UML diagrams easy to understand.

The article used:

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.