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.

For the past few weeks in class, we have been working with something called Docker. I have been working on projects that used docker, and we recently did an activity on Docker commands. With all this work revolving around Docker, I wanted to familiarize myself with it further. I did some research on what Docker is, how it works, and why we use it. There are an abundance of sources and blogs that go in depth to how Docker works. That being said, this blog post will just relay most of that information, and you may find it useful if you have been confused about docker up until now.

Let’s first understand what Docker is. A very informative source that I found was an article by IBM that explains this topic very well. Docker is an open source platform that utilizes containerization to package applications, their dependencies and required operating systems into containers. This in turn allows software developers like us to write code and build applications no matter the environment. Though it took a bit to get set up, I found that it made the whole process of writing programs more convenient.

For our second homework assignment, to get the project running in Visual Studio Code, we needed to reopen the folder in a dev container. Docker revolves around the process of containerization, a variation of virtualization. When you hear the term virtualization, you may think of virtual machines, which is the process of emulating a physical machine, virtualizing the OS, underlying hardware, the application and their dependencies. Containers on the other hand virtualize the OS and only the application and their dependencies. As a result, containers offer more portability because “unlike a virtual machine, containers do not need to include a guest OS in every instance and can, instead, simply leverage the features and resources of the host OS” as stated in another article by IBM.

Now that we have a better understanding of how containers differ from virtual machines. I just wanted to conclude by listing the benefits of using Docker and containers. IBM mentions that containers are more lightweight. I have definitely noticed the difference in system usage between running a virtual machine and just running Docker. Another benefit I have seen is the increase in development efficiency, especially for the second homework assignment, where we were required to run the code against tests several times as we made changes. Overall, I found that writing this blog post helped me get a better understanding of what Docker is, how containers work and their benefits to the software development process. It allowed me to weigh the pros and cons of using virtual machines as opposed to containers. And now I can understand why we are using Docker.

Sources:

https://www.ibm.com/cloud/learn/docker

https://www.ibm.com/cloud/blog/containers-vs-vms

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

https://refactoring.guru/design-patterns/strategy

