For my final blog post pertaining to the apprenticeship patterns in the textbook, I decided to review the pattern entitled “Rubbing Elbows.” The situation that this pattern pertains to when the apprentice has almost plateaued and has been working on their own for projects. In this situation, the book explains that the apprentice will sometimes feel like they are missing things (like better ways of solving problems), but that they are not able to find these things on their own during their plateau. The reason I chose to review this specific pattern is because I can relate to it. On my free time outside of school, I have worked on projects on my own, and I know there are better ways to program what I am making but because I work on my own, I find it difficult to find those new and possibly better ways or working. The book’s solution to this problem is to find someone else to work with in order to learn more and have a different perspective on your projects/work. “Find ways to sit with another software developer and accomplish a hands-on task together, side-by-side. There are some things that can only be learned while you are sitting with another software developer to accomplish a shared objective.” I have actually done this before with a classmate while working on making iOS applications for fun, and it was an enormous help. Even if the person you are working closely with does not have a different solution to your problems, the added outside perspective proves to be not only helpful, but also necessary. I was especially excited when reviewing this pattern because I feel like I already am great at working with others, and the fact that that skill could be a good thing for my career is reassuring. The book describes how working with someone else could have many benefits even if it is only once a week. It helps keep you motivated and helps keep the other person motivated as well. If working with a certain person becomes not so motivating, the book explains that this does not mean you should give up, but perhaps you should think about working with someone else who could be even more motivating to collaborate with.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

This week I read the section “Learn How You Fail” in chapter five of Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. This section focuses on the concept of learning from your mistakes by understanding your shortcomings. An example the authors use to illustrate this is writing an implementation of binary search and its tests in one sitting without compiling the code or running tests once. Once finished, compile the code and run the tests in order to find any mistakes you’ve made. Repeat this process until the code compiles and passes all the tests while also writing down notes on each iteration. These notes will act as an identifier to your personal shortcomings which will certainly be useful into the self-assessment that allows one to set realistic expectations and a direction to aim towards in self-development.

The concept of “Learn How You Fail” has a lot in common with “Expose Your Ignorance” like how they both promote self-improvement and emphasize examining one’s shortcomings. But the most important similarities among these is that they’re both concepts that center around learning from your failures. However, the key difference is that EYI is opening up yourself to failure while LHYF is learning from that failure. It’s just that both concepts complement each other in that one naturally leads to the other. Take for example that exposing your ignorance could very easily act as the direction needed for self-development similar to the notes in the “Learn How You Fail” example.

The idea of “Learn How You Fail” is also one that applies to many different contexts outside of software development. For example, before someone learns how to ride a bicycle, they’re likely to fall dozens of times. A saying I’ve encountered in everyday life is that mindlessly failing again and again will only get you so far, improving muscle memory and the like. A key aspect in learning effectively and quickly is knowing exactly what to improve on. That’s why I personally believe that a direction or a goal is incredibly important not only to this concept, but to learning as a whole.

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

Practicing is yet another aspect of software development that I have had issues with in the past. Personally, I find that whenever I bring myself to start some personal project with the goal being to practice programming I find that I simply have too much to do or what I am practicing feels too tailored to this specific practice program. Now that I am coming to the foreseeable end of my time in school, where these practice opportunities are essentially the focus, this issue has been weighing on my mind more and more. Thus, for this post chose to focus on the practice, practice, practice pattern.

Yet again I found myself really enjoying these patterns, as they felt very relatable. This was another insightful read, as I really did not have a set way to effectively practice in mind. I really enjoy the idea of katas that was brought up, which are simpler, but still somewhat challenging, exercises you repeat to try and hone a certain skill. In the case of programming, this can come in the form of working through some older books, as stated in the pattern. The idea of dodjos for programming also sounded enticing, as one issue I found with practicing on my own is a lack of feedback on what I produce. Solo practice is still effective to some extent, but I often find myself wondering if what I am doing is an effective way of solving the problem, or if anyone has devised a better one. This is the exact problem that a dojo addresses and is something I might have to take advantage of in the future!

This pattern has not really changed the way I view software development, at least in terms of practice. This is because I did not have a clear view of how to practice effectively in the first place. I have now been provided this new way of approaching practice that sounds both more engaging and effective than anything I could devise. I now understand that my practice session must involve short, challenging exercises and I must use others as a resource to compare my results and, ultimately, learn. I don’t really have much to disagree with but I did decide that I probably would not use those extremely old books for practice. As exciting as it would be to understand that older knowledge, I have more immediate things to learn.

Source: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s02.html

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

For this first blog post I chose a pattern that focuses on something I have struggled with on and off almost every semester, this being motivation. I am usually very gung-ho when beginning any sort of programming class, or personal project, but eventually I find that I just get completely buried. This can be for a variety of reasons, being other schoolwork or simply getting lost trying to solve increasingly more complex issues, but it happens consistently enough to be concerning. After reading this however, I do have some ideas for ways to try and cope with this should, or more accurately when, I get stuck in this rut once again.

Personally, I found this pattern to be very helpful, as it resonated quite well with me. I have been getting frustrated with a lot of my recent work, as it is all in relatively new languages I only have a vague grasp on, but I now realize what these are. As stated in the pattern, you have to set aside what you are comfortable with in order to grow, and these states of remaining in your comfort zone are classified as Golden Locks. I just have to understand that a part of the journey to becoming a master in this craft is resisting the urge to remain where I am, in terms of my knowledge. Beyond this, all of the examples used in the pattern felt very relevant and did a sufficient job at helping me relate to what the author was trying to convey.

I would certainly like to say that this pattern will have some effect on the way I think about software engineering. I have realized and acknowledge my issue with my motivation, being that I am simply on the road to mastery and must keep in mind that everything I am struggling through is just a part of that process. I cannot just retreat back into only really caring about Java, I have to continue working with these new languages as I encounter opportunities to learn them, otherwise my career, and most likely my passion, will stagnate. Maybe this is due to a lack of experience, but I did not find myself disagreeing with anything said in this pattern really, it was a good read!

Source: 

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch03s03.html

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

            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.