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

Resource Link: https://www.linode.com/docs/guides/when-and-why-to-use-docker/

For this week I decided to research and write about what exactly docker is and what it’s used for in commercial applications or projects. With how much we use docker in class, I was curious as to what its other applications were and how it was used it other settings. I was curious about this because I had never heard of docker or used docker before this class, and it seems like such a useful and important piece of software. Even with just what we’ve covered so far in class, it appears to be very versatile and suitable to a variety of different applications.

This article summarizes what docker is, when and how it originated, the benefits of docker, and when and when not to use docker. I chose this article because it provides all the necessary information in a clean and concise way. While many other resources about docker were bloated and included lots of unnecessary information, this one has just the right amount of information to inform a user about what docker is, how to learn more about it, and how to get started using it. This makes it a great resource for someone new to docker, who maybe just heard about it and doesn’t know exactly what it is.

First, the article provides details about what docker is and when it was released. Docker was released in 2012, and since has become an important technology in web development. This was surprising to me because I figured I would have heard about such a big and important technology in web development, at least in one of my other classes. I figured that since I hadn’t heard of it, it must be a newer technology, but it’s already 9 years old. However, it does make sense that it would be a fast growing piece of software because of its versatility and ease of use. It makes the process of setting up and configuring a web server much simpler than it would be otherwise, and it makes monitoring those web servers easy through the docker application.

Next, the article delves into some of the benefits of docker. The benefits include reproducibility, isolation, security, docker hub, environment management, and continuous integration. Docker is reproducible in a similar way to a java application, because whereas a java application runs on a java virtual machine that is the same across all operating systems, a docker container runs in docker and is the same across all operating systems. This is very useful because it means that the container doesn’t have to be changed across different operating systems, meaning that setup time is reduced. Then, isolation is the property of a docker container where it can have instillations independent of the operating system it’s on, and independent of other docker containers. This helps to avoid conflicts between docker containers that may require different dependencies or installations. Next, with the different parts of an applications separated into different docker containers, security is increased. This is because if a single docker container is compromised, other docker containers won’t be affected. Also, different containers means that different versions of a project can be maintained independently, for example for testing. The docker hub makes it easy to find and use certain images, also leading to ease of setting up a docker container. Finally, docker can be used as a part of tools like Jenkins, meaning that when an update is made, it can automatically be saved and pushed to docker hub as an image, and put right into deployment. This cuts down on development time, and increases the ease of use by reducing the amount of work that must be done manually.

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