Following the Docker activities in class, I found docker-compose quite confusing. I decided to use that as an opportunity to look for some other resources that explains the concept briefly but detailed so I can understand the term well. I finally settled on this blog that gives a tutorial on docker-compose. I like the fact that all concepts have been covered and explained simply. I also see some terms that in found confusing during class activities defined and explained. I like how it starts by giving a walkthrough of docker in general and then introduces docker-compose so the connection is clear and as a reader, you would not get lost.

This blog talks about the fundamentals of docker. It explains docker-compose as a docker tool used to define and run multi container applications. It talks about the features of docker-compose, structure of a docker-compose file and explains some of necessary keywords found in the structure. It gives images of structure of docker-compose file and images on docker-compose and docker to differentiate them. Blog also explains some docker-compose commands.

I learned in this blog that you can start using docker-compose with docker files by defining your apps environment using a docker file, defining the services for your app so that they can run in an isolated environment and start the app by running docker-compose. Docker-compose can be added to a pre-existing project and to your workspace if you add a docker file.

Docker-compose files can work by applying multiple commands that are declared within a single .yml configuration file. The compose file consists of keywords that make up the structure such as services, ports, volumes, build, etc. In class, these keywords were not clear to me. However, in this blog I learned that version denotes the version of the Docker-compose which is usually the latest version. All containers created are defined in services and docker composes will create containers based on the name we provide under this section. Build specifies the location of the docker file and ports map the container’s port to the host machine. The image keyword allows to run a service using a pre-build image by specifying the image location. Understanding of these concepts really helped me in the recent homework assignment.

I also learned that the purpose of the build in docker-compose build is to get images ready to create containers but this will be skipped if a service is using a pre-built images. I always thought that docker compose up builds images and run containers but little did I know that it also forks containers directly if images are already built.

I hope others find this blog helpful especially those that are new or beginners to the term, as it will give an insight of the term and that will help guide you through working with docker.

https://www.educative.io/blog/docker-compose-tutorial

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

As I was preparing for my exams, I came across the term/topic technical debt as one of the topics under the review topics and this term was seen in one of the class activities. I decided to research on the topic, write a blog post to broaden my understanding for the exams. I came across this blog post that talks about technical debt and chose this blog because the concept has been broken down into topics explaining the term in-depth.

The term technical debt has been described in this blog as well as the good and bad reasons for technical debt. It also explains and gives examples on the various types of technical debt such as Planned Technical debt, unintentional technical debt, unavoidable technical debt, software entropy. It also explains some identifications of technical debt in a project and various ways on how technical debt can be avoided and managed. A youtube video is provided explaining the term as well.

In this blog I learned that although the term may sound like a financial term, it is defined as the deviation of an application from any nonfunctional requirements. Simply, it is a code you have to work on tomorrow because you took a shortcut to deliver it/software today. Technical debt just like in financial terms can have interests which is the difficulty to implement changes and thus needs to be addressed in order to prevent software entropy and risks that may relate to the source code. Teams may delay better coding and certain pieces which are understood by them to impede future development, however, interests may cumulate if these pieces, mediocre codes and known bugs that were left are not resolved.

Technical debts can be identified when code smells are too subtle than logic errors and when there are higher levels of complexities with technologies overlapping each other. Other warnings signs include product bugs that will cause an entire system crash and issues with coding styles.

I learned in Planned technical debt that organizations make an informed decision to generate technical debt knowing and understanding the risks and cost while Unintentional technical debt occurs as a result of poor practices, inexperience with new coding techniques and rollout issues. Unavoidable technical debt is created due to changes in the business and technology that present better solutions hence, making old code obsolete.

One way of managing technical debt is to assess debts and to acknowledge that technical debts exists and share discovery with stakeholders, explaining the importance of paying off technical debt earlier. Technical debt can also be managed by using Agile methodologies that can ensure that teams are working on technical debt.

I hope others find this blog educative as well.

https://www.bmc.com/blogs/technical-debt-explained-the-complete-guide-to-understanding-and-dealing-with-technical-debt/

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

