The Breakable Toys pattern is about creating your own projects that allow you a safe place to experiment with new ideas and become more comfortable with your toolset. A project where you can try unconventional things to improve your skill, but where it doesn’t matter if they fail. The project they recommend for this is creating a wiki for yourself, to help learn multiple facets of design techniques.

I really liked this pattern and the idea that it promotes. Working on a rigid system that many people use, or whose functionality is necessary for the operation of your job, there isn’t really any room to try new things and grow. So having your own little workspace to try new things seems like a great way to build your knowledge in an environment that is completely your own. Like a chemist having a chemistry lab to experiment, it is important for software developers to have a place to experiment themselves. I also really enjoyed the idea of maintaining a project like this across different jobs, always having a place to try new things and to try new techniques when you are stuck on something. I think that implementing this into my own life will allow me to grow as a developer and gain new skills and insights that I would never have the freedom to do in a work environment.

The recommended “action” for this pattern is to build a wiki, and while I think this is a good example, I don’t think that that would work for everyone. So I think that if anything, I disagree with that specific recommendation, as I feel that depending on what is necessary for your work, a wiki might not need the tools that you need to work with or work on. So while I think it is a good example, I think that the individual has to come up with a project of similar scope that better matches what they need.

Overall, I think that this pattern is a very good piece of advice. Any profession can have difficulties and expectations that cause you to stagnate in your learning, but in the ever-shifting landscape of the software development field, this stagnation can leave you behind very quickly. So having your own personal project to experiment with things in will keep your skills sharp and keep you constantly learning and developing solutions to problems that can later be implemented in a work environment.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Throughout the last couple of weeks, we have been working with MongoDB in our exploration of web application development. After hours of scrolling through MongoDB documentation to figure out how to do assignments and learning about how to use this particular service, I thought it would be important to learn a little bit more about NoSQL databases and why they are being used more and more frequently in software development circles. To this end, I found an article by MongoDB about NoSQL databases and thought it would be the perfect introduction to the topic.

The article starts with a basic explanation of the differences between relational databases and NoSQL, that it stores information in a non-relational format, thus providing more flexibility with schemas, faster query times, ease of use, and horizontal scaling that is not present in traditional database design. It then goes into the different types of NoSQL databases, those being document, key-value, wide column, and graph databases, giving brief explanations of those. MongoDB is a document database, holding all information in a JSON format. The article goes deeper into the differences between NoSQL and relational databases, showing an example of the two. In general, the main reason to use NoSQL databases, in my opinion, is the flexibility they have. There is no need to split up data that has no reason to be split up. All data for a single object can be stored within that object, without having to relate it to a completely different table. It takes out a lot of unnecessary complexity within the schema and to that end can speed up the time it takes to access data. The article then clears up misconceptions about NoSQL databases and provides a tutorial example on how they can be used.

After reading about the differences, and having worked with both SQL databases and MongoDB, I much prefer the flexibility of NoSQL database design over that of SQL, and the performance increase is an added bonus as well. I don’t know why anyone would stick with a slower, more rigid database structure unless their application absolutely needed it. Not to mention the fact that SQL has always had issues, and is far more vulnerable to security risks (thinking about SQL injection, which doesn’t seem like it would be as much of a problem here). This gave me a lot more appreciation for the usefulness of a NoSQL database design as a whole and aided in my understanding of what they are. In the future, unless I have to, I would much prefer to work with a NoSQL database over a relational one, and given the trends of web app development, I think a lot of others are thinking the same thing.

Source: https://www.mongodb.com/nosql-explained

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Over the past week, as we were talking about APIs and working on the backend to web applications, I was wondering about how the front end of these applications actually interacts with the backend software that we were working on. So I looked for something to help aid my understanding of frontend and backend interactions. In doing so, I found a post on vsupalov.com called How Does the Frontend Communicate with the Backend? that covers this area of web design.

While there is little discussion of APIs and their use in this process, I still think it is important to understand how the frontend and backend of a server interact in order to get a complete picture of how web applications work. The post starts off by explaining the basics of how the structure works and the definitions of terms, with the frontend being made of mostly HTML, CSS, and some JavaScript, and being run on the browser, which mostly interprets and renders data received from the backend. The backend receives HTTP requests from the frontend and compiles data to be sent and rendered in the frontend. The post then explains how these two components interact, through the packaging and sending of HTTP requests and responses. These generally are in JSON format, but could just be HTML, images, or any other files or codes. The final part of the post gives examples of how these systems work together to bring about the best possible user experience, by using the speed of the backend running on a host server to process how the user views a site, without having to use the much slower and choppier processing speed of the browser application. These examples include interacting with databases and how sites can render information server-side for SEO or performance reasons.

