What is DRY?

First of all, what does DRY stand for? It is a term “don’t repeat yourself”. In the software engineering world, this is a principle of reducing repetition in the code, referring to a single source-or “snippet” -of reusable code whenever you need it.

An example of this could be an app that your programed that throws a ball for your dog once an hour throughout the day. Instead of writing the entire code out for finding the ball, picking up the ball, and throwing the ball every hour, you can write the code once and give it a name such as toss.ball. This will then allow you to just type toss.ball each time to call it. This saves a lot of time writing the code.

Not only are we saving time when first writing out the code, but it also means that there will be less human error as well. From the example, if we were to write out the code entirely 24 times (1 for each hour), you would be bound to make some sort of error at least once. Another reason how this is also effective is that if you wanted to change the object being thrown for example a stick, all you would have to do is change the term ball once, instead of doing it 24 times.

In terms of real life, we can see this being used when we let websites save our information such as logins, password, or any other type of information we would have to type in each time. The same goes for music. If we are using sites such as Spotify, most of us create playlists so we don’t have to constantly look for the song we want to listen to.

I chose to write about this topic because it is part of our curriculum. We will be learning about this principle along with others as it is an important part of coding. I will post a link that will take you to a blog I read. https://zapier.com/blog/dont-repeat-yourself/ I really enjoyed going taking the time to go through this blog because it taught me and showed the importance of reducing time when it comes to coding. I also recommend this blog to anyone who plans to become a software engineer because it goes into depth about DRY and uses many examples to help you understand how it works. It amazes me how a simple principle could do so much such as saving time, less human errors, and overall having a simple code.

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

A look over Docker

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.

Docker Docs Tutorial Follow-up

Hi everyone, or one, however many, hope all is well. These last few weeks have been hard for all of us, and it is tuff to keep a captain’s log when the sea is turbulent and requires careful navigation. This is the reason I decided to try something new, something I suppose I should have been doing all along. Instead of studying the subject and writing the experience, I will try to combine writing, while, getting acquainted with the subject. Disclaimer, this is a test, it is a discussion from following the tutorial not instructions. Feel free to follow the tutorial –the link is at the end.

The beginning of this tutorial has us creating a folder in cmd and opening that folder, I tried to follow it to the letter.  Windows users tend to get lazy with all the easy click visual aids and underestimate the power of the shell (pun intended).  While playing through a python file, I decided to write the script on the shell and forgot to use “”.  Many lines later I realize the time I wasted with the useless typing effort. Echo “import time” > app.py was all that I needed, sometimes we go through the extra effort without realizing there is no extra reward. The focus of this tutorial is not the python script [ctrl c, ctrl v is my best friend/enemy].

The second part of the tutorial has us setting up a Dockerfile. I wasted some time trying to find the [.extension] for Dockerfile, which shows how sometimes is easy to go around chasing our tails in tutorials. The tutorial has a very good set of explanations on what every line is doing. I really like the RUN pip install -r requirements.txt, which saves space and compartmentalize things, all we must do is write the txt for the requirements in that one file and we never have to touch the Dockerfile for petty things such as these.

Step 3 has us creating a [.yml] file for the compose json like statements. As mentioned in the tutorial this compose file defines a [web] and [redis] services, I assume the version is not linked to anything or it is set at the developer’s discretion giving the condition of some actual project. The [web] service just points to the port that have been exposed from the Dockerfile, I suppose. The other service [redis] is an image to run parallel to the image already running from Dockerfile.

The final step was to just run [docker-compose up] and I must say there is nothing more pleasing than blue text and no errors at the end. It then asks you to use the keyword [volumes] in the [.yml] file to bind the current directory on the host to /code, I must say I got an error for missing a space on [-.:/code] instead of [- .:/code], see the difference.  We’ve done this in class, but any good guitar player could tell you –repetition is the name of the game.

https://docs.docker.com/compose/gettingstarted/

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

24.35.23

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.

Docker

In class, for our activities and homework, the professor told us to download Visual Studio Code and Docker that we were going to use for the semester. I did not know what Docker was and what its purpose was going to be in this class. I was interested in learning more about Docker and why it is such a professional tool in software development.

In software, Docker is an open platform for developing, shipping, and running applications. It enables us to separate our applications from our infrastructure so we can deliver the software quickly. It is a set of platforms as a service product that use OS-level virtualization to deliver software in packages called containers. Containers are isolated from one another and bundle their own software, libraries and configuration files; they can communicate with each other through well-designed.

In a way, Docker is a bit like a virtual machine. But unlike a virtual machine, rather than creating a whole virtual operating system, Docker allows applications to use the same Linux kernel as the system that they’re running on and only requires applications be shipped with things not already running on the host computer.

And importantly, Docker is open source. This means that anyone can contribute to Docker and extend it to meet their own needs if they need additional features that aren’t available out of the box.

