As I was browsing YouTube, a video appeared in my recommended videos titled “5 Design Patterns Every Engineer Should Know” from someone named Jack Herrington. Thinking it would be good review I clicked on the video. I wanted to see if were familiar with the five patterns in the video.

The video discusses patterns from the “OG” design pattern book: Design Patterns by the “Gang of Four”. The five patterns are the Singleton Pattern, the Façade Pattern, the Bridge/Adapter Pattern, the Strategy Pattern, and the Observer Pattern. He explains all of these in order as he goes through the video.

Of these, the only one I was unfamiliar with was the Observer Pattern. He explained it simply as there being a publisher and a subscriber with the subscriber listening for events from the publisher.

Something from the video I found interesting was a compiler as an example of the façade pattern. Often you can’t access all the parts of a compiler and it is abstracted to be usable to you as a consumer of that product.

Below the video in the comments, someone mentioned the Head First Design Patterns book. I remember looking at this book in class before and it reminded me to go find it and look at it further. Unlike the Gang of Four book it is written in Java so I have a bit of an easier time understanding what is going on in the book.

This video was helpful as a reminder that there are many design patterns and many resources to help learn them. The final project includes using design patterns so I will look back at these resources to identify what patterns will be helpful in the situations I encounter as I work on the project.

 It was also a helpful reminder that design patterns are not necessary everywhere. Many people in the comments posted about knowing when to use design patterns. There are tradeoffs and consequences to using certain design patterns and it is important to take these into account when choosing to use a pattern in a situation. For example, using the singleton pattern makes life simple. Using it for something like a database driver makes accessing data easy, but it also makes your system inflexible. Whoever is the consumer that is using the database driver also has to have that on their computer to be able to access the database.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

This week we began to discuss REST APIs. While it was explained in class, the concept kind of went over my head so I wanted to look more into what they are. While looking around I found a helpful article from sitepoint.com

The author explains it with an analogy. A REST API is a way for two systems to communicate over HTTP. This is like when you get car insurance. The insurance agency must get data from the government, credit agencies, banks and other systems.

He goes on to give an example of a REST API that just shows a bad joke.

He also talks about the other data communication standards like CORPA and SOAP. They are much stricter than REST which is not a standard but a set of constraints that must be satisfied for an API to be RESTful.

The next section discussed was something we covered in class, requests and responses. He also includes an example for the reader to try at home.

REST APIs also have some challenges associated with them. One is that there are multiple endpoints that can be used to fetch the same data like:

• /user/123
• /user/id/123
• /user/?id=123

This can make is hard to be consistent on a large project with many developers.

It is also important to keep your application secure and a REST API provides another level that needs to be secured.

The author ends with additional articles and links to learn more about REST APIs.

A lot of what this article covered was also covered in class, specifically the part about requests and responses. I feel like what we discussed in class was clearer and more made more sense. This is probably because we were talking about it and could ask questions if necessary.

What was useful from this article was the REST API example. I did try the example myself and it worked with no issues, though this is to be expected as it was just copying and pasting the code. I would have liked if there were more explanation, but this was a simple example so not much more could be said.

The author here assumes that the reader is familiar with JavaScript. I am new to JavaScript, but this example was simple enough that I could understand what was going on. I don’t anticipate us doing an example this simple in class, but it was helpful, nonetheless.

https://www.sitepoint.com/developers-rest-api/

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

For the past few weeks, we have been working a lot with Docker and how to use it. Coincidentally, I came across an article describing some best practices when using Docker. Some of the things in the article were even things we used in class.

Many things were given to keep in mind. There is size. Images should not waste space, especially as it could be a security concern. Using Alpine Linux is a great way to save space though it may not always be appropriate. It is also important to keep your Dockerfile current. Using the latest tag is one way but the author also says to check regularly to make sure you really are building from the latest version. The author also mentions a new tool called docker scan to find known vulnerabilities in your Docker images. There is a lot of emphasis on Docker containers being simple and easy to create and take down. The system should be designed to do so without adversely affecting your app as that is the whole point of Docker. At the end of the article there are additional links to more articles about Docker by the same author.

I selected this article because it is relevant to the current course material. We have been using Docker in all our classes for the last few weeks. As I was reading the article I recognized where the author says use “Use Alpine Builds” because we do use those in class. The article even explains to use “FROM alpine”, something we start our Dockerfiles with in class.

Because the tips in the article were kept very general, I was able to understand most of it. For more technical articles I often get confused or lost, especially since I have no experience working in the software development industry. Reading this article made me realize how far I have come since I started the CS major. Going in I had no programming experience and little to no aptitude when it came to computers. Seeing the things we learn in class actually be relevant in the real world is a very validating thing. It proves to me that I am actually learning, something that is only more difficult with remote learning.  

I hope to be able to use this article going through the course and on the final project. These tips should help me get the most out of Docker.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.