Considering how far along we are now in the semester, I decided to revisit a much earlier topic, design patterns. For this week’s blog post, I am going to look at a post by Ravi Kiran, a research analyst at Edureka. In class, we covered what are design patterns and what are some examples of design patterns and in this blog post, Mr. Kiran starts off the same way by introducing the audience to what are design patterns and why we use them. Then he begins to talk about what are the four categories of design patterns which are creational, structural, behavioral, and JEE (Java EE-based). The blog then proceeds to list examples of design patterns, what categories the design pattern falls under, and explains a little bit about why that design pattern falls under that specific design pattern category. The blog post does not explain all of the examples but instead for the ones that it does explain, it explains it very well in the form of a UML diagram and snippets of Java code. In addition to all of the technical information, this blog post gives us, it also gives real-world examples where that design pattern can be applied.

I chose this topic because when we were learning about this topic in class and when we did a homework assignment, I found the topic to be very interesting. I really wished we had spent more time on this topic in class. It was only after reading this post that I realized in class and on the homework, most of the design patterns that we covered in class fall under the creational or structural categories. After learning about the Singleton pattern in class and working on it on the homework, I think conceptually I understood the topic, but after not working on it for some time and revisiting the topic, I think I understand it better now than I did back then. One of my regrets early on in the semester was not doing the Advanced Assignment working with the Factory design pattern. When I was reading about that design pattern for the assignment, I found it interesting and thought I understood the topic, but I did not do the assignment because I was not sure if I understood the topic well enough to do the assignment. After reading more about the topic and seeing the UML diagram, it validated my thinking about the topic. I am the kind of person who second guesses themselves a lot and after reading this blog post, it makes me want to just go for it the next time I don’t quite understand something or understand it completely. I feel like if I just did the assignment back then I probably could have done it but I second-guessed myself.  

https://www.edureka.co/blog/java-design-patterns/

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.

Hello everyone! Hope everyone is doing great! In This week’s blog post I want to write about the front end and the back end and what are the differences between them. Front end and back end are the two most popular terms used in web development and they are very crucial for web development and are quite different from each other. Web development is the process of building websites and applications, Unlike UI UX Design, web development focuses more on coding and making sure the website functions well. Both the front end and bank end need to communicate with each other for the website to operate effectively and to improve the website’s functionality.

Front-end development is a style of computer programming that focuses on the coding and creation of elements and features of the website. This is the part of the website that the user interacts with and can be also referred to as the ‘client side’ of the application. This means as a front-end developer your job is to code and bring to life the visual elements of the website. It includes everything that users directly experience such as text colors and styles, images, graphs and tables, buttons, colors, navigation menu, animations, and content organization. The languages used in Front end development are HTML, CSS, and JavaScript. Responsiveness and performance are two main objectives of the Front end. The developer must make sure the site is responsive.

The back-end is also referred to as the “server-side” of the website and focuses on the side of the website user can’t see. It stores and arranges data, and makes sure everything on the client-side of the website works fine. As an example, let’s say you are using a social media website, you need an accessible place to store all the user’s information, this storage is called database systems such as Oracle, SQL Server, and MySQL, these are not seen by users and done at the back end of the website. Back-end uses languages such as PHP, C++, JAVA, Python, JavaScript, and Node.js.

The difference between the frontend and back end is that they work on different sides of a website which is the client-side and server-side, both have different strengths, both work in different languages. I used this article because it makes the front end and back end very easy to understand and In the future if I work as a web developer it’s very important to know about these concepts.

https://www.kenzie.academy/blog/front-end-vs-back-end-whats-the-difference/

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.

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.

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.

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.

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.

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.

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.

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.

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.