I chose this article because I was curious about Docker and wanted to know more about it. So, from all the sources that I could have found, this one has all the details about docker, docker containers, how needed it is in software development, and why it is so desired in companies.

Now that we know what Docker is, let’s understand why it is used and needed for software. Docker streamlines the development lifecycle by allowing developers to work using local standardized environments, using local containers which provide our applications and services.

I think one of the reasons Docker is important, is that it can get more applications running on the same hardware than other technologies, and makes it easier to package and ship programs, which is a high potential. Companies use Docker a lot in software where they do a lot of programming and applications because it makes the work easier and more portable.

As a computer science major, what I understood about Docker even though I have never used it, it’s a great platform when it comes to running applications and can do many of them at the same time. I am still getting used to it with the activities that we do in class and love to see how it works and its roles.

Docker containers, images, and registries | Microsoft Docs

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

Looking at the Interpreter Pattern

“Interpreter Pattern – Spring Framework Guru”

The above article describes in detail how the Interpreter pattern from the gang of four book works. Before I continue, I should specify that the book, this post and the above article are focused on the Interpreter pattern primarily in terms of object oriented programming, which is not the only way that the general concept may be applied. There is the general idea, which is creating a small, limited language inside of a program, and then there is the gang of four specification, which includes more specific implementation details. For example, it mentions regular expressions, which do not necessarily have to be written in an object oriented way.

I sort of understood what the interpreter pattern was in a broad sense, but not in the specific technical sense one needs to actually make use of it. For example, I didn’t know that it employed the use of another pattern, called the Composite pattern. The Composite pattern is essentially the idea of treating individual objects and compositions of objects uniformly by representing them as a tree. The Interpreter pattern uses the Composite pattern in order to represent an expression to be interpreted. It does this by representing the components of the expression as atomic expressions arranged in a tree called an “abstract syntax tree,” and then expressing the language by recursively processing each node in it. The components of this expression may be either non-terminal or terminal, representing operations with and without operands, respectively (for example, a multiplication versus a constant). The pattern also specifies a “context,” which represents string data that is parsed, and a “client,” which actually parses the expression.

This pattern may be useful in a case where I want to create a smaller, more focused programming language inside of a project for use by less technically oriented people. Specific potential use cases like this include a language for writing plugins in an art program or a simplified language for directing game behavior inside of a game engine like GameMaker’s GML. Other, more common examples include SQL parsing and, as was mentioned previously, regular expressions.

At its core, the Interpreter pattern is essentially about converting instructions from one language to another, much like how a language interpreter interprets ideas from one language to another. “Interpreted” languages such as Python can be seen as an instance of this idea, using an interpreter to convert Python expressions into work by the computer. In the same way, you might also view a C compiler as an interpreter that converts C instructions to machine instructions.

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

Self-Directed Professional Development Post #6

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.

Interface vs Abstract class vs Concrete class

Summary:

As a programmer, java is all about classes and there are design patterns that we must follow, and it is our duty to question them. Java is an object orientated programming language where we have the ability to write our code in the form of reusable classes. Code re-usability doesn’t start by creating objects out of classes, it starts way before that when we are creating the classes itself. The class types that we have available to us are Interface, Abstract, and Concrete classes.

Reason:

The reason why I chose this article was because I thought this article would help us understand why we us certain classes and when to use them. In class we have gone over different design patterns where the uses of every class are different depending on what we want to achieve. I believe that it is important to fully understand how they each function as it will make understanding the design patterns much easier.

What I’ve Learned:

Interfaces are a blueprint for your class that can be used to implement a class and an interface cannot have any concrete methods. What your interface can have are static members and method signatures. All methods that you declare in an interface can have static, default or abstract modifiers. Abstract methods cannot have a body; all they can have is a method signature. Variables are not allowed in interface. Hence any data declaration is public static final. Interfaces can extend other interfaces (one or more) but not classes (abstract or not). Interfaces cannot be instantiated as they are not concrete classes. Methods and constants cannot be declared private, methods cannot be declared final.

Abstract classes are a bit different from interfaces. These are also used to create blueprints for concrete classes but abstract classes may have implemented methods. Abstract classes can implement one or more interfaces and can extend one abstract class at most. A class can be an abstract class without having any methods inside it. But if it has any methods inside it, it must have at least one abstract method. This rule does not apply to static methods. As abstract classes can have both abstract and non abstract methods. Static members are allowed. Abstract classes can extend other at most one abstract or concrete class and implement several interfaces. Any class that does not implement all the abstract methods of it’s super class has to be an abstract class itself.

Concrete classes are the usual stuff that every java programmer has come across for sure. It is like the final implementation of a blueprint in case you are extending it some abstract super class. A concrete class is complete in itself and can extend and can be extended by any class. The only condition is that all the methods have to be implemented in order for it to qualify as a concrete class.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Code Smells

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.

“Encapsulate what varies.”

“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.