Category Archives: Week-2

Docker

As my journey to find my very first internship as a software developer. I’ve noticed that the majority of the posts require Docker’s experience. From there, I realized that Docker is an essential tool for Software Developers and their professional careers. This blog is about Docker of what it is and also why it is necessary nowadays.

Docker is a container running time. A container is a standard unit of software that packs up codes and all their dependencies so the applicant might run quickly and reliably from one computing environment to another. Docker container is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries, and settings

The good thing about Docker is it helps developers get their application to work on every machine. Also, the abundant app’s libraries and dependencies ready to be executed make Docker even better compares to its same category competitive. Besides that, Docker is lightfast and also very easy to maintain.

Also, running applications in a container brings many benefits to both developers such as:

  • Portability: Once developers run their containerized application on their machines they also would be able to deploy it to other operations and be assured that their applications would perform the same as on their own.
  • Performance: VMs are alternative methods for developers but Docker offers much more compared to regular VMs as faster to deploy, quicker to start, and smaller footprint than ordinary VMs
  • Agility: Containers offer portability and performance help reducing time-consuming and make the process responsive and agile. Such advantages provide a better way to deliver the right software at the right time.
  • Isolation: A Docker container that contains one of the applications also includes the relevant versions of any supporting software that the developer’s application requires. If other Docker containers have different versions of the same supporting software, that is not a problem because Docker containers are independent.

Most uses of Docker make developer life simply better while developing applications. But it does not mean that Docker could entirely replace the actual Virtual Machine. VMs are still much needed if we have to have a whole operating system for each customer or the entire sandbox. VMs are still being used as middle layers when you have a big server framework and many customers that using them. Despite many good things that Docker could bring to developers, VMs still has a firm grip within the industry and development cycle.

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

UML Class Diagram Arrows

Seeing how one of my CS classes just recently introduced me to UML class diagrams, I wanted to conduct some research on the formation and comprehension of the diagrams. I looked for blog posts that showed examples of the diagrams and how they would be written, since I like reading written explanations and visual representations.

I stumbled across a blog covering the different arrows used in the diagrams, as well as when and how they can be used. That blog can be accessed at https://www.gleek.io/blog/class-diagram-arrows.html.

The blog presents to us six different types of class diagram arrows: directed association, inheritance, composition, realization/implementation, aggregation, and dependency. I had already seen directed association, inheritance, and implementation arrows, but I had not yet familiarized myself with the others. I learned the following from the blog:

A composition arrow in a UML diagram does not have an actual arrowhead, but instead looks like a solid diamond at the end of a solid line. The solid diamond is at the sub-object end of the solid line, and indicates that the sub-object cannot exist without the container class. It can be shown using -<*>.

The aggregation arrow looks just like the composition arrow, except that the diamond is hollow/white. The aggregation arrow is used to show association between two classes, but the subclass can still exist without the super class. It is shown with -<>.

Dependency arrows have a thin arrowhead and a dashed line. They show that two elements depend on each other but the dependency is weaker than standard association. Making changes to the parent class will have an impact on the child class. It is shown with -.->.

This blog was a great source to understand the usage of different arrows for UML diagrams. It provided great examples of when to use aggregation and composition, and I now know to take those into account for when I will need to make my own UML class diagrams in the future. It was easy to understand how the relationship between a library class and a book class can use the aggregation arrow because books can still exist after they are borrowed from the library. It was also easy to see how the relationship between a shirt class and pocket class can be composition association because a shirt pocket would not exist without the shirt. I also think it was a nice touch for the blog to include a video on the page where it explains the arrows and shows how the examples would be typed up on gleek.io.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

JUnit 5 and Gradle

In this second assignment for the software quality Assur & test we had to practice writing more Junit5 test cases. We had given three java classes, product, customer, and order. Our job was to write Junit5 test classes. Different from the week before this time we had more test cases to write. I liked and disliked this assignment because I enjoyed writing the test cases but the part that was not my favorite was running gradle in the project. It gave me a lot of trouble until I figure out what was wrong with it.

I believe that like me, many students or developers like to write Junit5 test cases. In our assignments we just scratch the surface of the features offered by JUnit 5. To find out more, go to the JUnit 5 documentation, it covers a huge host of topics, including the features we’ve have used until now and many more in detail. What I personally like about writing in Junit is that it follows a modular approach, which makes extending the API easier. It provides a separation of concern, where writing tests and discovering/running them is served from different APIs. In essence, three main modules exist within JUnit 5: JUnit Platform + JUnit Jupiter + JUnit Vintage.

Another obstacle that I had for this assignment was running gradle in program. Gradle is an open-source build automation tool that is designed to be flexible enough to build almost any type of software. What I like about it is that gradle avoids unnecessary work by only running the tasks that need to run because their inputs or outputs have changed. When I run gradle in my computer some of the test cases failed even though they passed in my environment. The main problem was in one test case. My solution to this problem is think another way you can write your test case, and that’s what I did. I changed the test cases and added some import statement that were missing and no issue after that.