This article shows the “intent” of the strategy design pattern and how to successfully use it when refactoring code which is our current class topic. According to the article the strategy pattern (a behavioral design pattern in CS helps define a group of algorithms in separate classes which will effectively use each other’s objects.

One of the larger issues addressed by using the strategy pattern helps keep the main class from growing into a more complex mess. The strategy pattern allows for a developer to take/extract a class that has different functions and funnel them into a new class which is what this pattern refers to as a strategy.

Interfaces are commonly used with the strategy pattern in order to communicate with the other “strategies” that you previously extracted from the main class. The use of interfaces in the strategy pattern also allows your code to switch between algorithms at run time by using sub objects that perform their own tasks.

I chose this article as I feel it gives readers like myself a good general understanding of how to use and implement the strategy pattern. The article effectively shows you when you should or should not use the strategy pattern along with the pros and cons of using it. Similarities between the strategy pattern and other patterns it also outlined in the article which helps you tell the patterns apart and when you should use one pattern over another.

This article from refactoring guru has helped me to better understand the strategy pattern as a whole and helped me gain a somewhat smaller but still important understanding of some aspects of other design patterns (for example command and state). There are also examples of the strategy pattern being used in different coding languages found under the “Relations with Other Patterns” section.  I plan to use the information in this article to help me understand the Strategy pattern more in current and future assignments as well as in my professional career whenever I may need to refactor code through the different design patterns.

Overall I believe the general understanding of the strategy pattern gained from this article can help myself and any other student that may be having trouble with the topic or even someone who is just curious and would like to learn more about design patterns as their are articles on the other design patterns on the same website that can be accessed easily through links near the end of the page.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

            In my experience, the concept of virtualization is currently synonymous with the creation of virtual machines that are used to emulate hardware and operating systems that, for one reason or another, are not readily available during the process of software development. For example, during my studies I have needed to use programs that were not available on Windows operating systems or to study an operating system for which a physical unit may not be readily available. Whatever the case may be, virtualization is not a new concept, and it is widely utilized in software development. It is important to note that virtualization is not exclusive to virtual machines, as it has a broader range that includes any concept related to the abstraction of a system’s physical components into virtual components.

            Among others, one concept of virtualization is containerization, with which most of us are familiar through Docker. Conversely, containerization refers to the containment of applications, their dependencies, and their required operating system into a singular package, also called container (hence, the name) that can be deployed and used on any operating system. By design, containers are meant to be a portable and lightweight way of testing and deploying applications, at least when compared to virtual machines. However, it is important to note that singular instances of containers cannot be modified, whereas it is possible to customize and modify virtual machines. Despite the caveats or benefits of virtual machines and containers, both are equally important during development.

          As I mentioned before, I have used virtual machines during my studies to create and use servers that I had no immediate physical access to, so the concept of virtual machines is not entirely foreign to me. However, I have little experience by comparison when it comes to Docker and using containers for software development, so I believe it is important for me to understand their differences so that I can know how to properly utilize them. As I was researching more regarding the concepts of virtualization and containerization, I came across the post titled What’s the Diff: VMs vs Containers on BackBlaze.Com, in which Roderick Bauer defines what virtual machines and containers are in detail, how they are different based on their structure on a server, as well as listing their benefits and best uses. Though Bauer does not directly state their caveats, by looking at the differences of both virtualization and containerization I can better understand when either approach could be more suitable depending on the needs during development.

            Moreover, what this post also helped me understand better is that neither option is mutually exclusive; it is possible (and sometimes, even preferable) to utilize both virtualization and containerization during development, rather than being limited to either option, so long as doing so does contribute to improving development.

Direct link to the resource referenced in the post: https://www.backblaze.com/blog/vm-vs-containers/

Recommended materials/resources reviewed related to virtualization, virtual machines, and Docker/containerization:
1) https://www.oracle.com/cloud-native/container-registry/what-is-docker/
2) https://www.infoworld.com/article/3204171/what-is-docker-the-spark-for-the-container-revolution.html
3) https://www.docker.com/resources/what-container
4) https://devopscon.io/blog/docker/docker-vs-virtual-machine-where-are-the-differences/
5) https://www.airpair.com/docker/posts/8-proven-real-world-ways-to-use-docker
6) https://opensource.com/resources/virtualization
7) https://en.wikipedia.org/wiki/Virtualization (Definition of Virtualization)
8) https://www.ibm.com/cloud/learn/containerization

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

               When working with a Java program, one of the strongest tools to ensure it is functioning is Junit testing. Junit testing makes it easy to take a glance and see if all properties of your code are functioning correctly. Despite this however, at the end of the day, the product must be able to seamlessly accept and output data in a usable form. Therefore it is important to understand how to use temporary test files when using Junit.

              Andrew Binstock’s post fits in with regards to the currently assigned homework which sees us utilizing test classes and modifying them as the code is refactored. These tests allow us to ensure that the written code is working properly. To build upon this idea the post linked below presents the idea of Junit testing with temporary files to read and write to. Within this post is sample code which creates temporary files in and out of Junit testing.

Below we can see a snippet of code from the original blog post which shows temporary files being used in a Junit test. (Andrew Binstock)

import org.junit.jupiter.api.*;
import org.junit.jupiter.api.io.TempDir;

import java.io.*;
import java.nio.file.InvalidPathException;
import java.nio.file.Path;

import static org.junit.jupiter.api.Assertions.*;

public class TempFilesJUnit5Test {

Path path1, path2;
File file1, file2;

/* This directory and the files created in it will be deleted after
* tests are run, even in the event of failures or exceptions.
*/
@TempDir
Path tempDir;

/* executed before every test: create two temporary files */
@BeforeEach
public void setUp() {
try {
path1 = tempDir.resolve( “testfile1.txt” );
path2 = tempDir.resolve( “testfile2.txt” );
}
catch( InvalidPathException ipe ) {
System.err.println(
“error creating temporary test file in ” +
this.getClass().getSimpleName() );
}

file1 = path1.toFile();
file2 = path2.toFile();
}

