Docker is an open-source software that is used to deliver Linux and Windows images into virtual containers. According to this article, containers use shared operating systems, meaning that they are much more efficient than hypervisors in system resources terms. Instead of virtualizing hardware, containers rest on top of a single Linux instance. This means that 99.9 percent of useless VM junk is left behind, so we can have a small container containing necessary applications.

Specifically, container technology just abstracts the operating system kernel while the VMs hypervisor abstracts an entire device. Meaning that containers allow data center operators to cram much more workloads into less hardware. Furthermore, containers are portable, each instance is stored standalone in a port. It means that Docker allows you to run multiple copies of the same image in different local ports.

Another reason why Docker is so popular is its installation, downloading a whole application, for example, a database service, is usually frustrating since we have to follow strictly step by step, and if we mess up somewhere, the application will not function properly and we have to fix or reinstall the whole app. Docker is encapsulating the whole application into a container, to install a container to use locally, developers simply pull it from Docker Hub, which I will introduce below, with a command and run it.

Docker Hub is the largest library and community for container images, where users are able to find what image, container, command they need and share what they have to others. Just like GitHub, you will create an account and use it to fetch and push the source code or pull it from other people, but the repositories here are containers, image repositories. For instance, you need to set up the MySQL database for your application, instead of downloading and setting up the port for one database, you will look for it on Docker Hub and install it based on the repositories’ instructions and connect it to your computer port through a port. By the time this blog is posted, there are almost eight and a half million available images on Docker Hub for users to pull and work with.

In conclusion, Docker has revolutionized software development by making things possible. It gets more applications running on the same hardware; it is quick and simple to initiate an instance, therefore it makes managing and deploying applications much easier.

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

So I know I’m quite late to the topic, but way back in week 1 or 2 we went over the POGIL roles, responsibilities and basic structure. This for me has always been about learning to work in a team, regardless of the assigned jobs on the card – and I have to admit I’ve always had a hands off approach. I wouldn’t say I’m a bad team member, just an absent one. I wasn’t always engaged, and just wanted to meet some arbitrary requisite for a good enough grade. I’ve obviously adapted as projects and activities got harder, but this podcast episode seems to have broken me out of that passive mindset into something much more productive.

There is a bit of a disconnect here from myself to the podcasters, as they are experienced developers with years of managing experience, but nonetheless I think it helped me glance into a world that I knew absolutely nothing about. Kind of like a peek behind the curtain of what I should be expecting. My greatest takeaway is always defer to someone who has even a tad more expertise with a certain context. There’s simply too much to keep up with, and in order to do your job effectively, one must make a choice to lean into a specific type of architecture. Just be good at what you’re supposed to be good is my takeaway, I guess. Other peoples’ expertise will help whatever the team is working on, and your personal experience will almost always prove to be invaluable at some point in the project.

In addition, I think I’ve picked up a habit of deferring to other peoples’ techniques when solving a problem. I of course will point out if I think I see an error or bug, but it gives me a sense of wonder seeing how many different solutions people can come up with to a singular problem. There is so much ingenuity inherent to coders that it’s never a good idea to say “this is the way things should be done.” My father is an architect who advises some up and comers, and when I ask him, he is regularly annoyed with staff for not doing things “the right way.” I love the guy, don’t get me wrong, but after listening to the episode I have to say that this technique is too suffocating. Just like in architecture, writing code is an expression of will or intent through creation. To limit that in either capacity is unhealthy for the people who would pour their heart into the work.

I suppose that’s a bit philosophical, but nonetheless it’s a lesson I’m glad that I’ve been exposed to. Other nuggets in the episode are tips on efficiency and cohesion, but these two concepts are what really stuck with me.

Link to Episode – https://content.blubrry.com/completedeveloperpodcast/CDP-Episode0319_Your_Code_Sucks.mp3

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I have decided to go over into more detail on docker since we have been setting up and working on docker for the last few weeks and I wanted to learn more about it. The source I have chosen seems to have a good amount of information about Docker that I can utilize the source is reputable. Here I have learned more on the general landscape of what docker is and its place in the digital world.

