Hello everyone and welcome to week 13 of the coding journey blog. In this week’s post I will be talking about a popular container that many software developers use called docker. Docker is very helpful in today’s world and helps manage as well as deliver software much more efficiently.

So what exactly is docker is a question that many people when they first hear the term. Well docker is basically an open platform that is used for developing, shipping and running applications. The reason why docker is so important and useful is because it allows you to separate your applications from your infrastructure, which results in quicker software release. Timing is everything in today’s world and so a tool like docker is needed for a faster approach in software. With docker, the infrastructure of the software can be managed the same way as applications and so this shortens the gap between producing and releasing code for production use. The tool docker has is it allows an application to be run in a separate environment known as a container. This isolation as well as heightened security allows users to run many containers on a certain host. Containers are efficient because they run directly through the host machine’s kernel and so you can run more with this process than a virtual machine. The process for docker first starts with you developing your code and other parts using the docker containers. Then docker becomes helpful in testing your code as well as sharing it through the container. Then when the code is all ready to go, you can deploy your application in the product environment, whether it is local or on a cloud service. Essentially, there are many reasons for using docker when developing code and working on an application. Docker allows applications for more faster and more consistent deployment of applications so it isn’t a hassle if there are any bug fixes that need to change down the line. Containers are known for continuous integration and continuous delivery in the workflow. Docker is also helpful in scaling applications because it allows for highly portable workloads, as it can be changed easily to fit any business needs.

I know for a fact that throughout my journey with developing and learning code, I will use docker to run and create apps. It makes the process a lot more smoother and efficient as this is what most developers are looking for because they don’t want extra hassles. Docker simplifies creating applications and my future projects will be much easier to manage through docker and its ability to use containers.

For more resources check out these links:

https://docs.docker.com/get-started/overview/

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Hello everyone and welcome to week 11 of the coding journey blog. In this week’s post I will be talking about the design pattern acronym GRASP. This acronym is short for general responsibility assignment software patterns. Design patterns are essential for software developers, and we will dive more deep into the benefits of using GRASP.

Originally, the GRASP design patterns were introduced after gang of four book, which has details on commonly used software design patterns. The GRASP design pattern is answering what each certain role each aspect plays in the software. There is the controller whose essential role is to take responsibility to encapsulate a system operation, which is something the user is trying to process such as purchasing an item. The system operation is achieved by calling one or more method calls between the software objects. Also the controller is responsible for providing a layer between the UI and the domain model. Then there is the creator which is responsible to help decide which class going to be responsible for creating a new instance of a class. There is a pattern known as high cohesion which is essentially responsible to keep objects understandable and more manageable. An example of this is breaking classes down and different subclasses for different roles making it easier in the bigger picture. Then there is the indirection principle which is responsible for low coupling and gives interaction responsibility to an intermediate object. Another part of GRASP is the information expert which gives guidelines about giving responsibilities to classes and one example would be methods.

Also in the GRASP design pattern there is the pattern of low coupling which decides how to assign responsibilities to lower dependency of classes and the change in classes impacting on another as well as the higher reuse potential. Polymorphism is a concept most of us know about because it is one of the principles of objected oriented programming. In brief to recap the concept, polymorphism provides guidelines on how to use the object oriented feature in your design. Then there is protected variation which protects elements from the variation on other elements by wrapping it with an interface and using polymorphism for many other implementations. The last part of the GRASP principles is pure fabrication which is made up to achieve low coupling and high cohesion with a class that does not represent a concept in the problem domain.

I personally think that the design concepts of GRASP have many essential components of programming and creating real world software. Many of these components are used in our everyday world and features we see without even recognizing. As I learn more in my coding journey and take in more concepts, I will most certainly take into account GRASP principles in my future projects to make it easier.

For more resources on this topic check out these links:

https://dzone.com/articles/solid-grasp-and-other-basic-principles-of-object-o https://medium.com/@ReganKoopmans/understanding-the-grasp-design-patterns-2cab23c7226e

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Hi everyone and welcome to the week 4 of the coding journey blog. For this week’s post I will be talking about a principle called YAGNI which is an abbreviation for you ain’t gonna need it. Now this may seem like a simple topic, but it is very important concept that often gets overlooked in the early stages of programming.

