Author Archives: Austin Engel

Maven Overview

Today I will be writing about Maven using information from the article Maven-Overview by TutorialsPoint. Maven is a project management tool giving a complete build process framework. Mavens objective is to provide a comprehensive, reusable and maintainable model for projects and to provide plugins and tools to interact with this model. Since Maven uses a standard directory layout and default build lifecycle, development teams can quickly set up their project builds. When you have multiple development teams Maven can create a standard build structure for all teams to use. This promotes consistency across the project while developers create reports, builds and testing automation setups. Maven gives a way for developers to manage builds, documentation, reporting, dependencies, SCMs, releases, distribution and mailing lists. Mavens project structure is declared in in the pom.xml file. POM stands for Project Object Model and contains the fundamentals of the entire Maven system. This pom.xml file is similar to the build.gradle file we have seen/used in class. Some features of Maven include its ability to generate a website or PDF including complete documentation, backwards compatibility, automatic parent versioning so that there is no need to specify in the sub module, parallel builds achieving performance improvements of up to 50%, and improved error reporting.

This topic relates to class because it is a software project management tool, which can be very useful to developers. We often used Gradle in class which is a similar concept. I selected this article from TutorialsPoint because it is a useful website for quick references, overviews and tutorials. It is similar to w3schools which is another website I use often for quick tutorials, references, etc.. I would say that the information is reliable, just more shallow as it does not dive deep into topics. I would not use it as the only source when trying to learn a certain subject in depth as you will not get a deep understanding of the material. As an overview though, I would say it is perfect. I personally had an okay understanding of Maven as I had used it a couple of times but never knew the finer details as to how it is different from other project management tools. Some things I had learned from this article are its many features including its use for reporting and documentation. I plan to use project management tools for future projects, so it is good to know the differences and know which one is the right one to use.

Source: https://www.tutorialspoint.com/maven/maven_overview.htm

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.

What is Gradle?

Today I will be writing about Gradle and the article “What is Gradle?” on the Gradle, inc website. Gradle, as explained by the company, is a build automation tool that is open source. Gradle can build almost any type of software due to its flexibility. Gradle build scripts have three phases, initialization, configuration, and execution. First, it sets up the environment. Then it constructs a task DAG or Directed Acyclic Graph to decide which tasks need to be ran in which order then executes these tasks. Gradle runs on JVM and depends on the user to have JDK installed in order for it to be used. This is a plus for people have have used the Java platform because you can use standard Java APIs in the build logic. This article is everything you need to understand what Gradle is and how it works. It first gives an overview, split into a summary and five subheadings explaining more into depth on how it functions. After the overview it gives “Five things you need to know about Gradle” which discusses key factors that makes it different than other build automation tools. I selected this topic because we have been using Gradle in class, but I never fully understood its use and how it works. This article answered exactly that. The article is by Gradle inc, so there wont be a more accurate article on what it is and its functionalities. I personally found this article easy to read. As mentioned in my prior blog posts, I like when the reading is split up into subsections and headings. This makes it easier to keep track of what the article is talking about and keeps the information organized. There is not more than 4-5 sentences per subsection which keeps it to the point. Also, the diagrams provided do an excellent job on displaying what the subsection is trying to convey to the reader. For example, their diagram of the DAG that Gradle makes to determine the order of task to be completed is split into two parts. One shows an abstract model for a general view, then it gives an example for a standard java build. By giving the abstract and the practical example, it gives you two diagrams in which you can make a connection to better understand what they are trying to explain. Overall, I recommend this article. I had learned a lot about the tool and will be more confident using it in the future now that I understand its use and how it works.

Source: https://docs.gradle.org/current/userguide/what_is_gradle.html

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.

Adding Comments to Code

This post is about Chapter 4. Comments from the book, Clean Code by Robert Martin. This chapter along with the rest of this book has a strong relationship with the course because it is all about how to write clean organized code. This chapter is on writing effective comments. Rather than long drawn out chapters of plain text, the chapter is split up into many subheadings with even more sub-subheadings. I find this format very useful because it splits up and organizes the information so that it is easier to read and understand. Many of the subtopics have many examples to go with them. This makes it even easier to understand what they are trying to say. The chapter is split up into into two main sections/subheadings, “Good Comments” and “Bad Comments”. Each have many subheadings to them such as “Legal Comments”, “Explanation of Intent” , and “Informative Comments” under the “Good Comments” subheading. “Redundant Comments”, “Misleading Comments”, and “Mandated Comments” under the “Bad Comments” subheading. I selected this article because we have not gone over proper comment writing in my classes (or at least I have not), and I think it would be an important thing to learn for future jobs and class projects. I have found the information in the article to be very direct and informative. As said earlier, it is split up into various subheadings with subtopics so if you are debating whether to add a certain comment into your code, you can go right to topic of the exact type of comment you are looking to add. I have learned about “noise comments” which is basically putting comments that are not needed such as /** Default Constructor*/ over a constructor. I would do this because I would typically like to explain everything in the code but things such as constructors explain themselves. Another is “mandated comments” where you give a javadoc at every single function. I would always do this but it only creates clutter. An example of a “good comment” that I have learned about is “warning comments” where you can warn other programmers of certain consequences for example leaving, “// don’t run unless you have time to kill” above a test with a really big file. Another example of a “good comment” is “amplification” where a comment can be used to amplify the importance of something that may not seem that way. I will be able to apply this knowledge in the future with projects and work to provide clean uncluttered code and powerful, efficient comments.

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.