In this article that I have chosen, IBM goes over Docker with how Docker is an open source containerization platform that enables users to package and run code much more efficiently than other platforms. It is widely popular at over 11 million different developers using docker and you can find it mentioned anywhere container is mentioned on the internet. Docker while wasn’t the first to utilize container technologies, it did it in a revolutionary way in which it made the process us creating and utilizing these containers simpler, less resource intensive and more flexible allowing the developer to to more easily run their applications. Docker also provides portability where you are able to take packaged software and run it on other platforms and systems. There also isn’t the need for individual OS’s and other resources for each application that you want to run but instead they can all run on the same OS. The benefits are numerous and this has allowed Docker to explode in popularity over the years since 2013 and looks to keep on rising. The article also goes over some Docker terms and tools although there was a Kubernetes section which is now outdated since Kubernetes deprecated Docker.

This source had brought insight in what place docker had in the world and how it would affect me later on. I can see from the website that Docker seems to be continuously growing and will be a part of our coding lives for an extended period of time. The benefits are quite astounding considering it is also free to use in which any extra information on Docker will help down the line when we work on it more. It also makes me wonder on if Docker will stay on top forever. The growth has been continuous but it won’t stay like that maybe in a decade since we are always innovating further. There was that point where Kubernetes is mentioned to help with larger complex container environments in which Docker could potentially adapt in the future to help with these environments or perhaps might become outdated in the future. There is always the chance for competition to rise to go against Docker, perhaps by a bigger company like google.

Source: https://www.ibm.com/cloud/learn/docker#toc-how-contai-5UTUfWRp

From the blog CS@Worcester – kbcoding by kennybui986 and used with permission of the author. All other rights reserved by the author.

Whenever I played video games in the past, I would always be aware of a weird looking number, often resembling something along the lines of “1.2.3”. Even back then, I was aware that this number meant that I was using a certain version of a software; however, the idea of a value having multiple decimal points was perplexing to me. Upon doing some research, and performing a closer, more careful analysis behind the meaning of the number, I now understand why: this value is part of a system known as “SemVer” (Semantic Version).

SemVer is a special kind of number used to provide programmers and clients an awareness of a certain version of software. Basically, it is broken down into three different parts: MAJOR.MINOR.PATCH. A “MAJOR” number is incremented when code is added to a project that is not backwards compatible with previous versions. This kind of update will force users of the software to adapt in some way to the new changes.

On the other hand, a “MINOR” number is incremented upon creating (as the name implies) rather minor changes that do not result in breaking the program. All changes that result in a MINOR increment can work with previous versions of the software. Finally, the “PATCH” number receives an increment when very minor changes are made to a program. These changes often involve fixing bugs or other errors found within the MAJOR and MINOR releases.

Linked below is a YouTube video describing SemVer in detail, and it was made by a user known as “Inedo”; I chose this video simply because of the fact that it allows me to indulge in my favorite social media (YouTube) while also learning about SemVer. I guess I also chose this video in particular due to the fact that it is mainly audio; this is an easier video to play in the background as a “radio” during work than a normal video (which requires sitting down and paying attention).

Going forward, I plan on using my knowledge of SemVer for two purposes. First, when enjoying video games, I can now have a greater understanding of just how complete the product is (compared to when I was a kid). SemVer allows me to know just how much time and effort companies put into their software; while a higher SemVer number isn’t necessarily a hint of a better product, it does show that more time was dedicated to perfecting the craft. Second, I can use SemVer in my own coding adventures. Instead of making one program and being done with it, I can now create different versions of the product (for example, version 1.0.0). This knowledge will be especially useful when combined with collaborative software tools such as git and Scrum.

Note: The numbers in the title are NOT random. See if you can figure out what it means!

Link: https://www.youtube.com/watch?v=Si3eWq1yHXs

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.

