“Apprenticeship makes a difference because it instills a lifelong passion to master the craft. It instills a passion for perpetual learning and, in the process, enables the apprentice to become a great developer.” – Pete McBreen

I do agree with this statement that was at the beginning of the chapter. As an individual, whenever I hear the word “Apprentice”, I always wonder and think about the “Master” because that is who the apprentice learns from. After reading through this chapter, I tried to tie all the concepts back to the title of the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. An apprentice should always try to learn and understand the concepts that the master is trying to teach. Understanding and learning the concepts is one thing. Learning how to implement and use the concepts is another. The techniques that you learn from a master can sometimes, if not most times, be found found in textbooks or they can’t be basically self-taught. Every master can have different styles, which is why a “master” is very valuable and special in a sense. To me, that is an Apprentice and Master relationship. When the apprentice is trying to perfect their craft with the aid of their master, it instills something very special within the apprentice’s work and makes them have the desire to want to learn and create more. This quote by McBreen is very important to me and makes sense to me the most. To relate it to myself, I feel that the Master is the contents of which I am trying to learn, and the Apprentice or Journeyman is myself.

There is a quote that also sparked my interest because it is a statement that I fully acknowledge. “One of the lessons we’ve learned from the Agile development movement is that just telling people to do things doesn’t create lasting or sustainable change. When the people you’ve advised encounter a situation that isn’t covered by the rules, they’re lost. However, if those same people have imbibed the values that underpin the rules, they can come up with new rules to fit any situation. Our goal here is not simply to hand people a rule book, but to give them the ability to create new practices for new contexts, which in turn drives the discipline of software development forward.” This supports the thought of critical thinking in a sense that thinking outside of the rules in order to create new ones is the foundation of continuing the evolution of software development. If developers encounter a situation that certain rules do not cover and they become lost, software development cannot progress forward.

As I am currently aspiring to become a future video game developer, I expect that there are going to be new rules that are going to be created constantly. I know that I am going to learn and to develop certain “crafts” to be very efficient in that environment of work because there will be many things to adapt to. As Pete McBreen points out, there are many developers out there today in the field. The important question is are there enough “good” ones? When I head out there in the field, I would want to be recognized as one of those “good” developers.

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

This week’s reading was Code Smells written by Jeff Atwood, on Coding Horror. As the title of the blog suggests, the message that the reader should get from the post is to familiarize themselves on the common smells to prevent design problems. With that, he lists the different type of smells into two categories, “Code Smells within Classes” and “Code Smells between Classes”. The first category deals with simplifying, removing or splitting code where its due to make reading methods easier. This idea is also applied to classes, which should reduce unnecessary classes or makes sure encapsulation is applied properly.

There is no definite reason as to why I chose this topic but it is said that developing your code nose early is useful for the future! From what I have gathered so far, the idea behind this topic is to have a good design where the earlier choices of methods/classes will not have conflicting issues for later additions or improvements to the code. Many of these code smells are already taught in earlier introductory CS courses such as, duplicated code and making useful comments.

After reading about the different types of code smells, I have noticed a couple that code be smells in previous school projects. One would be the overuse of comments, as I sometimes find myself not remembering what a certain function was used for, which compels myself to leave a comment here and there. Another would be oddball solutions, where sometimes issues mysteriously fixes itself as you continue with your code. This usually leads to problems in the future while adding newer functions. However, there are a couple of smells that are useful to remember now then later such as Speculative Generality. After being taught to prepare for future problems in life, it’s also sometimes applied to writing code but is a wrong mindset. Only implementing things when you need it will reduce clutter and seems to apply to the dead code smell, where you should delete unused code.

By exercising or having an open mind to these design problems will help prevent simple problems from appearing while working on projects. Having clean code benefits myself and others while reading the different classes/methods we each produce. Which should entail a better experience for group work, and saves time solving problems that should not have existed in the first place. There is no way to remember all the different smells, but being aware of them will help myself produce cleaner code in the future.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

A Lambda Expression is a representation of an anonymous function which can be passed around as a parameter thus achieving behavior parameterization. A lambda consists of a list of parameters, a body, a return type and a list of exceptions which can be thrown. I.e. it is very much a function, just anonymous.

An instance of a lambda can be assigned to any functional interface 
 whose single abstract method’s definition matches the definition of the lambda. In fact, a lambda is a less verbose way of defining an instance of an interface provided the interface is functional. Since, the definition of a lambda can match the definition of multiple functional interfaces, hence, a lambda instance can be assigned to any of these matching interfaces.

The reason i picked this topic was because it was something new i have seen in the java language. Also wanted to know more about it and see if i can utilized it on some of my java programming language.

Examples of lambda expression.

First of all. Comparing java 7 to java 8.

public interface StateChangeListener {

public void onStateChange(State oldState, State newState);

}

In java 7 we implement this interface in order to listen for state changes. You do this

public class StateOwner {

public void addStateListener(StateChangeListener listener) { … }

}

But in java 8 you can add an event listener using a java lambda expression. like this.

StateOwner stateOwner = new StateOwner();

stateOwner.addStateListener(

(oldState, newState) -> System.out.println(“State changed”)

);

From this topic ( lambda expressions), i learned that previous java or java 7, if i wanted a block of code to be executed, we need to create an object and pass the object around. From Java 8, lambda expressions enable us to treat functionality as method argument and pass a block of code around. Lambda expressions in Java 8 are very powerful and therefore very compelling. For me, lambda expressions is way much better, convenient and very easy.

link to the resource : http://tutorials.jenkov.com/java/lambda-expressions.html

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

https://www.thecodingdelight.com/write-clean-code/#ftoc-heading-2

As I learn more about computer science, I find that writing code for a programming project is very similar to writing an essay for an English project. I find that the core structure of a coding language mimics the core structure of any other language. A run on sentence can be compared to poorly using indentations, grouping your variables together at the top of the page is like having a well organized thesis statement. Just as we spend years taking English courses perfecting our grammar and sentence structure, it takes a lot of practice and learning to perfect our syntax and ability to write clean code.

Some benefits of writing clean code include:

• Being able to easily follow your own code to track down errors
• More efficient productivity
• A more professional reputation
• Your employer/teacher will resist the urge to strangle you

This article explains in detail why we should try to better our code and how to develop better habits from common mistakes. I for one, typically write messy code just hoping it will work and later try to buff out bad variable names, overly complicated methods, and half written comments. After reading this article however, I’ve learned tips and tricks for writing better code and how to embrace the clean code mindset. I can only imagine how many frustrated programming teachers’ evenings I’ve saved after reading this article, so for your own sake and for the sake of whoever has to look at your code, I recommend you read this article as well.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.