When I was working on websites, this kind of architecture would have saved me and the company a lot of time, I spent countless hours reducing the size of pictures to improve website performance, all of which could have been saved by using HTTP requests to dynamically load images when they were needed from a backend database. And the role of APIs in this process cannot be understated, facilitating this transfer of information between frontend and backend through properly formatted requests and responses. This gave me a much more clear understanding of how the interactions between the frontend and backend of web applications are processed, and why it is such an important part of proper web design. In the future, I feel that this information will help me have a better grasp of how these systems work, and how to properly utilize them to create better user experiences online.

Source: https://vsupalov.com/how-backend-and-frontend-communicate/

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

This week, as we have started covering REST APIs in class, I thought it would be good to learn a little more about them. While we haven’t finished going over it in class, there’s just something about REST that hasn’t clicked with me, so finding out a little more about what “REST” means, and how they are used would be useful to help me conceptualize the material. That being said, after looking through some blogs, I found a great post about REST APIs called “REST API: Key Concepts, Best Practices, and Benefits” off the AltexSoft blog.

This blog post establishes Representational State Transfer (REST) is an architectural style for APIs that standardizes interfaces between clients and servers in order to create, receive, update, or delete resources. These 4 actions are referred to by the acronym CRUD. The API acts as a handler for requests from client to server and replies from the server back to the client. These are the basic interactions that REST APIs are built to do. The article then talks about what makes an API “RESTful”, and how the principles of the REST architecture influence API design. These principles, called constraints within REST, are client and server autonomy, having a uniform interface and layered architecture, the use of caching, being stateless, and having the ability to run code on demand. Most importantly though, is flexibility by prioritizing business needs. This means that any of the other aspects of REST can be changed or ignored if they conflict with the needs of the API’s owner. The final part of the article covers some examples of REST API being used, with services such as Trello, and then compares REST to other API architecture like SOAP and GraphQL, which have some advantages over REST but are far more situation-dependant.

I think that most of the constraints that REST puts on API development seem extremely sensible. Especially the fact that they are there more as guidelines than as hard rules. Not every service is going to have the same needs, so the ability to use a framework that is flexible to those needs seems extremely useful. In the article, the author talks about how very few people actually apply all of these RESTful constraints, especially things like Code on Demand, as they have concerns about the security implications of doing things like this, which I also think is sensible. The uniform interface constraint seems extremely important to me as well, having an API that can run on any client platform or application, and will always have a standardized way of communicating with the server just seems like proper design. And the standardization seems to be one of the main selling points of REST. This definitely gave me a much better understanding of what REST APIs are, and why people would want to use them. It seems like an extremely flexible tool for API development and I will likely use it over other API architectures if I’m ever in that situation.

Source: https://www.altexsoft.com/blog/rest-api-design/

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

This week, as we have begun to use Docker and explore how to use it further, I thought it would be a good time to look further into what Docker is and why it is used professionally. In doing so, I found a relatively short blog post by Sudip Sengupta called Introduction To Docker: A Beginner’s Guide that I think does a pretty good job of explaining the positives of using Docker as a development tool.

The post begins by covering why a lot of companies are switching to a containerized framework for development. Mostly, they explain, it is due to the ease of use. It allows for reduced complexity and vulnerability, and generally makes the development process more resilient to the introduction of bugs that are introduced by developers using different dependencies, or using different versions of different software dependencies. If developers are using Docker, they have a consistent container that is completely independent of what they have installed on their own system. So there is no variation in how a build will go, and no bugs can be introduced in the build process, making both building and testing more stable. The post also contains a brief but helpful explanation of how Docker actually functions. A customized docker image can be used to tailor instances of the container to use what is needed for development, and allow for a more modular work environment, as everything needed is stored in the image.

I chose this post because it felt like a pretty good introduction to what Docker is, how it works, and why it is being used more and more in professional software development. From my own experience using Docker so far, it seems like an extremely useful tool. There is no longer a need to have Java installed on my system just for software development, I don’t have to worry as much about what versions I have installed, or have to worry about having multiple versions that can introduce issues into my development. There just seem to be so many perks to using containerization, especially as part of a development team. After the initial setup of getting Docker to work, all the dependencies of your code are just stored in an image that can be used by everyone on the dev team. There is no longer a need to worry about somebody having an out-of-date version of something that can break the code, or cause inconsistent testing results. I will definitely continue to use Docker in the future, it just seems like an invaluable tool for any kind of software development, either personal or professional. And the amount of development tools that are made for Docker or can interact with Docker makes it even more useful.