We have been working on Docker doing some activities in class for some time now so I decided to look for more resources on that talks more about Docker. I finally settled on this blog that gives tutorials on Docker. I chose this blog because it talks about some topics and defines some terms relevant to know when working with Docker. Links to some concepts and to some Docker commands are provided to explore the concept further.

In this blog, Docker has been defined with some examples, and reason for its popularity. It also talks about the difference between virtualization and containerization. Advantages and disadvantages of each of these concepts have been provided. A youtube tutorial is also provided to explain the concept further. It also talks about the benefits of using Docker and explains some other concepts such as Dockerfile, Image, Container, DockerHub, Architecture and Docker Compose. Some diagrams have been provided to help visualize some of the concepts being talk about. As I was reading through, I came across a link to a page that talks about Docker and Containers, explaining with examples and I found that very helpful.

I learned in this blog that Docker is a containerization platform that packages application and all of its dependencies together in the form of a docker container to ensure that application works well in all environment. A docker container is a standardized unit that can be created on the fly to deploy a particular application or environment. Docker have functionalities that are useful to both developers and system administrators.

Virtual machines and docker container are similar in the sense that they both allow running of multiple operating system inside a host machine.  However, Docker unlike Virtual Machine, allocates exactly the amount of memory required by a container which helps to create additional containers from any leftovers of allocated memory which by so doing, increase productivity. Docker saves a lot of time to start since the container runs on host operating system unlike Virtual Machine which runs on guest operating system, so it takes a lot of time to boot up.  Docker containers are also lightweight and faster because containers created are run from the host operating system.

In addition, I learned that multiple containers in docker can be run as a single server by using Docker compose. Also, Docker engine is an application installed in the host system that uses a server, a command line interface and a REST API. Images are built and containers are run by passing commands from the command line interface and the server. Docker images are also the building blocks of a Docker container and these images are stored in Docker Registry.

https://www.edureka.co/blog/docker-tutorial

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

As I was reading some articles, websites for my previous assignments, I came across the term refactoring a lot. However, that was not the only time seeing that as it is part of the course syllabus. I decided to learn more about refactoring and write something on it for my weekly blog post. After going through some resources, articles I finally settled on this blog post that talks about refactoring. The structure of this blog is made simple, easy to learn and understand especially for beginners and those new to the term. It also provides links to some terms, books and some other IDEs mentioned.

This blog defines refactoring as the process that involves editing and cleaning up previously written software codes without changing the function of the code at all. Blog talks about the importance of refactoring, reasons for refactoring and how to perform refactoring. It also provides some techniques on how to perform refactoring. Each technique is well explained and broken down into subtopics and/or steps with some diagrams provided. Also, blog talks about when refactoring is not needed, best practices for refactoring and general summary refactoring.

In this blog I learned that the basic purpose of refactoring is to make codes efficient and maintainable, reduce technical cost, improves readability, and help prevent future bugs. A term that I found interesting as I was reading about the importance of code refactoring is code rot. Further research from Wikipedia explained it as a software decay that is a slow deterioration of software quality over time leading to software becoming unusable or in need of upgrade. Refactoring is important as it help to avoid this code rot.

I also learn that the best time to refactor is before any update or additions to an existing code. This is so as it improves the quality of code and should be done in small steps as possible. Other practices include planning refactoring project and timeline carefully, testing frequently and involving Quality Assurance teams and striving to focus on progress.

I thought that refactoring is always needed especially dealing with very high coded software programs and systems, but I learned from this blog that refactoring is not needed when an application needs to be completely improved.

Some techniques of refactoring I learned are Red-Green Refactor, Refactoring by Abstraction, Composing and Simplifying methods. Before applying the Red-Green Refactor technique, there should first be consideration of what needs to be developed. These developments need to pass basic testing before improvements can be implemented. Refactoring by abstraction is used when there is a large amount of refactoring to be done. I learned that extraction, one of the processes in Composing method, involves breaking down of codes into smaller pieces to find and extract fragmentation. This code is then removed to a separate method and replaced by a call to a new method. This process also involves classes, interface and local variables.

I hope others find this blog useful as well.

https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/

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