Overall, I enjoyed this assignment. I like writing Junit5, but I don’t enjoy gradle. I had used it before and always causing trouble for me. Hope in the future that things will run smoothly.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Breakable Toys

Breakable Toys is a very interesting pattern. It talks about doing and undoing something. You must learn how to break it in order to unbreak it again and really learn its inner parts and how does it work. As the author clearly states, “failure is merely an incentive to try a different approach next time.” Breakable Toys is more about deliberately creating opportunities to learn by stepping beyond your boundaries and single-handedly building complete software projects.

I´ve applied that pattern repeatedly, sometimes breaking it too much that I would take hours to unbreak it, but at the end, taking with me a greater knowledge. This way I learned computer languages. I have a project with requirements, and I must translate it into code. Nothing works with the first try so you have to break your classes over and over again until you get it right. At the end what you gain is experience in that language and knowledge that you can share and use it in the future.

This pattern made me understand that is ok to break and fail. In the apprenticeship pattern book, in the chapter about the breakable toys, the author writes that Only by attempting to do bold things, failing, learning from that failure, and trying again do we grow into the kind of people who can succeed when faced with difficult problems. I am one of those persons who is afraid to break it because it might damage the whole thing even though it might need that.

Breakable toys is one of those patterns that need to be in your mind all the time. You need to remind yourself that the road to learn something new is not easy and has a lot of failures, but what is important is that you do it with passion. It really doesn’t matter what you decide to do, as long as you experiment and learn.

You can’t do anything well unless you love it, and if you love to hack, you’ll inevitably be working on projects of your own.

—Paul Graham, Hackers & Painters

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

MongoDB

Today, I will be talking about an article titled, “MongoDB : an Introduction” by Harshit Gupta on Geeks-for-Geeks.com. This article explains what MongoDB is in a simple format by comparing it to relational databases. He explains that MongoDB is a NoSQL database meaning it is non-relational. Instead of storing data in a tabular format such as SQL, it stores data in its document model which is much more flexible. This makes it similar to a JSON format (called BSON which stands for Binary JSON). When dealing with big data, it is a much better choice to use MongoDB instead of a relational database because it is horizontally flexible. This means that if the demands of the database grows, we can add more servers so that it can handle the change. While adding a new column to a RDBMS requires replanning of the schema, adding new fields to a NoSQL database is easy because it is schema-less. Another major feature is that MongoDB is a distributed database meaning multiple copies of data is stored across multiple servers making data recovery fast and reliable. The article provides easy to read bullet points on the features of MongoDB, when to use it, and also the differences between MongoDB and RDBMS. It also goes over the languages it supports, how to install it, and provides a list of major companies using it.
The reason I selected this source is because Geeks-for-Geeks has always been a trusted website that I will go to when having problems in programming or with topics in class. They always provide a well thought out, simple explanation for topics that seem confusing in a textbook. While reviews for Geeks-for-Geeks are mixed, it has always been reliable for me and I have never had any problems with it. For basic topics at least, it has been very accurate. The content in this article held up with everything I have learned about MongoDB already, and also, matched up with what other writers said about it.
I chose this topic/article because I thought it would be good for anyone in class who does not yet know what MongoDB is and would like to read up on it. In this course, we will be using MongoDB for our final project to store data so we will be using it in the future. I started learning about MongoDB with this article as a good introduction then took it to more concrete and informative websites to learn about it further. MongoDB is good to learn if you will handling large amounts of data in the future.

Source: https://www.geeksforgeeks.org/mongodb-an-introduction/

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Why I Prefer Object-Oriented Design

Object-oriented design is incredibly useful in my opinion. While there are also functional and procedural languages, I feel that languages which are primarily Object-oriented are the most exciting and useful for the types of projects which I enjoy. Topics such as game development, large-scale user interface focused applications such as Microsoft Word, and general programming can all benefit from an object oriented approach. While functional and procedural languages are certainly important and have legitimate uses, I would be unlikely to choose one for any large project.

I recently read a blog post on The Robert Half Blog, a blog which focuses on career advice and discussion of skills which employers look for. The post focuses on a quick overview of some reasons that object-oriented programming is useful and some of the aspects of object-oriented programs which make them easier to understand compared to code written with different paradigms.

Overall, the article focuses on features which are key to the concepts of object-oriented design. Modularity is discussed, and while I was already aware of the concept the post brings up an interesting point. The idea that the self-contained nature of object oriented code makes it easier for teams to work on many different projects at once, while minimizing the chances of duplicate code (since classes and objects are self contained, it is almost always clear what each one will do in terms of functionality).

Additionally, the topics of inheritance and polymorphism are discussed. While I have always been able to easily visualize the concept of inheritance (one concept extends from and inherits functionality from another), polymorphism has been confusing to me throughout my academic career. The author of the post uses a clear example which was very helpful in clarifying my understanding of polymorphism. An example “car” class is discussed, with “drive” function which controls driving in general for all types of cars which extend and inherit from the parent car class. Since all types of cars inherit the drive method from the superclass, they can call drive with their own information and variables, and the method has the ability to be adapted into many potential situations.