For this week’s blog post, I’ve decided to continue watching the video I started in my professional development post #4, “Object Oriented Design Tutorial: Creating a UML Design from Scratch” and start the next video in this series titled, “Object Oriented Design Tutorial 2: How to Turn a UML Design into Code” by Derek Banas. The reason I picked this video is because 1. it directly relates to one of our course topics, “Modeling: Unified Modeling Language (UML)” and 2. because it teaches a methodical process to creating UML diagrams and the code that goes with it. Since I will likely be making more UML diagrams in my educational/professional life, I want to further develop these skills. In my last post, I learned how to use a Use Case Description to create an Object Model and a Sequence Diagram. In this post, I will start by discussing how an Object Model and the Sequence Diagram is used to create a Class Diagram. I will then move on to discussing how these models and diagrams can be used to create Java code.

When Derek is creating his Class Diagram, he uses his Object Model to create the class name and the data fields of his classes. Derek then uses his sequence diagram to bring in the methods for each of the classes he creates. One thing that I thought was interesting as he brought in the methods for his Class Diagram was that he added an additional method that he did not include in his logic when creating his sequence diagram. He added a getCoinOption method and stated that he may not end up needing this method but will include it just in case he missed something with his logic. It is nice to know that using his approach allows me to make these kinds of edits on the fly.

In Derek’s next video, he uses his class diagram to lay out the data fields and methods in his IDE. Once he has outlined his program, he uses the sequence diagram to write his code. Derek starts with the coin class. In this class he mentions how he starts with what makes the most sense to him to get his code to work. He mentions once his code works, he can come back and worry about optimization. He uses an array that contains heads or tails for the coin value and Math.random to return the value of the coin flip. Observing this process was beneficial because it showed me how important it is to think of the data structures I will be working with and the operations that I want to perform.

Overall, I’m very happy with this series. One of the things I enjoy the most is that Derek is doing all this from scratch so we get to see any obstacles that come up along the way. I’m looking forward to seeing his working program at the end.

Tutorial links:

1. https://www.youtube.com/watch?v=fJW65Wo7IHI&list=PLGLfVvz_LVvS5P7khyR4xDp7T9lCk9PgE&index=3
2. https://www.youtube.com/watch?v=1BVXQ64wI00&list=PLGLfVvz_LVvS5P7khyR4xDp7T9lCk9PgE&index=2

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://jserd.springeropen.com/articles/10.1186/s40411-017-0041-1

A code smell is used to see or detect issues in code. There are many tools used by different developers in order to make the detection of code smells easier and faster. Aswell as being used to detect more general issues in code developers can also use code smells to help them know when refactoring of code would be beneficial. Code smells most frequently represent issues with maintainability (future or present) or comprehensibility if a developer refactors their code these issues will either take a much smaller form or they can be non-existent.

This article focuses on three of the many code smells and what each of them mean. One code smell outlined in this article is the “God class” code smell, this code smell tells the developer that class contains too much code/information or that the methods inside of the class are used to do too much. Which as the article says violates the “single responsibility principle”. The “God Method” code smell is described as when a method is assigned too much functionality which makes it hard to maintain. This code smell also “tends to centralize the functionality of a subsystem” according to the article. Lastly “Feature Envy is a code smell which shows that a method is more influenced or interested in a class other than its own.

The three code smells outlined in the article are some of the most frequently detected and can be detected without using a specific code smell detection tool. Some well known detection tools listed by the author are “inFusion, JDeodorant, PMD and JSpIRIT” all four of these tools are free or can be used on a trial. All four tools can be used to analyze Java and are known to at least detect the three code smells from the article. But other tools can be used or be more effective depending on the language you use to code or the code smell present in the code.

I chose this source (article) as it is easy to follow but also relatively in depth about the general definition of code smells as well as giving a list of tools used for code smell detection which other students as well as myself could find helpful in future classes or the professional world. This article showed me what tools I should be using to detect code smells in my own code and the reason as to why code smells are important to address/fix by way of refactoring and I plan on using this article or reflecting back to it when I need to find a tool for detecting code smells in the future.

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.