Since we have been using and seeing a lot of UML diagrams in class and in previous assignments, I decided to look for some resources on UML diagrams to broaden my knowledge and understanding. I finally settled on this resource because it gives simplified tutorials on UML diagrams making it easy to understand especially for beginners. Each part is broken down into various topics and subtopics. Page gives useful resources on UML as well.

This resource gives a clear and simplified definition of UML diagram. It has various topics that explains the roles of UML diagrams and goals of UML in Object Oriented Design. It explains the building blocks of UML diagrams which are Things, Relationship and Diagrams. It gives detailed explanations about nine kinds of UML diagrams or format uml diagrams, the three types of UML modeling and UML notations. It also gives sample examples of UML diagrams when explaining some concepts which makes it easy to understand when reading. Page also talks about the 2 broad categories-Structured and Behavioral with each divided into subcategories

In this tutorial, I learned that UML diagram is not a programming language and relates to Object Oriented Design. Initially I thought it was only a pictorial language to build software system, but this page makes it clear that it uses non-software systems as well. UML diagrams are also made for different users, not just developers to understand a software and non-software system. I must say that through UML diagrams in class, I was able to really understand the way a program is structured as well as relationships between the classes, interfaces etc. even before looking at the codes.

In the architecture part of the tutorial, I learned about the roles that UML diagrams plays in different perspectives of a system. These are the design, implementation, process, and deployment. Looking at these perspectives, all the diagrams that I have seen support this. These diagrams make clear of classes, interfaces etc., assembled in a physical state giving an idea about the flow a system/program has. Another important thing that I learned is that UML diagrams helps support the representation of physical nodes of a system that forms the hardware.

I learned that UML notations are very important to make a model that is very meaningful and is something that should be emphasized from the beginning. Some of these notations are Class, Object, Interface, Collaborations, Actor Notations, among others. I learned that the only difference between the Class and Object notations is that name is underlined in Object notations but has same structure and components as the Class Notation. I got confused when I saw a diagram of Active Class Notation as it looked similar to Class notation but I learned that the differences is that Active Class has solid borders and are used to describe concurrent behavior of a system.

I hope others find this source useful

https://www.tutorialspoint.com/uml/uml_standard_diagrams.htm

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

After the class activity on smells, I was interested in knowing more about it and how it relates to programming. The term was quite interesting, so I chose this topic because I wanted to know more. After several searches, I finally settled on this blog that talks about code smells and makes it easy to understand.

In this blog, I like the fact that it relates code smells to the everyday smell that we know, typically body odor. Initially I was thinking of code smell as a bug but this blog made it clear that it isn’t a bug. Blog talks about the downside of having code smells which are causing technical debt and affecting the maintainability of software system. It also gives some links to some series that explains more about code smells, giving examples, code snippets and how to identify and solve smells in a code. It talks about various code smells which are Method-level, Class-level and General-level code smells. Each type of code smells mentioned explains and give an overview/points on what to look out for in codes/programs to identify a specific kind of code smell. This blog also talks about some stereotypes of code smells that I found interesting and relevant.  

In this blog, I learned that code smell is a piece of code that we perceive as incorrect but do not fix right away. That being said, code smells in software programs will produce output but may affect the quality of the program if not taken care of.

In method-level code smell, I learned that there are certain things that one must check in methods to identify smells. These include the method not being used, taking too many parameters, doing too many or little things, having too many branches or loops. I always thought that methods can have as much parameters as it can but little did I know that too many parameters in a method could affect a software system and needs to be corrected. In the future I will not include methods that I do not use in my program.

I learned in Class-level code smells that the name of a class and programming interface should reflect its purpose. Also, when a class does too much or too little work, class unnecessarily exposes its internal details, inherits a base class but only some of its inherited behavior is needed, design of a class is overly complex are indications of code smells.

As I was reading through the series in this blog, I found very educative term which is factory method. I learned that factory method is a method, typically static, that returns an instance of a class and uses a constructor publicly or private. When too much work is required to get new instances when using constructors, it is always encouraged to resort to factory methods, although there are other cases where one could use factory methods.

I hope this blog is helpful to others as well.

https://blog.jetbrains.com/dotnet/2018/06/18/sharpen-sense-code-smell/

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

