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.

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 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.

Source: https://www.guru99.com/microservices-tutorial.html

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

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.

Article: https://www.partech.nl/en/publications/2020/10/basic-principles-of-object-oriented-programming#

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.

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.

https://www.ibm.com/cloud/learn/rest-apis

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