I decided to review a topic previously discussed during our second homework assignment this semester in Software Design and Architecture; Design Patterns. This is a much shorter video that serves as more of a refresher of five different design patterns and their main uses, advantages, and disadvantages.

Software design patterns are described as a general, reusable solution to a commonly occurring problem within a given context in software design. This is far too general to be applicable in any meaningful way. What this video provides is much needed context for what each pattern is and in what context would it be useful.

The author of this video is named Jack Herrington and he works for Nike as a Principal Software Engineer. He has written six books and is a verified authority on Software Design. The first pattern that Herrington describes is the Singleton pattern. The Singleton pattern is described as a pattern that restricts the instantiation of a class to one “single” instance. Herrington says that this pattern is very good for use in a database driver or, if you’re over on the client, the data store with the current state of the application. The pro of this pattern is that you can go and get to that data whenever you want, you just have to get the singleton and away you go. The con is that it’s very difficult to back out of a singleton pattern and that it can be very restrictive.

The second pattern discussed is the Facade pattern; this pattern is an object that serves as a front-facing interface masking more complex underlying or structural code. This can improve readability but may also mask some functionality, thus requiring the consumer to do a bit of work to access the feature that they want. Third is the Adapter pattern; which allows the interface of an existing class to be used as another interface. Herrington uses his camera as an example, how the body of the camera serves one main purpose and is then modified by the interchangeable lens. The main draw of this is that it can be applied to almost any app and allows for additional functionalities, only limited by the “body” of the app. The pitfall is that many developers overuse this pattern and complicate too much of the app, thus damaging the quality.

These were the first three and I highly recommend you watch the video to learn more about each of them. I plan to take this knowledge with me and keep an eye out in my career for different uses of each of them and try to better understand why each pattern is used in professional settings and what each of them accomplish differently.

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

Self-Directed Professional Development Post #7

For my last blog post, I’ve decided to review an article titled, “HTTP Methods” from the website, https://restfulapi.net/http-methods. The reason I picked this article is because 1. it directly relates to one of our course topics, “REST API Design” and 2. it helps me further prepare and review for my upcoming final exam. In addition to the resources that I have from the class POGIL activities, I wanted to find another resource to solidify my understanding of HTTP methods. In this post, I will start by going over the 5 HTTP methods and the information I’ve gleaned by reading this article, and then I will move onto a reflection on how effective this article was in helping me learn this course topic.

In the list of review topics for my upcoming exam, I’m asked to know what the HTTP methods are used for and how they differ depending on whether I am referencing an entire collection or a single element in a collection. In the article that I’ve selected to read, the HTTP GET method is discussed first. I’m reminded that the GET method is used to retrieve information and that it can be used for both a collection and a single resource. This lines up pretty well with what we have learned from our class activity 12 (see table in Wikipedia citation below). Next, HTTP POST is brought up in the article and we learn that it is used to create a new resource in a collection. We are encouraged not to use POST on a single resource/element and this corresponds with the information from activity 12. Subsequently, the article discusses the HTTP PUT method. We learn that PUT is used to update an existing resource or create it if it does not already exist. PUT methods can be used on both elements and collections (this also matches up with the information learned in activity 12). In fourth place, the article discusses the HTTP DELETE method, one of the more straightforward methods, that can delete single elements or an entire collection. Lastly, with HTTP PATCH, we learn that it can be used to make a partial update on a resource and that it is usually used on elements. Personally, I preferred the description of this method over the one given in activity 12 but the article did support the point that PATCH is not usually used on an entire collection.

Finally, once I was done reading/taking notes on the article, I felt even more confident in my understanding of HTTP methods. I thought the article was both straightforward and educational, and therefore effective. The language was easy to understand and it provided me with another perspective to learn the class material. I would recommend this article to anyone else who is learning about HTTP methods for the first time or simply needs a refresher on the topic.

Article:

• https://restfulapi.net/http-methods/

Wikipedia link:

• https://en.wikipedia.org/w/index.php?title=Representational_state_transfer&oldid=866461276

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

https://www.dossier-andreas.net/software_architecture/fsm.html

A finite state machine is an abstract model of computation. In the context of software development, it can be used as a way to control and conceptualize the flow of a program.

Finite state machines consist of a number of states, each representing a particular behavior of the system. These states have transitions between them, defining when the system may change from one state to another. Transitions can be thought of as connecting the states like a graph (specifically an ordered graph, with two states that can change to each other represented by two separate transitions). The graph is not necessarily complete or acyclic. The state transition also defines what actions must be taken to change the system from one state to another.

I like most of the articles from this blog, but I found this one a little lacking. In particular, the “Examples” and “When should you use it?” section, which really don’t say anything meaningful.