You ain’t gonna need it is one of the key principles to extreme programming and the XP co-founder has states that you should always implement things when you actually need them, never when you just foresee that you need them. The basic concept behind this principle is to do the simplest amount of work that would also get the program to work. The goal is to cut down drastically on unnecessary work, and as a result of this there will be higher productivity rates as well as a more simple to understand code. Efficiency is key when it comes to programming. A software can have many lines of code and functions, but this will be an issue if there are much simpler ways to implement those same functions with a lot less work. The process will take a lot longer with more features and down the line make it much more difficult to maintain.

There are a lot of problems that can occur if you try to implement a feature early when it is not necessary at the moment. There are three things that could happen which include having the wrong feature, having the right feature but it is built wrong or the most ideal option is having the right feature that is built right. Now with these results of the features there is also the outcome of costs. The different costs include cost of building, cost of delay, cost of carry and cost of repair. The cost of building is all the effort spent on analyzing, programming and testing a feature. The cost of delay is the lost opportunity to build and release another feature now. The cost of carry is the complexity added by the feature to code, which makes the software harder to modify and debug. The cost of repair is the effort spent on modifying a feature because it is not exactly what you need now. Now these concepts are the input and output as they go hand in hand. If you make the wrong feature then you have to pay the cost of building, carry and delay. If you make the right feature but it’s built wrong then you have to pay cost of repair, carry and delay. Now with the best option if you make the right feature and it is built right then you just pay cost of carry and delay.

In my personal case, I plan to follow the YAGNI principle in all my future projects because it help simplify projects and saves time. It improves my productivity and prevents unnecessary work and problems.

Check out these additional resources: https://medium.com/better-programming/yagni-you-aint-gonna-need-it-f9a178cd8e1

YAGNI

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

For this week’s post in the coding journey blog, we are going to talk about a principle in software coding knows as dry. I chose this topic for this specific week because it felt relevant to the classwork we did this past week with super classes, abstract classes and interfaces.

What dry means is don’t repeat yourself and this concept is very important for developing software. The actual principle is represented as “Every piece of knowledge or logic must have a single, unambiguous representation within a system.” Now take for example the classwork we were doing, and how there was a method in the superclass that we decided all the subclasses would also include through inheritance. Now in the subclasses, if we wanted that method to do a different version of the method such as fly or quack, then we would have to alter each and every subclass. Even if a subclass does not have the fly or quack method, we would have to add the method and have the code do nothing. Just by talking about this you can see how redundant this starts to become. Now you may be able to get by with this repetition if you’re working on a small project and don’t have much to check for. However, when it comes to larger projects this will certainly turn into a never ending nightmare. Your code breaks and you have to go through all this different code which is similar and figure out what is off. This just seems like a waste of time and effort. This is why the common notion is to use the principle of don’t repeat yourself which has the goal of reducing repetition of the same software over and over again.

The big problem with repeated code over time is that it will become very hard to maintain. If over time, there comes a big change to the code and the logic changes, then it will become a headache. All the places where the previous logic was used, needs to be altered and the big thing that will be wasted is time. If you want to create quality code, then you will also have to use quality time. It is thereby better from the get go to design code to not repeat the same unnecessary methods and logic in multiple places.

To put this into perspective on a personal level, in the past I most certainly used repetitive code and wasted a lot of time. It may have seemed like the easier option sometimes, but as I dove deeper into my projects it became more difficult to figure out the solution for bugs and tracing the code for error. In the future, I know it is the best option to optimize the best way for the code to work without repetition in order to help myself and others down the line.

To read up on more sources, check out these links here: https://medium.com/code-thoughts/dont-repeat-yourself-caa413910753

https://dzone.com/articles/software-design-principles-dry-and-kiss#:~:text=DRY%20stand%20for%20%22Don’t,unambiguous%20representation%20within%20a%20system.%22

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

In this week’s post for my blog about the crazy journey of coding, I will be talking about the SOLID principles. The reason I am selecting this topic is because it sets the tone on how to produce quality code. Many times, especially for most students like me, we rush to finish up any coding project we have and don’t live up to the potential that could have been put forth. Therefore, SOLID principle help give a guideline to follow for almost any programmer to outcome the best work.