Finally, the post discusses the use of object oriented languages in problem solving. It is described as a “natural and pragmatic approach”, which accurately describes object oriented languages in my experience.

Although the information provided in this post is fairly general in the information it provides, the examples and concise explanations of a few concepts which were becoming unclear to me over time (it has been a while since I have been able to study and review modularity and polymorphism, polymorphism in particular has been especially confusing). The post provided a good review of these concepts, and I will likely attempt to introduce polymorphic methodologies into some of my projects in the future. In some circumstances I think a simple explanation can be more effective than something complicated.

https://www.roberthalf.com/blog/salaries-and-skills/4-advantages-of-object-oriented-programming

image from The Robert Half Blog, July 13, 2017

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

S.O.L.I.D

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.

S.O.L.I.D

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.

Hello fellow CS enthusiasts and beginner programmers!

  In this week’s blog post, I plan to go over Object Oriented Programming. I found an excellent blog that explains the four principles of OOP; encapsulation, abstraction, inheritance and polymorphism. The author hilariously titled the blog “How to explain object-oriented programming concepts to a 6-year-old”. As a father of two 6 year old boys, I don’t see many 6 year old’s understanding it but it did however clarify Object Oriented Programming for me. I chose this specific blog because I found it comprehensible and uncomplicated. It was written and formatted in a way that made it very enjoyable to read. I have read many examples in textbooks but none of them were as easy to understand as these for me.

I enjoyed the simple example the blogger used to explain encapsulation. Encapsulation happens when the object keeps its state private inside a class, but other objects can’t directly access it. Other objects they can only use public methods. The object maintains its own state, and unless explicitly stated other classes can’t change it. We are made aware of a developing sim game involving a cat class which has private variables as the “state” of the cat such as mood, hungerLevel, energyLevel. The cat in the example also has a private meow() method, and public methods sleep(), play() and feed(). Each of the public methods modifies the state of the cat class and has the possibility of invoking the private meow() method.

To explain abstraction, the blogger used an example of a cellphone. When using your cellphone, you only need to use a few buttons because implementation details are hidden. We don’t need to be aware of all the intricate processes that occur when we press buttons on our cellphones, we just need them to behave accordingly as expected.

Inheritance is the concept of code being reused to create more specific types of an object. is fairly easy to understand due to classes being referred to as parent and child classes. The child receives all the fields and methods of the parent class but can also have its own unique methods and fields.

When explaining polymorphism, the author uses the example of a parent “shape” class with the children triangle, circle, and rectangle. In the shape class we have methods CalculateSurfaceArea(), and CalculatePerimeter(). The children classes utilize polymorphism when calling the abstract classes of the parent because they each have their own formulas for surface area and perimeter.

Since discovering this blog post, I am more confident in my understanding of OOP. I can visualize the 4 principles better and will be able to utilize them in my coding much more efficiently now. I hope you enjoyed this blog post, attached below is the blog which inspired my post.

https://www.freecodecamp.org/news/object-oriented-programming-concepts-21bb035f7260/

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

S.O.L.I.D

In the second week of my blog I will continue to talk about the Design Principles. These are the first steps that each of us learn when we are introduced with the world of programming. The first week I talked about the importance of OOC and how to get out of a bad OOC case. Today I want to talk about SOLID. Computer science and their acronyms, never ending.

What does Solid stands for? Probably you all know but I will explain it anyway. S.O.L.I.D is an acronym that represents five principles of object-oriented programming and code design theorized by Robert C. Martin also known as Uncle Bob. 

[S]ingle Responsibility Principle
[O]pen/Closed Principle
[L]iskov Substitution Principle
[I]nterface Segregation Principle
[D]ependency Inversion Principle

The goal of the principles is to make it easier to develop, maintain, and scale. They also make it easy to recognize and avoid code smells as well as improving the refactorability of your code.

The reason why I choose this topic is that I like everything that makes my life easier. And these principles have helped me a lot in my programming experience. I used to do a lot of repetition in my code, so these principles helped me understand how to code better. Remember “Do not repeat yourself”.  SOLID it makes your software easier to implement and prevents unexpected side-effects of future changes.

I researched and read a lot about Solid principles, to understand the concept and how to apply it. There are tons of examples, books, websites that are nice, help you with anything that is unclear. Stackify and Medium are two of my favorites in this topic. They show the importance of SOLID and apply it in code examples. Stackify it is more detailed, shows what a future developer should keep in mind, tips and tricks that you might you use it.

Simply learning and knowing these principles will not in itself make a person a better programmer. To truly be able to understand them you must apply them. If you cannot do that in the code base you have now, then work through practice problems applying them there. As you use them you will see why they are important and where they may not be the best choice. This is something that comes with time because it takes many experiences to get a full picture or how they can be applied. Whether you are just starting your career and learning the best ways to write code or have been at it for decades there is much to learn from just applying simple principles to the way you code.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.