Author Archives: kmaiser

DevOps With Docker

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.

Improve Your Code with Design Patterns

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.

Analyzing Code Smells

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.

The Usefulness of UML

This week, we have started talking about UML (or Unified Modeling Language) in class, and while I can see some of the usefulness of UML, I wanted to see how people actually use it in the context of a workplace environment. So as a part of this, I found a blog post by Lucidchart talking about different types of UML diagrams. While this blog post is made by a company, and they are trying to get the reader to use their product, I don’t think detracts from the usefulness of the post.

So in this blog post they talk about how Agile developers can incorporate UML into their development process, as well as 7 different types of UML diagrams and how each one is useful, and which context it is useful for. It is largely just an overview of these different models, and I know there are more types of UML diagrams, but this gives a fairly good breakdown of what UML is and how it can be used in a more real-world context. I chose this post as I personally found it useful in understanding why anyone would actually want to use UML outside of a planning stage, since you are essentially planning out the whole class structure before you design it, so in my mind why wouldn’t you just write the code? Well this post makes the case that UML makes very good documentation for your code. If you have a class diagram, like the kind we worked with in class, you can use that as a sort of blueprint for your code. So you don’t have to scroll through hundreds of lines of code just to find all of the methods that are in it and how they interact with other classes, you can just look at the UML diagram. They also make the case that UML can be a valuable tool in explaining code to others.

From this blog post, I think I have a better understanding of how UML is (and should be) used in a workplace. There are a lot of different types of diagrams that were shown that I didn’t know were part of the point of UML, as I have only ever seen the class diagrams. But there are many models that fit under the purview of UML, each with different use cases. Some model runtime behavior in a way that it could be easily explained to someone who has no knowledge of programming, and some are able to show how different methods or classes communicate with one another, creating a diagram that can be easily looked at to make sure you aren’t going to mess with interactions in a system by making certain changes. I think that, given the proper context, UML could make a much more significant impact in understanding how we code, and has the ability to explain code to others in a way that even more traditional documentation methods lack.


Source: https://www.lucidchart.com/blog/types-of-UML-diagrams

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.

Introductory Post for CS-343

Hello there. This is my introductory post for CS-343: Software Construction, Design and Architecture. My name is Kurt Maiser and I am a senior at Worcester State. Hope you all had a great summer (pandemic aside) and I am excited to get into some software design again. See you all in class.

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.

Introductory Blog Post

Hello! My name is Kurt Maiser and this is my first blog post for CS-443 (Software Quality Assurance and Testing) at Worcester State. I’m a Junior in the CS program here and made this blog for the class (at least initially). I am looking forward to the year and to writing some code! See you all in Zoom.

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.