As a student learning new things every day, I chose this topic because I was curious as to what it really entails in computer science as it is one of the topics that directly relates to the course. However, little did I know that it was an abbreviation for 5 important design principles employed in software programming to make software designs more understandable, flexible, and maintainable.  I selected this blog because it explains briefly but detailed about each principle of SOLID and definitions.

This blog talks about who introduced the acronym SOLID and its importance. Also, what it stands for, which are Single-Responsibility, Open-Closed, Liskov Substitution, Interface-Segregation and Dependency-Inversion Principles. Not only does it explain each principle, but explanations are concise and easy to comprehend. It has some links that provides detailed explanations to some of the principles, giving examples that enables one to grasp the concept fully. It also explains why each concept can help developers to build better software and the importance of cohesion and less coupling in software development.

In this blog not only did I learn about the 5 principles, but also learned that it is a part of object-oriented programming that enables one to write a better code that is robust. I learned in Single-Responsibility Principle that classes should have a unique responsibility and that will help reduce complexities, reduce dependency on other classes, ensure readability all in while leading to a stronger cohesion. I believe that the quote “do one thing and do it well” has come into importance in this principle as that will help me avoid fusing too much responsibility on classes in my future programs to make editing of codes easy.

In Open-Closed Principle, I learned that any class written or coded can be used as it is written. It can be extended but can not be modified. However this principle made me understand more about inheritance and polymorphism in the sense that classes can be open if attributes can be added but closed if it is available for use/extended/implemented by other classes. I always used to be a victim of modifying parent classes if there are any errors in my sub classes which should not be the case. Also, this principle improves readability.

When looking at sample programs using interfaces, I never understood why interfaces could not be segregated into one, rather such programs could have more than one interfaces. Also, one class could implement many interfaces. However, this blog made me understand why this is the case in Interface-Segregation Principle that an interface can be broken down into smaller interfaces that are specific rather than making it large. In addition, classes do not need to implement interfaces they do not use.

I will encourage other students to read this blog as it helps understand more concepts in Object-Oriented Programming to make them better programmers.

https://apiumhub.com/tech-blog-barcelona/solid-principles/

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

In my first programming course, I asked my professor how important it is that I learn Object Oriented Programming (OOP). He replied by saying, if I want to program anything, I must learn OOP. Being a freshman then, I took that lightly until I started coding and did not understand what I was doing. It was then that I realized how important it is to learn about OOP and utilize the concept in my program. As students especially beginners in programming, we are so geared towards completing programming assignments, projects etc that we fail to really understand what is used to structure a software program which OOP is basically about.

I selected this specific blog post because it talks about OOP and what it entails. The blog explains OOP as a programming paradigm that relies on the concept of classes and objects. It provides the importance and reason for OOP. It also explains classes, objects, methods, attributes and provided some examples, code snippets and OOP structure. I believe that this is important to know especially for new programmers, to better understand, and help structure their programs as well as others. The blog also explains the principles of OOP which is inheritance, polymorphism, abstraction and encapsulation. It provides code snippets of how each of these principles are seen and employed in codes and programs. It also provides a table that summarizes each concept.

In this blog I learned more on inheritance that it supports reusability. I learned from previous programming class that subclass can inherit all attributes of its parents class and add more attributes but little did I know that subclasses do not have to redefine methods that are already defined in parent class. When a method is called, it goes up to the child parent classes to find where that method was defined. It used to be a common mistake in my programs as I would redefine methods from parent class in subclasses and I never clearly understood why I got errors.

Also, I learned on encapsulation that, it hides the internal software code implementation inside a class, and hides internal data of inside objects. After reading this, I am sure to employ this method to hide information that I would not want to change in my program or code. In the past, I wasn’t able to understand the difference between protected and public codes when I see them, other resources made it very ambiguous for me to understand. However, thus blog provided a simple, easy to understand difference between them. Public codes are those that can be accessed by other classes in the program and protected are those that can only be accessible to subclasses.

I hope beginner programmers will find this blog helpful. For continuous programmers, this blog will help broaden your understanding and knowledge of OOP like it did to me.

https://www.educative.io/blog/object-oriented-programming

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