“Find what changes and encapsulate it.”-  This is a different approach from the redesign approach. In simpler words, we are able to consider what we want to change without redesigning, rather than thinking about who might force a change in design.

This principle of encapsulating makes it possible for nothing to affect the rest of your code.

Encapsulation can be found everywhere!

When we turn the steering wheel and the car wheels rotate, we see that there is a variety of moving parts that work together to transform our action into the final effect that the car wheels have, but all these details are encapsulated by us. But this example can never be confused with abstraction. Because they are simply similar and can be true. Just like in the real world but also in the world of Software we have various examples of encapsulation but also of Abstraction that interact together. These are two concepts that are different but that are also related to each other, and that in most cases work together.

The moment we include anything that has the potential for change, we are dealing with time savings. In general, encapsulation has to do with objects which in a way make possible the merging of attributes but also of the methods they have, for the sole reason that they do not have an impact on other objects they have. But it works differently in cases when we are dealing with the design of a program which is mostly object-oriented. This is because the requirements that may most likely change in the future, need to be more concise for one reason only: that the change is likely to occur at the time it is requested. The volume of the code is changed by the summary which minimizes the volume of the code, and which may need to be changed in the future.

When we see that this principle is particularly relevant to the code which changes very often, we are dealing with the benefit of encapsulating the code, regardless of the frequency of the code change. Like what:

The code that is encapsulated has the possibility of reasoning to be separate from the code

• To prevent conjugation summarized with the implementation of the code which is encapsulated, such as when summarizing when the interaction of a downstream system. At this point this replacement is even easier.
• -Other developers can understand from the encapsulation constants, that they are sufficiently connected and have control security in case they have changed or even the way it has changed.

References:

https://genderi.org/encapsulate-what-varies.html

https://alexkondov.com/encapsulate-what-varies/

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

Command-Line is essential to developers and I think every developer should master this skill. In my point of view, the command line is quicker than a regular click which saves developers much time along with effort, and the command line is one of the best tools at our disposal. Recently, I have had more opportunities to practice command-line while learning about Docker. It comes to my sense that using CLI fastens the Docker process than the original clicking method.
Knowing CLI gives you better accessibility to control the system. You can only access these kinds of commands via the shell on Unix/Linux and Power-shell on Windows. The basic commands only involve changing the directory, creating new files, and editing text files. The more advanced techniques could involve managing database systems like Apache/SQL. And elite users could use the command-line to do test penetrating to expose security vulnerabilities.
Developers spend an amount of time in Command Line Interface to execute codes or to run packages. Two essential programs are git and brew was designed exclusively for CLI though there is a way to use it without CLI interference, this is still much quicker and easier to use and work with the code base in it. CLI also allows us to do manipulations with your system internals. It offers better flexibility and control than regular GUI.
Front-end and back-end developers are better off with CLI. Since back-end developers will be dealing with servers, configuration files, and making sure the code for your site is working. Front-end developers don’t need as many CLI skill sets as back-end but knowing CLI serves them .better in the long run. After all, both developers use git and git functional based on CLI.
Talking about the bad stuff, CLI in Linux is popular among penetrating testers, meanwhile, hackers love CLI because of its flexibility. Using CLI to run Nmap to expose vulnerability is a powerful tool. It allows us to scan the network and discover not only everything that is connected to it but also much sensitive information. Besides Nmap is Metasploit, another powerful tool for penetrating testing. The problem with Metasploit is it makes hacking simple than it used to be. Nmap and Metasploit are two powerful for testers and developers and to people who use Linux, these are essentials, not necessarily for regular Linux users.
To summarize, the main advantage of using CLI is if you know the commands, CLI could be faster and efficient than other operations. It can handle repetitive tasks easily and CLI requires less memory than other interfaces.

From the blog CS@Worcester – Nin by hpnguyen27 and used with permission of the author. All other rights reserved by the author.