Well S.O.L.I.D is actually an acronym that stand for five important principle of object-oriented programming by Robert C. Martin, who is commonly known by as Uncle Bob. Now if you have read my first blog you would know that I went to a lot more details on object-oriented programming and I would suggest everyone read up on that before reading this post. The essential purpose of the principles to create software that is easy to maintain and add onto in the future. These principles also help detect any minor problem in the code that could lead to bigger problems and help change around code any time on the code journey. Now let’s get into what these letters actually represent.

The S in the S.O.L.I.D principle stands for Single Responsibility Principle and it states that a class should have one and only one reason to change, essentially meaning a class should only have on job. This concept should be fairly easy to understand as one class should be responsible only for what it represents and all the methods in the class should correspond to that. The second acronym O stands for Open-Closed Principle and it states that objects or software entities should be opened for extension, but closed for modification. What this essentially means is that classes should be able to extend its behavior, but not be modified. This can be done in various different ways such as through inheritance or an interface, but the main guideline is not to modify.

The L in the S.O.L.I.D principle stands for Liskov Substitution Principle and it states that objects of a superclass can be replaced with objects of its subclasses without breaking the software application. What this simplifies too is that the objects of the subclass need to behave in the same way as objects of the superclass. The next acronym I stands for the Interface Segregation Principle and it states that no client should be forced to implement an interface that it doesn’t use or clients shouldn’t depend on methods they don’t use. These interfaces are difficult to maintain and change over time so it is best to avoid. The last acronym in the S.O.L.I.D principles stands for Dependency Inversion Principle and it states that software entities must depend on abstractions not on concretions. This is due to the fact that abstractions change less and so make it easier to change behavior.

I think personally these principles are all key to establishing good solid code. In the future, I expect myself to catch myself when I am coding and follow these principles. With this outlook, I will be able to keep a clear focus from start to finish of a project, and won’t compromise one thing for another. The principles create a clear road to follow and I have benefitted from learning about it.

To read more up on the S.O.L.I.D principles, here are some sources to check out which I have used for research:

View at Medium.com

https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

This blog post is going to be about one of the most important concepts in today’s world of computer science and it is object oriented programming. The reason I chose this topic is because it directly relates to course material and is fundamental for most computer science students.

I’m going to first start of by explaining the basics of objected oriented programming and try to bring some clarity to people who are either new to coding, or want to learn about a different mechanism of coding. Now keep in mind, there are many different ways to code and different approaches one can take on his specific journey. Now to the outside world of coding, they might think it’s all the same. However, specific types of ways to code include objected oriented programming, functional programming, procedural programming, logical programming, etc. I will expand on this later when I talk about my real life experience with some different ways.

Essentially, object oriented programming consists of object which are created by variables and methods. It consists of many objects who are collected and arranged in a specific class for unique uses based on the person’s needs and end goal. The four main concepts of object oriented programming include encapsulation, abstraction, inheritance and polymorphism. Encapsulation is choosing to limit certain object’s information to be seen by everyone in a way to protect information. Usually this is done by using a private access modifier. Abstraction is similar to encapsulation, except it hides properties from everyone in order to make the outside code a lot more simpler and understandable. Not everyone needs to know the broad details behind the object and helps keep things from causing problems on the main front. Inheritance is when a subclass basically inherits its properties and methods from the parent class. The main objective of this is to reduce redundant code and make things easier to use. Polymorphism is when an object can have multiple functions and change methods through the process of overriding and overloading.

Now the most popular programming languages today are objected oriented programming such as Java, Python, C++, etc. Now two languages that I have had experience with was Java and C programming. Java is an object oriented programming language, whereas C is a functional programming language. When I was learning Java, I never understood the big deal with Java and object oriented until I learned C and saw how not as much could be done. Java is much better equipped for real world projects as it makes code very reusable, simpler as well as saving memory. With C functional programming, there was more code to write for accomplishing simple tasks and also there was less security with direct access to memory. Overall, going into the future I am going to improve my java skills and be more equipped with the simple as well advanced concepts of objected oriented programming because of the many types of projects that can be created with it.

To read more info on object oriented programming link which I used as a reference here is one: https://www.indeed.com/career-advice/career-development/what-is-object-oriented-programming#:~:text=Object%2Doriented%20programming%20has%20four,basics%20of%20a%20computer%20program.

To read more info on different ways to program this is a another link with helpful information: https://careerkarma.com/blog/types-of-coding-languages/

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.