               Within the second homework assignment we can see that Junit tests are used to ensure that the different classes of ducks and working properly and that the data output is correct. Some of the Junit tests scan the output file and compares it against the expected output. While this is useful to ensure the code works, it is also important to consider that not everyone will want their output confined to the terminal. This program could very easily be modified to output to a text file for data collection purposes. Testing this with Junit would allow the creator to ensure that data is being retained properly before running the program in a real case scenario.

Testing with temporary files was previously an underutilized method of testing due to older hardware being much slower and older drives using spinning magnetic disks rather than modern solid state storage. In the post we see the author discuss this dated policy and encourage the use of test files to create a more thorough testing method. Some might want their output in a text file or as an output to a front end for a website. Junit tests with temporary file allow you to test for this functionality as these temporary files can be created, read from, written to, and are all deleted at the end of testing to keep drive space free from clutter.

Bibliography:

Binstock, A. (n.d.). Working and unit testing with temporary files in Java. Blogs.oracle.com. Retrieved October 11, 2021, from https://blogs.oracle.com/javamagazine/post/working-and-unit-testing-with-temporary-files-in-java.

Working and unit testing with temporary files in Java (oracle.com)

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

For this week’s assignment, exercise #2, I had an opportunity to refactor a poor design of Duck Simulator using the factory pattern. It was nice that I could approach this design pattern step by step and learned its definition by understanding why I had to create an abstract method or why I had to create a factory class. Moreover, after skimming through a long chapter, Chapter 4. Baking with OO Goodness: The Factory Pattern, although there are many important definitions in this chapter, I believe that there are two concepts that I shouldn’t miss, the factory method and the abstract factory. Both are new tools that I need to know what they are and how to apply them to a design.

Furthermore, for better understanding, I also wondered what was the difference between factory method and abstract factory. Although, the textbook has a comparison between those two concepts, but for myself, it was long and difficult to follow till the end. So, I did a few searches to see if there were any good resources that I could take a quick look at for my question. I found a good blog, called Factory Method vs Abstract Factory. In this blog, the writer makes some comparisons to show the difference between factory method and abstract factory. Through the blog and the textbook, I know that both concepts are used to encapsulate object creation, and they apply the dependency inversion principle by allowing coders to decouple code from concrete classes . On the other hand, the two concepts differ in many ways. First, the number of products produced is different. The factory method is used to create only one product while the abstract factory is used to create families of related products. Second, for the factory method, the object creation is decided by subclasses (depending on inheritance), whereas the abstract factory has a separate class to creates a family of products, then its object can be passed to client class for using (object composition). Next, it is the level of abstraction. Since the abstract factory are at higher level in abstraction, we can use factory methods to create products in factories.

For myself, this is a resource worth referring to because its concise, well-organized content helps readers easily distinguish the difference between the two concepts. Thanks to this resource, I got a better understanding of the factory pattern, especially the abstract factory and factory method, which is really helpful for my diagram design latter.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

The year was 2005. I was a young child in elementary school, and eventually I was exposed to a little-known strategy game known as Warcraft III. As I championed the human race in my epic quest against the Undead Scourge of Lordaeron, I came across a sorceress ability known as “Polymorphism”. This powerful spell allowed its caster to turn an individual target into a harmless sheep. While entertaining and useful to say the least, little did I know that Polymorphism itself would take on a new form in the years to come…

Fast forward to 2021. I am being exposed once again to Polymorphism, this time as an essential feature of Object-Oriented programming. This would mark the third time that I am working with this concept (the other times being 2016-2017, and 2019 respectively). Polymorphism, in theory, isn’t very difficult: we take one idea (such as a function/method), and give it “many forms” (hence the name) among its various classes that use the function/method.

Listed below is an article about polymorphism from GeeksForGeeks, one of my “personal go-tos” when it comes to learning about programming practices. Specifically, “runtime polymorphism” will be more applicable in my software design class, due to its usage of method overriding. When using the “Strategy Design” of refactoring, we will create various interfaces and have them implemented using respective classes; these classes will then create their own version of the method.

Strategy design refactoring seems to provide an edge over “simple inheritance”, which would involve having a single base class (that all subclasses inherit off of). This “edge” is the removal of inherited methods that serve no purpose in certain subclasses; when the interface is implemented by the class, we can choose exactly what we want and don’t want from polymorphism.

However, having too many interfaces, or not enough data within the interface can cause its own problems. In addition, an interface is just that: a “top-down” view, with nothing beneath it; the methods need to be designed by the class using it. Meanwhile, inheritance may have redundant data, but at least you get all that and a bag of chips. In other words, inheritance provides one portion of functioning methods, plus whatever else is added on in the subclass.

I hope that I can use the idea of polymorphism, alongside interfaces, to reduce the amount of redundancy and complexity in my programs. There is no need to turn a program into a headache with unnecessary amounts of inheritance. In addition, part of this unnecessary material could be redundant – brought along for the ride, but not used during run-time.

Link: https://www.geeksforgeeks.org/polymorphism-in-java/

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.