Source: https://www.bmc.com/blogs/docker-101-introduction/

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

This week, I wanted to learn more about the design patterns we discussed in class. After completing the homework, I saw how each of the design patterns we had used could be stacked on top of each other to make more efficient programs and find solutions to common programming problems. So naturally, I decided to seek out a comprehensive list of the Gang of Four design patterns to learn more about them. While looking into this, I found a blog post by Madhura Oak entitled Design Patterns – Revisiting Gang of Four that seemed to fit the bill.

In this post, Oak explains how the “Gang of Four” came up with a list of design patterns that solve common issues within programming, and laid out these patterns so they could be used in any language, and could help software designers write maintainable and easily readable code. In this, he explains the SOLID principles by Robert Martin, and uses these 5 design principles to help explain the usefulness of each pattern. The author also breaks down the 23 Gang of Four design patterns into categories depending on how they are used and gives examples of their use, which helps put into context why we would use these patterns in the first place.

After reading about all 23 of the design patterns, and having used both the singleton and factory patterns in the homework, I feel like I have a far deeper understanding of how these patterns can be used to create more efficient and readable code. They provide a framework for so many different types of abstraction, showing ways to structure your class hierarchies to improve your ability to modify, extend, and test code without having to slog through massive classes that are full of specific use-case scenarios. Using encapsulation and inheritance in the way they are used in these design patterns, code can become so much easier to document, test, and build upon. It becomes so much cleaner and more readable.

So far in class, we have only looked at what Oak classified as “creational” design patterns, as they mainly have to do with the creation and encapsulation of objects. However both “behavioral” and “structural” design patterns are also listed here, to help bring the same principles to the structure and behavior of the programs. Mixing these together within the full structure of a project would provide great benefit to the maintainability of code in the future, one of the most important parts of software design.

Overall, this blog post was a good introduction to design patterns and the principles that they help to achieve. In the future, I hope to use these patterns to help design code that is far more abstracted, and hopefully far easier to follow than code I’ve written in the past. I really like how easily followed the patterns are, and the way the post is organized makes it easy to find what you are looking for. If you are interested in further reading about more design patterns, I would highly recommend looking through this post, at least for a general outline of what they do and how they work.

Source:

https://madhuraoakblog.wordpress.com/2017/03/01/design-patterns-revisiting-gang-of-four/

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

This week, the topic that I wanted to focus on was design smells. I wasn’t confident in my own knowledge of what exactly design smells were or how to implement that knowledge into my designing of code. So I found a blog post by Sandor Dargo, in which he reviews the book Refactoring for Software Design Smells. Dargo’s blog has a background in software-design related book reviews, so it seemed like a good place to learn a little more about what design smells were.

The review covers a lot of the fundamentals of design smells, much like what we did in class, although it focuses more on what design smells affects within software design, such as understandability and reliability. I really liked this way of thinking about design smells, as simply learning them felt a lot more abstract to me, but showing what it affects and how it can harm the design of software makes it a little bit more understandable, to me at least. The first half of the post talks about the concept of technical debt, and the later half is more on the design smells. Obviously these both impact each other, but I liked his breakdown of technical debt as being similar to taking out a loan to get something done that needs to be done, but if you don’t keep up with that debt you will get further and further into debt until you fail. I think it is a very good analogy to technical debt, and aided in my understanding of the topic as a whole. The final part of the post focuses on common issues that are caused by design smells and how these seemingly insignificant things can make your code less and less usable over time.

I found this review to be extremely useful in my understanding of what design smells are and why code refactoring is so important. The most important aspect of this post to me was the discussion on technical debt. It is such an important aspect of software design to consider, as is allows us to make quick-and-dirty solutions when we need to, but also tells us how important it is to go back and change the code before it gets out of hand. We must design code in a way to make it as easy to use as possible, and easy to build on in the future. If we are able to properly document our code, allow for reusability within the system, and make use of abstraction and encapsulation to make code as simple to follow as possible, we can create an environment that can significantly increase not just our own workflow, but the workflow of any collaborators, or anyone who needs to make use of our code. It is our job as designers to make sure that as time goes on, our code gets easier to work with, especially as complexity increases to meet the demands of our clients.

Source:

https://www.sandordargo.com/blog/2021/01/30/refactoring-for-software-design-smells

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.