Category Archives: Week 12

So why is called REST Again…?

REST stands for REpresentational State Transfer. It was introduced by Roy Fielding as a part of his doctoral dissertation. It’s purpose is to allow the use of data while not having it tied to an entity specifically. This allows the data to be represented differently through various mediums we refer to as hypermedia. 

A RESTful interface is resource dependent. In order for an application to follow REST guidelines, it must adhere to a set of constraints. The first constraint states an interface should interact on a client-server basis. The client machine should be able to make requests to the server, and in return the server will respond according to the information it received. 

The second constraint states the client-server interaction must utilize a uniform interface. In order for the client and server to interact RESTfully, the use of Universal Resource Identifiers (URIs) is imperative. Any resource that is involved between the client and server must be identifiable in order for the interaction to be successful. 

Thirdly, all requests between the client and server must be stateless. This means that a request made from the client side must have all the necessary information so the server can complete the request. This is necessary to keep the workload on the server to a minimum as it handles various requests from different clients. The burden of keeping track of the session state of the application is the responsibility of the client, and it basically gives a snapshot of the current state to the server when the request for additional resources is made. 

The fourth constraint states that any response from the server must either be cacheable or non-cacheable. This will allow the client to reuse data from a request for a certain period of time (if the server allows it) without having to resend the request to the server.

The fifth constraint states that the client and server should have layers in between them. This allows legacy systems to have continued support as improvements and new features are added to the system. This will continue to work as long as the implementation of the interface has not been changed.

The last constraint is an optional one and it’s called code on demand. This constraint states that the functionality of a client can be extended by allowing code to be downloaded and executed. This allows the client to be simpler.

While I found all of this to be informative, I was mostly taken aback that the formulation of this architecture is to be accredited to a student pursuing their doctorate degree. It places things in perspective for me that any assignment that I am given does not only have to be completed for a grade, but it can be used as an opportunity to change the way the world interacts with things.

The information that I conveyed in this post is all thanks to two the following links

https://restfulapi.net/

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Understanding SOLID principles

This week I took a look at some of the popular acronyms that are out there and wanted to focus on the SOLID principles. SOLID is a set of design principles introduced by Robert C. Martin in the essay, “Design Principles and Design Patterns,” written in 2000. Martin argues that without good design principles, a number of design smells will occur. I thought that this would be a fitting topic to cover since I am learning about clean code in my Software Process Management class. SOLID is an acronym for a set of five commonly used principles among software developers:

Single Responsibility Principle – A class should have one, and only one, reason to change. In order to follow this principle, a class or any module should simply serve one purpose. It is important to prevent functions from doing more than one thing, which can be done by keeping them small. By utilizing this principle, code is easier to test and maintain in the future. 

Open-Closed Principle – Changing a class can lead to problems or bugs. Martin argues that you should be able to extend a class’ behavior without modifying it. In order to have a class that is open for extension but closed for modification, use abstractions. Through the use of interfaces and inheritances that allow polymorphic substitutions, one can follow this principle. In doing so, code is easier to maintain and revise in the future.

Liskov Substitution Principle – Named after Barbara Liskov, this principle requires that every derived class should be substitutable for their base or parent class. This is a way of ensuring that derived classes extend the base class without changing the behavior. Implementing this principle is like implementing the open-closed principle, as it prevents problems or bugs brought about by any class changes.

Interface Segregation Principle – The idea of this principle is that it is better to have multiple smaller interfaces as opposed to a few bigger ones. Developers should be inclined to build new client-specific interfaces, instead of starting with an existing interface and making changes. 

Dependency Inversion Principle – Martin states, “Depend upon Abstractions. Do not depend upon concretions.” meaning every dependency in a design should target an interface or abstract class. No dependency should target a concrete class. Being able to utilize this principle will make your code more flexible, agile, and reusable. 

While these principles are certainly not a fool proof method of avoiding code smells, they offer many benefits when followed correctly. It has become good practice for developers to follow these principles in order to keep code clean so as to not introduce any problems with future changes. I think this is a very useful set of principles to follow, and I plan to refer to it for anything I plan to develop in the future. These principles drew ideas from the concept of code smells and clean code, so it was interesting to finally connect the topics that I’ve been learning about in two different classes.

The Importance of SOLID Design Principles

Design Principles and Design Patterns

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

week-12

Hello blog (mood-status: feeling tired), writing this blog after the family dinner party on a Saturday night. But anyway, on writing about this week-12. Same reason from last-blog, I writing this once again because I am falling behind on blogs when there is nothing to talk about, besides kept being busy with other courses like HWs and projects, etc. (You get the point. Well, if you are a student) 

I decided to go on the Syllabus once again to look at the course topics.

Then I choose the subject of Refactoring.

