In the “Sweep the Floor” learning pattern of the Apprenticeship Patterns book focuses on the transition when joining a team. Being the newbie is not an easy task, especially when unsure of your skills, so finding your place and claiming suitable work can be a struggle at times. Since I will hopefully be joining a software development team in the coming years, or even next year as an intern, getting accustomed to working on a team and proving my value while not finding myself in too deep on work that I am not ready for will be a somewhat tricky line to toe. This pattern focuses just on that.

            The idea of sweeping the floor, while not meant to be taken literally, can be a literal task. It means to take the tasks that need to be done but no one wants to do. This can either be menial tasks or simply tasks that are painfully boring or something. Although not attractive, this can be a way to start making progress on a team and pay your dues. It can help gain the trust of the team if the tasks are done well, oftentimes because they can be important sub-tasks which free up the way for higher-level developers to make more meaningful progress, so they’re still quite important.

            Having the humility to take on tasks like this is not something I’m worried about; I do not come into the field with a large ego. I knew nothing about computer science before I started my major. I’m not afraid of having to build from the ground up. I’m actually quite eager to. Others’ evaluation of my work will be the most valuable to me, a concept which is alluded to in many other learning patterns within the book. I think this is a great idea and helps carve out a position on a team which can only stand to grow.

            It’s also important to consider the downsides that the pattern mentions as well. Becoming the one that other developers dump the meaningless/annoying tasks on is clearly not the goal, so making sure to not get complacent and expressing an eagerness without overstepping bounds is essential. Nevertheless, I love this idea and plan on going through with it once I join a software development team.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

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.

One of the topics of this class that I don’t know much about is SOLID. Most of the programming I have done has been very small projects that do not necessitate the use of very many design principles. This is not to say they should be applied but they add quite a bit of extra work to something that doesn’t require very many lines otherwise.

Because of my lack of experience with it, I chose to learn a little more about SOLID starting with the “S” – Single Responsibility Principle. I found an article from stackify.com to explain it further.

The principle is self-explanatory. Uncle Bob describes it as “A class should have one, and only one, reason to change.” This is important because it makes your software easier to implement and prevents unexpected side-effects of future changes.

When a class has multiple responsibilities, these responsibilities are no longer independent of each other. If one responsibility needs to change, the more often the class needs to be changed. This may not seem like a big deal but if some things depend on the changed class you may need to update dependencies of recompile dependent classes. To avoid having to change many components to make a single change, give each class only one responsibility.

It also makes your code easier to understand. If there is a problem somewhere it is easier to isolate the problem.

While each class should have one responsibility, this shouldn’t be taken too far by, for example, making each class have only one function.

The article also provides some real-world examples showing the Single Responsibility Principle in action.

I am often guilty of violating this principle. For a project I once made a Pokémon battle simulator. Looking back now I really broke this principle with that one. I had a class to make Pokemon objects and another to do everything else. Because it was for a database course, I connected to the database and had a battle method all in that class.

For the final project I will have to make sure I do my best to stick to the SOLID principles and not get caught in just making the code work. Because it is a group project, I need to be sure the code is easy to understand to others and not just myself. The Single Responsibility Principle is a big part of that.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

As I was browsing YouTube, a video appeared in my recommended videos titled “5 Design Patterns Every Engineer Should Know” from someone named Jack Herrington. Thinking it would be good review I clicked on the video. I wanted to see if were familiar with the five patterns in the video.

The video discusses patterns from the “OG” design pattern book: Design Patterns by the “Gang of Four”. The five patterns are the Singleton Pattern, the Façade Pattern, the Bridge/Adapter Pattern, the Strategy Pattern, and the Observer Pattern. He explains all of these in order as he goes through the video.

Of these, the only one I was unfamiliar with was the Observer Pattern. He explained it simply as there being a publisher and a subscriber with the subscriber listening for events from the publisher.

Something from the video I found interesting was a compiler as an example of the façade pattern. Often you can’t access all the parts of a compiler and it is abstracted to be usable to you as a consumer of that product.

Below the video in the comments, someone mentioned the Head First Design Patterns book. I remember looking at this book in class before and it reminded me to go find it and look at it further. Unlike the Gang of Four book it is written in Java so I have a bit of an easier time understanding what is going on in the book.

This video was helpful as a reminder that there are many design patterns and many resources to help learn them. The final project includes using design patterns so I will look back at these resources to identify what patterns will be helpful in the situations I encounter as I work on the project.

 It was also a helpful reminder that design patterns are not necessary everywhere. Many people in the comments posted about knowing when to use design patterns. There are tradeoffs and consequences to using certain design patterns and it is important to take these into account when choosing to use a pattern in a situation. For example, using the singleton pattern makes life simple. Using it for something like a database driver makes accessing data easy, but it also makes your system inflexible. Whoever is the consumer that is using the database driver also has to have that on their computer to be able to access the database.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

https://www.agilealliance.org/glossary/refactoring/#q=~(infinite~false~filters~(postType~(~’page~’post~’aa_book~’aa_event_session~’aa_experience_report~’aa_glossary~’aa_research_paper~’aa_video)~tags~(~’refactoring))~searchTerm~’~sort~false~sortDirection~’asc~page~1)

This week we’ll be covering refactoring which is a very simple but also very important concept to software design similar to models, the topic I covered last week. The reason why I’ve chosen to talk about refactoring is because while it’s a topic that hasn’t been specifically covered in class; I have had experience learning about a form of refactoring in this software process management class I’ve been taking. According to the link above, refactoring is the process of improving the overall structure of a program’s source code. However, this does not mean that the functions of the program are altered in any way. For example, the interface is not improved on, bugs are not fixed, and code isn’t outright rewritten to change the behavior of the program. Refactoring instead cleans up and organizes the source code in order to be more easily readable and understood. An example of this would be simplifying the two lines “answer = 2 * 5;” and “answer = answer * 8;” into the line “answer = 2 * 5 *8”. This change simplifies the code and makes it easier to understand at a brief glance. On a smaller scale, refactoring can be used to remedy code smells and remove duplication. But on a larger scale, refactoring can alter large bodies of code towards different design styles such as object oriented or functional.

The benefits to refactoring do not end at organization and raising code readability. Refactoring also encourages the use of reusable design elements and code modules. These reusable elements and modules highlight the structural similarities and differences in each code module. Refactoring also improves attributes of code that cause easier maintenance like length, duplication, coupling, cohesion, and cyclomatic complexity. Since refactoring often simplifies source code, the length and complexity are also often times lowered which again makes code easier to read. In order to efficiently refactor code, the dependencies (cohesion) and independencies (coupling) of each module will have to be highlighted in the overall structure of the code. And in the case of duplication, it has already been stated that refactoring can remove it from source code. All of these benefits return back to the intended purpose of refactoring, improving the overall structure of a program’s source code by cleaning and organizing it. It’s a form of proofreading and revising code but also comes at the risk of accidentally changing the behavior of a program. So individuals using refactoring should have a good grasp on which part of their code does what in order to avoid that issue.

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