The examples section states two examples without elaborating: A coffee machine and “Games” (just, in general I guess). Here’s how I would model a coffee machine (knowing nothing about how they actually work and just going off how I’m used to them behaving):

The coffee machine begins off. In this state, it can only be turned on, which starts it in the “awaiting input” state. From there, you can press a button to have it actually make the coffee. For the sake of simplicity, giving it water and coffee grounds are handled by a human and heating the water is rolled into the “dispensing water” step (I would place it in between “dispensing water” and “awaiting input”, connected to both of them and also to “off”). A sensor would detect whether there is actually enough water to make coffee and move to either the “dispensing water” or “error” state accordingly. The “dispensing water” stage just pours the coffee and either moves to the “awaiting input” state when finished or the “error” state if it runs into some kind of problem. The error state simply displays a message and then returns to the awaiting input state. At any point, the machine can be turned off, but once turned on can only start at the awaiting input state.

Note that this is not really helpful at all for building an actual coffee machine. It is, however, helpful for simulating a coffee machine programmatically, and a similar thought process can be used to break down almost any kind of behavior.

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

In this week’s blogpost, after seeing a piece of code in a previous assignment I wanted to learn a little bit more about what it actually was. The piece of code in JavaScript used async and await, and me being a novice in JavaScript didn’t exactly know what it was, but did a little bit contextually. At first glance they seem like timed functions to synchronize something. In exploring what these were I came across this article on error handling in JavaScript.

https://www.valentinog.com/blog/error/

This blog goes into great detail over error handling in JavaScript, and I’ve learned quite a bit more as well as answering the async and await question.

First off, I did not know that JavaScript was single threaded, meaning that it doesn’t utilize multi-threaded processes to handle certain bits of logic simultaneously. The article gives a good example with a timed error throw with an error catcher to demonstrate how the try/catch will already execute before the error would ever be called.

I was also introduced to some new interesting features of JavaScript like Promise. Promise is indicative of it’s name and is basically like a promise of the code to catch up with each other later. Promise uses “.then”, “.catch” and “.finally” where the only real difference is in name for “.then” as it’s the counterpart to “try”. It also has some more singular uses like “.all”, “.any” and “.race”. These are just different methods for finding an error. All will take an array of “promises” and find any of the errors from the promises and return the promises that resolved. Any will give you the first of the “promises” that resolved. Race is basically just a race to see who completes first regardless of error or not.

Asny and Await are two functions that you generally prefix to another function. Async forces the function to return a promise which allows us to use the Promise “.then”, “.catch” and “.finally” to resolve outside the function. But it doesn’t also mean that we can’t use try and catch as with “await” it allows us to literally wait for a function to resolve and with try and catch we can handle the errors inside of the current function.

Overall this article was very helpful. My intention was to just find an explanation as to what async and await meant, but I ended up with a little crash course on interesting ways of handling errors in JavaScript, as well as clear meanings behind each one.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

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

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

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

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

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

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

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

Hello and welcome to the last post of my blog. I’ve really enjoyed writing these throughout the semester since it helped me learn more about computer science and programming in general. For this last week, I will talk about refactoring. It is one of the most important concepts to grasp in programming because it can greatly improve your code over time. Refactoring is a way of rewriting and improving code without changing the functionality of the original code. Your code may be hard to look at or understand by other programmers so you may want to refactor it to make it easier to read and understand.

Your code should be clean so you don’t end up having technical debt later on. Rushing your coding to meet deadlines will pretty much guarantee messy code and you should start refactoring early on so that the messy code does not keep piling up. When messy code keeps piling up, it becomes more of a burden to refactor and the programmer may become more unmotivated to fix it. When you refactor code, you want to make sure all your variable and method names make sense and provide some context. For example, the variable name “x” does not provide any information about what information it stores or what it is used in. Instead, your variable name should be more specific, like “accountNumber.” Having more specific variable names also helps other programmers identify what your code does exactly.

You want to start looking at refactoring at specific times during your coding process. Refactoring Guru talks about the “Rule of Three” which means when you have to code the same thing for the third time you should consider refactoring. Also consider beginning to refactor when you add a new feature because someone else’s code might be too messy to read and you need to refactor to clean it up. That also makes it easier to implement additional features later down the line. You should also consider refactoring close to the deadline of your project since it will be the last chance to make changes to the code. Your project will become open to the public and you do not want other people to see your messy code.

When you refactor, the code should become cleaner and still maintain its functionality. Sometimes you may have to completely rewrite some parts of your code in order to do this. Other times it may just be as simple as adding some spacing or renaming a variable. All your tests should still pass after refactoring. If a test fails, you messed up somewhere and made an error.

In the past, I have done some refactoring myself and I hope to continue to practice refactoring to keep my code clean, easy to understand, and easy to manage.

https://refactoring.guru/refactoring

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