Refactoring is used to restructure an existing code body, altering its internal structure without changing its external behavior. It’s small behavior-preserving transformations. Each transformation does minor parts, but a sequence of these transformations can produce a significant restructuring. Since each Refactoring is minor, it cannot go wrong. After each Refactoring, the system maintained fully working and reduced the chances of a system breaking during the restructuring.

Refactoring can help lower the cost of intensification. When a software system is robust, there is to keep intensifying it, fix problems, and add new features. But the quality of a codebase makes a big difference in how light it is to make these changes. Often intensifications are applied on top of each other to make it frequently more challenging to make changes. From setting this change, it’s essential to refactor code so that added enhancements don’t lead to unnecessary complexity.

Refactoring is a part of everyday programming. When Refactoring isn’t a particular task that would show up in a project plan, it’s a regular part of programming. When it’s needed to add a new feature to a codebase, look at the current code and consider whether it’s structured to make the recent change straightforward. Refactor the present code to make this new addition easy if it isn’t. Refactoring first in this way is faster than if it hadn’t carried out the Refactoring first.

Once the code program has finished, the change, then added to the new feature. Also, it said it apart and got it working; the notice appears that the resulting code, refactor it into a better shape return to code to become less confusing from how it works. When modifying a program, much of what needs to do already encode into the program. This code may be functions I can quickly call or hidden inside more significant parts. If it is difficult to understand the code; It refactors won’t have to work again next time.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

week-12

Hello blog (mood-status: feeling tired), writing this blog after the family dinner party on a Saturday night. But anyway, on writing about this week-12. Same reason from last-blog, I writing this once again because I am falling behind on blogs when there is nothing to talk about, besides kept being busy with other courses like HWs and projects, etc. (You get the point. Well, if you are a student) 

I decided to go on the Syllabus once again to look at the course topics.

Then I choose the subject of Refactoring.

Refactoring is used to restructure an existing code body, altering its internal structure without changing its external behavior. It’s small behavior-preserving transformations. Each transformation does minor parts, but a sequence of these transformations can produce a significant restructuring. Since each Refactoring is minor, it cannot go wrong. After each Refactoring, the system maintained fully working and reduced the chances of a system breaking during the restructuring.

Refactoring can help lower the cost of intensification. When a software system is robust, there is to keep intensifying it, fix problems, and add new features. But the quality of a codebase makes a big difference in how light it is to make these changes. Often intensifications are applied on top of each other to make it frequently more challenging to make changes. From setting this change, it’s essential to refactor code so that added enhancements don’t lead to unnecessary complexity.

Refactoring is a part of everyday programming. When Refactoring isn’t a particular task that would show up in a project plan, it’s a regular part of programming. When it’s needed to add a new feature to a codebase, look at the current code and consider whether it’s structured to make the recent change straightforward. Refactor the present code to make this new addition easy if it isn’t. Refactoring first in this way is faster than if it hadn’t carried out the Refactoring first.

Once the code program has finished, the change, then added to the new feature. Also, it said it apart and got it working; the notice appears that the resulting code, refactor it into a better shape return to code to become less confusing from how it works. When modifying a program, much of what needs to do already encode into the program. This code may be functions I can quickly call or hidden inside more significant parts. If it is difficult to understand the code; It refactors won’t have to work again next time.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

week-12

Hello blog (mood-status: feeling tired), writing this blog after the family dinner party on a Saturday night. But anyway, on writing about this week-12. Same reason from last-blog, I writing this once again because I am falling behind on blogs when there is nothing to talk about, besides kept being busy with other courses like HWs and projects, etc. (You get the point. Well, if you are a student) 

I decided to go on the Syllabus once again to look at the course topics.

Then I choose the subject of Refactoring.

Refactoring is used to restructure an existing code body, altering its internal structure without changing its external behavior. It’s small behavior-preserving transformations. Each transformation does minor parts, but a sequence of these transformations can produce a significant restructuring. Since each Refactoring is minor, it cannot go wrong. After each Refactoring, the system maintained fully working and reduced the chances of a system breaking during the restructuring.

Refactoring can help lower the cost of intensification. When a software system is robust, there is to keep intensifying it, fix problems, and add new features. But the quality of a codebase makes a big difference in how light it is to make these changes. Often intensifications are applied on top of each other to make it frequently more challenging to make changes. From setting this change, it’s essential to refactor code so that added enhancements don’t lead to unnecessary complexity.

Refactoring is a part of everyday programming. When Refactoring isn’t a particular task that would show up in a project plan, it’s a regular part of programming. When it’s needed to add a new feature to a codebase, look at the current code and consider whether it’s structured to make the recent change straightforward. Refactor the present code to make this new addition easy if it isn’t. Refactoring first in this way is faster than if it hadn’t carried out the Refactoring first.