Law of Demeter

Todays blog is about the Law of Demeter a.k.a the Principle of Least Knowledge. This information is based off of the article, “Object Oriented Tricks: #2 Law of Demeter”, by Arun Sasidharan on the website “Hackernoon”. The law uses the Tell Don’t Ask principle which states that we may call methods of objects that are: passed as arguments, created locally, instance variables, and globals. In other words, saying that “each unit should only have limited knowledge about other units”, that are closely related to the current unit. Basically the Law of Demeter (LoD) says that it is a bad idea for single functions to know the entire navigation structure of the system, or to have a chain of functions, also known as a “Train Wreck”. The article states, “We want to tell our neighboring objects what we need to have done and depend on them to propagate that message outwards to the appropriate destination”, and that is what we need to do to solve this problem of “Train Wrecks”.

I chose this article because it was one of the first to come up when searching “Law of Demeter”. When I looked into the article it seemed like a reliable source. I also looked up reviews on the website before diving too far into the article. Many people suggested the website in their reviews so I concluded that it was a trustworthy source. The article has paragraphs discussing the law/principle, code snippets to show the before and afters of using the Law of Demeter, and then a final summary at the end to give an overview of everything talked about. I have found that articles with the same elements/structure help me a lot with understanding a new subject.

While reading about the Law of Demeter, it brought me back to a few times where I personally broke the law on projects. There has also been a few times where I have seen people break the Law of Demeter in tutorials, such as the one I watched for the Decorator Pattern. With this article, I learned how to write reliable, clean functions and to use them in a reliable manner. I also learned that it is very difficult to accomplish. As the article states, it is more of a suggestion than a law for that exact reason. Unlike some of the other principles, this is something that we cannot be proficient in in a single day. It is something to set as a longer term goal to improve on. I hope, through practice, to be able to utilize this principle in an efficient manner on future projects.

Source: https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85

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.

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.

Integration Segregation Principle

This blog is about the Integration Segregation Principle (ISP) based off of the “SOLID: Integration Principle” article by Anu Viswan. This topic relates to the course (CS343) because we will cover SOLID, a combination of principles which contains ISP.
Integration Segregation Principle is about organizing your interfaces in a way where you will not be implementing methods that are not needed in your subclasses. The example given in the article by Viswan contains an IPrinter interface with an All-In-One Printer class and an Economical Printer class. The example that shows bad technique in ISP displays the IPrinter interface with three methods: print(), scan(), and copy(). For the All-In-One Printer class this is fine since as it has the functionality of all three methods. However, the Economical Printer class only prints. This leaves us putting exceptions in the scan() and copy() methods. This could lead to a violation of the Liskov Substitution Principle and is also known as a “fat interface” or “interface bloat”.
This problem is most noticeable when each of the implementations have separate assemblies. When making a change in the interface, all of the assemblies have to be rebuilt even if it seems as there is no change in their functionality. ISP reduces the impact when making changes.
The example of the correct way to build the IPrinter interface as given by Viswan would be to create smaller interfaces with an IPrinter interface containing the print() method, an ICanScan interface containing the scan() method, and an ICanCopy interface containing the copy() method. Now, the Economic Printer class can implement only the IPrinter class with the methods it supports. Meanwhile, the All-In-One Printer class can implement each of the new interfaces giving it all the additional features.
One side note about this example that Viswan added to the end that I found important to clarify is that this does not mean that all interfaces should have only one method but that we should understand the responsibilities of the interface.
I chose this topic because I think it is an essential rule to follow in order to have a solid and well-rounded class hierarchy that will not cause problems down the road. I chose Viswans article in particular because the content by Viswan on the rest of the SOLID principles seem very reliable, accurate, and well thought out. This will be of great importance when designing our final projects for this course.

Source: https://bytelanguage.net/2020/04/15/solid-interface-segregation-principle/

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.

Introductory Post/CS-343

My name is Austin Engel and I am a senior at Worcester State University studying Computer Science.

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.