Once the code program has finished, the change, then added to the new feature. Also, it said it apart and got it working; the notice appears that the resulting code, refactor it into a better shape return to code to become less confusing from how it works. When modifying a program, much of what needs to do already encode into the program. This code may be functions I can quickly call or hidden inside more significant parts. If it is difficult to understand the code; It refactors won’t have to work again next time.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

week-12

Hello blog (mood-status: feeling tired), writing this blog after the family dinner party on a Saturday night. But anyway, on writing about this week-12. Same reason from last-blog, I writing this once again because I am falling behind on blogs when there is nothing to talk about, besides kept being busy with other courses like HWs and projects, etc. (You get the point. Well, if you are a student) 

I decided to go on the Syllabus once again to look at the course topics.

Then I choose the subject of Refactoring.

Refactoring is used to restructure an existing code body, altering its internal structure without changing its external behavior. It’s small behavior-preserving transformations. Each transformation does minor parts, but a sequence of these transformations can produce a significant restructuring. Since each Refactoring is minor, it cannot go wrong. After each Refactoring, the system maintained fully working and reduced the chances of a system breaking during the restructuring.

Refactoring can help lower the cost of intensification. When a software system is robust, there is to keep intensifying it, fix problems, and add new features. But the quality of a codebase makes a big difference in how light it is to make these changes. Often intensifications are applied on top of each other to make it frequently more challenging to make changes. From setting this change, it’s essential to refactor code so that added enhancements don’t lead to unnecessary complexity.

Refactoring is a part of everyday programming. When Refactoring isn’t a particular task that would show up in a project plan, it’s a regular part of programming. When it’s needed to add a new feature to a codebase, look at the current code and consider whether it’s structured to make the recent change straightforward. Refactor the present code to make this new addition easy if it isn’t. Refactoring first in this way is faster than if it hadn’t carried out the Refactoring first.

Once the code program has finished, the change, then added to the new feature. Also, it said it apart and got it working; the notice appears that the resulting code, refactor it into a better shape return to code to become less confusing from how it works. When modifying a program, much of what needs to do already encode into the program. This code may be functions I can quickly call or hidden inside more significant parts. If it is difficult to understand the code; It refactors won’t have to work again next time.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

week-12

Hello blog (mood-status: feeling tired), writing this blog after the family dinner party on a Saturday night. But anyway, on writing about this week-12. Same reason from last-blog, I writing this once again because I am falling behind on blogs when there is nothing to talk about, besides kept being busy with other courses like HWs and projects, etc. (You get the point. Well, if you are a student) 

I decided to go on the Syllabus once again to look at the course topics.

Then I choose the subject of Refactoring.

Refactoring is used to restructure an existing code body, altering its internal structure without changing its external behavior. It’s small behavior-preserving transformations. Each transformation does minor parts, but a sequence of these transformations can produce a significant restructuring. Since each Refactoring is minor, it cannot go wrong. After each Refactoring, the system maintained fully working and reduced the chances of a system breaking during the restructuring.

Refactoring can help lower the cost of intensification. When a software system is robust, there is to keep intensifying it, fix problems, and add new features. But the quality of a codebase makes a big difference in how light it is to make these changes. Often intensifications are applied on top of each other to make it frequently more challenging to make changes. From setting this change, it’s essential to refactor code so that added enhancements don’t lead to unnecessary complexity.

Refactoring is a part of everyday programming. When Refactoring isn’t a particular task that would show up in a project plan, it’s a regular part of programming. When it’s needed to add a new feature to a codebase, look at the current code and consider whether it’s structured to make the recent change straightforward. Refactor the present code to make this new addition easy if it isn’t. Refactoring first in this way is faster than if it hadn’t carried out the Refactoring first.

Once the code program has finished, the change, then added to the new feature. Also, it said it apart and got it working; the notice appears that the resulting code, refactor it into a better shape return to code to become less confusing from how it works. When modifying a program, much of what needs to do already encode into the program. This code may be functions I can quickly call or hidden inside more significant parts. If it is difficult to understand the code; It refactors won’t have to work again next time.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

week-12

Hello blog (mood-status: feeling tired), writing this blog after the family dinner party on a Saturday night. But anyway, on writing about this week-12. Same reason from last-blog, I writing this once again because I am falling behind on blogs when there is nothing to talk about, besides kept being busy with other courses like HWs and projects, etc. (You get the point. Well, if you are a student) 

I decided to go on the Syllabus once again to look at the course topics.

Then I choose the subject of Refactoring.

Refactoring is used to restructure an existing code body, altering its internal structure without changing its external behavior. It’s small behavior-preserving transformations. Each transformation does minor parts, but a sequence of these transformations can produce a significant restructuring. Since each Refactoring is minor, it cannot go wrong. After each Refactoring, the system maintained fully working and reduced the chances of a system breaking during the restructuring.

Refactoring can help lower the cost of intensification. When a software system is robust, there is to keep intensifying it, fix problems, and add new features. But the quality of a codebase makes a big difference in how light it is to make these changes. Often intensifications are applied on top of each other to make it frequently more challenging to make changes. From setting this change, it’s essential to refactor code so that added enhancements don’t lead to unnecessary complexity.

Refactoring is a part of everyday programming. When Refactoring isn’t a particular task that would show up in a project plan, it’s a regular part of programming. When it’s needed to add a new feature to a codebase, look at the current code and consider whether it’s structured to make the recent change straightforward. Refactor the present code to make this new addition easy if it isn’t. Refactoring first in this way is faster than if it hadn’t carried out the Refactoring first.

Once the code program has finished, the change, then added to the new feature. Also, it said it apart and got it working; the notice appears that the resulting code, refactor it into a better shape return to code to become less confusing from how it works. When modifying a program, much of what needs to do already encode into the program. This code may be functions I can quickly call or hidden inside more significant parts. If it is difficult to understand the code; It refactors won’t have to work again next time.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

week-12

Hello blog (mood-status: feeling tired), writing this blog after the family dinner party on a Saturday night. But anyway, on writing about this week-12. Same reason from last-blog, I writing this once again because I am falling behind on blogs when there is nothing to talk about, besides kept being busy with other courses like HWs and projects, etc. (You get the point. Well, if you are a student) 

I decided to go on the Syllabus once again to look at the course topics.

Then I choose the subject of Refactoring.

Refactoring is used to restructure an existing code body, altering its internal structure without changing its external behavior. It’s small behavior-preserving transformations. Each transformation does minor parts, but a sequence of these transformations can produce a significant restructuring. Since each Refactoring is minor, it cannot go wrong. After each Refactoring, the system maintained fully working and reduced the chances of a system breaking during the restructuring.

Refactoring can help lower the cost of intensification. When a software system is robust, there is to keep intensifying it, fix problems, and add new features. But the quality of a codebase makes a big difference in how light it is to make these changes. Often intensifications are applied on top of each other to make it frequently more challenging to make changes. From setting this change, it’s essential to refactor code so that added enhancements don’t lead to unnecessary complexity.

Refactoring is a part of everyday programming. When Refactoring isn’t a particular task that would show up in a project plan, it’s a regular part of programming. When it’s needed to add a new feature to a codebase, look at the current code and consider whether it’s structured to make the recent change straightforward. Refactor the present code to make this new addition easy if it isn’t. Refactoring first in this way is faster than if it hadn’t carried out the Refactoring first.

Once the code program has finished, the change, then added to the new feature. Also, it said it apart and got it working; the notice appears that the resulting code, refactor it into a better shape return to code to become less confusing from how it works. When modifying a program, much of what needs to do already encode into the program. This code may be functions I can quickly call or hidden inside more significant parts. If it is difficult to understand the code; It refactors won’t have to work again next time.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

week-12

Hello blog (mood-status: feeling tired), writing this blog after the family dinner party on a Saturday night. But anyway, on writing about this week-12. Same reason from last-blog, I writing this once again because I am falling behind on blogs when there is nothing to talk about, besides kept being busy with other courses like HWs and projects, etc. (You get the point. Well, if you are a student) 

I decided to go on the Syllabus once again to look at the course topics.

Then I choose the subject of Refactoring.

Refactoring is used to restructure an existing code body, altering its internal structure without changing its external behavior. It’s small behavior-preserving transformations. Each transformation does minor parts, but a sequence of these transformations can produce a significant restructuring. Since each Refactoring is minor, it cannot go wrong. After each Refactoring, the system maintained fully working and reduced the chances of a system breaking during the restructuring.

Refactoring can help lower the cost of intensification. When a software system is robust, there is to keep intensifying it, fix problems, and add new features. But the quality of a codebase makes a big difference in how light it is to make these changes. Often intensifications are applied on top of each other to make it frequently more challenging to make changes. From setting this change, it’s essential to refactor code so that added enhancements don’t lead to unnecessary complexity.

Refactoring is a part of everyday programming. When Refactoring isn’t a particular task that would show up in a project plan, it’s a regular part of programming. When it’s needed to add a new feature to a codebase, look at the current code and consider whether it’s structured to make the recent change straightforward. Refactor the present code to make this new addition easy if it isn’t. Refactoring first in this way is faster than if it hadn’t carried out the Refactoring first.

Once the code program has finished, the change, then added to the new feature. Also, it said it apart and got it working; the notice appears that the resulting code, refactor it into a better shape return to code to become less confusing from how it works. When modifying a program, much of what needs to do already encode into the program. This code may be functions I can quickly call or hidden inside more significant parts. If it is difficult to understand the code; It refactors won’t have to work again next time.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.