Tuesday, December 28, 2010

The power of Groovy - notes of "Transforming to Groovy"

Yesterday I watched a video presentation from infoQ:"Transforming to Groovy", presented by Venkat Subramaniam, I read his book: Programming Groovy. The presentation is really great, the author used lots of code examples to explain the power of groovy: first he provided the java code, then refactored it into groovy code, so you will find out how concise the Groovy is compare to Java. The whole presentation is 1.5 hour, but I did not feel it is quite long.  I remembered the author describe the Groovy using the term "less ceremony", Which reminds me the how to describe the power of Groovy: "Accomplish more by doing less". And when he refactored java code to Groovy code, he described it as "reducing the noise".  I like the word "noise" to describe Java code, since Groovy is quite expressive, concise, and its dynamic nature allow developer to focus more on their core business problems ( essential problem), and spend less time to deal with the language issues (accidental problem), which is noise compare to the business problem.

What I learned
AST transformation
   Before I did not aware the feature of AST transformation in Groovy, probably this is the new feature,  because I did not find this topic in the book.
  The author covered @Immutable, @Newify, and @Delegate

@Immutable
@Immutable class Person {
   String firstName;
   String lastName;
   int age;
}
@Immutable annotation applies to class level only, it does not support on the field level.

@Newify
@Newify def createPerson {
    Person.new("John", "Smith", 28)
}

@Newify(Person)
def createPerson {
   Person("John", "Smith", 28)
}

@Delegate
class TirelessWorker {
   public void work() {}
   public void report() {}
}

class Manager {
   @Delegate employee = new TirelessWorker();
   public void schedule() {}
}

Here the Manager class can use all the methods of TirelessWorker class, if you add/modify method of class Tirelessworker, you don't have to modify the Manager class, it follows the OCP principle.

Multimethods
Multimethods is one of the major difference between Groovy and Java. Multimethod means the method call depends on the target and the parameter type, which reminds me the multiple dispatch, Java does not support mutlimethod, it only support single dispatch, I remember when I learn the Visitor pattern, I learned the multiple dispatch term, I am sure the Visitor pattern will be much easier to understand if the language support multiple dispatch, cool.

ArrayList
use spread-dot operator to access ArrayList
*.  is called spread-dot operator, for example:
list*.member  =  list.collect { item -> item?.member }

It means given a list, iterate each item's specific method, form the return value as a collection.
get each item's first name: list*.firstName

Groovy follows the Kanban principle
I think Groovy is a good example of evolutionary and emergent design, since you can begin with purely java code, then migrate with Groovy, and even more you can mix with java and Groovy code in your project. Let's look at the Kanban's 2 foundational principles: Start with what you do now; Agree to pursue incremental, evolutionary change. Pretty similar.

Based on this, I think Groovy is an important language that worth every Java developer to looking at.

Wednesday, December 15, 2010

Try Pomodoro

Today I finished the book of "Pomodoro Technique Illustrated". Actually I heard of the Pomodoro in last year, but I did not think it seriously, until recently Dan North recommend it in his last two talks, so I decided to look at it. Through over a week's learning and practicing, I like it, it is simple, straight forward, and powerful.

The Pomodoro technique is pretty simple:
- Choose one single activity from your TO DO List;
- Set clock to 25 minutes focused on a single activity for 25 minutes, during this time-boxed 25 minutes,  you only have one activity, and one goal: finish it.
- After 25 minutes, take 5 minutes break;
- Choose the next most important activity, start again;

The Pomodoro is timeboxed, focus on single activity and single goal. It helps you prioritize your task, help you keep focused and remain high productivity.
It emphasize on execution, getting things done, and NOW. I found it is similar as Getting Things Done, but comparing with GTD, I like Pomodoro because it is quite hands on and easy to implement,  actually I have not finished the GTD book  yet. It focus on only one thing at a time, and its emphasize on NOW remind me the ZEN philosophy.

From Agile perspective, Pomodoro like a personal agile methodology, or specifically it very similar as SCRUM, I would rather say it as personal SCRUM, because you can treat each Pomodoro as SCRUM sprint, and the inventory as SCRUM backlog. And quite similar, in SCRUM, you can not change your task during each sprint; while you can not change your task during each Pomodoro. Pomodoro also focus on planning,processing, tracking,retrospective, so it is really agile.

I only started Pomodoro for only a week, I like it because it provide you the awareness the time,prioritizing and single minded; before it is quite easy to yak shaving, or get distracted. The Pomodoro provides a mechanism to let you get focused and remain higher rhythm, then improve your productivity.

Some notes from the book:

- time-boxed, single activity,single goal
- 5 stages: Planing, Tracking, Processing, Visualizing - retrospective
- Deming-Shewart cycle: plan, do, check, act
- Tools: TODO Today Sheet, Activity Inventory,Record Sheet
- Pomodoro will first Prioritize, then focus on the most important activity (like scrum)
- Pomodoro need to see the big picture before you decide what to do
- it is goal oriented
- it has immediate feedback

Interruptions
- principle: neither switch activities nor stop an activity in the middle of a Pomodoro.
- avoid LIFO
- avoid BPUF

Deal with internal interruptions
- Strategy: Accept, Record and continue
- Write it into Unplanned & Urgent
- never switch activities in the middle of Pomodoro: "Once a Pomodoro begins, it has to ring."

Deal with external interruptions
- Strategy: inform, negotiate,schedule,call back

Resources:
I use my iphone as a timer, but I want to use it as vibrate only, but I could not find a vibrate only ringtone, try this link, it tells you how to set the silence only ringtone

Sunday, December 12, 2010

Some thoughts about Conway's law

One of my best learned from QCon San Francisco is Conway's Law, I heard it at least 3 times from different talks, especially from Michael Feather's talk. It is so striking, I never aware this before. Here is the definition of the Conway's law:
organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations
In short, you can understand Conway's law like this:

  • The software design structure is constrained or shaped by the company's physical structure;
  • Your code structure mirrors your organization's structure.


This concept is quite interesting and so striking, it forced me into further thinking:

Constraints
Based on Conway's law, we can conclude:

  • Good organization's structure generate good software architecture, bad organization's structure generates bad software architecture;
  • The messy code base reflect its organization's messy management, the clean code base reflects the organization's clear structure;
  • Management structure is quite similar as the code structure, for example, some manager like to control everything and focused on details, he does not know how to delegate, just like the "GOD Object" anti-pattern in the software development.
  • The software manager's style, like/dislike and skills may also constraints the software product;
  • Developer's own skills, knowledge, communication skills and ignorance level, etc, may also constraint the software product. We need to be aware of these constraints.

Conway's law in the other way
Can we good developer influence/improve organization by applying the good practices/patterns/principles?  For example, As a developer we knows how powerful the design patterns and SOLID principles to the OO design, and manager can apply those patterns to improve/refactoring the organization structure. Actually I have the idea long time ago: manage a company is like managing software, if you are a good developer you can be a good CEO or manager. We can use the software technologies to manage the company team. Although the context is quite different, they both solve the similar problems: How to manage dependency, how to make the team or software product more adaptable. 
This seems has a higher requirement for the manager, since I seldom see a manager who has a strong developer background. I really experienced how difficult it is to communicate with a non-technical background manager, it is really frustrating, and so hard to explain the issue, some time you have to translate it into an real life example to make it easy to understand. Think about it, it is so hard to let the manager to understand an issue, how could he actively find out the issue that developer himself does not aware? This is definitely an example of the Conway's law.

Thursday, December 2, 2010

Use your pain point to measure your incompetence

Corey Haines's presentation Software Craftsmanship, Beyond the Hype is interesting.
What I get most impressed is what he mentioned a simple way to measure your level of incompetence:
Picture your mind what's your ideal of programming, then picture what you do when deadline comes, the difference is how much you suck is.
In short, the difference between your ideal and your reality is the measuring of your suck.

I totally agree with what he said. Because right now it really applies my situation: I am thinking a long time to improve our build system,  I took the training of "Continuous Delivery" in Qcon, I know what is the ideal, but in reality it is really painful, and I don't know where to start, use what tools, it really measures my skills and knowledge for the build process is really low. I have to acknowledge this.

Here I would like to share my experience about measuring my incompetence:
Yesterday I tried to follow this article to improve our build script, we have 3 different environments: local test, stage box and product box. The first thing I need to do is put the parameters in the build script into 3 different property file, like: local.properties, stage.properties, and prod.properties. then in ant build.xml will read different property file based on the different server environment variables; what we need to do is in different build script, passing its own server environment variable, for example:
inside local.sh,  call ant -Dbuild.env=local
inside stage.sh,  call ant -Dbuild.env=stage

This's change is not hard, it did not take me a long time to do that. Then I noticed that in 3 different build script are quite duplicated: the major difference is the build.env value, others are pretty similar, can we refactor the shell script like refactoring the java code? Or can we apply the OO concept to the shell script? Till now I realized that I actually I did not do too much shell script programming: most of the time I just read and copy & past. Then when I googled, I just know that unix shell also support function, you can pass arguments, and even it can return values, this is cool! I did some test, it works!
But I need another feature: inside one script, call the methods in another script file.  Basically I want to put the common methods into another file, and so that 3 different script files call the methods in this common file; just like parent class and child class in java, which can make the script file much simple and reusable. After googling, I found the solution again, here I would like to post the sample code and show how it works.

In build-common.sh, define 3 functions:
 process_arguments()
 set_ant_env()
 call_ant()

buildlocal.sh

  . ./build-common.sh   # this is how to import another file
  set_ant_env
  process_arguments $*
  call_ant local

buildstage.sh
   . ./build-common.sh
  set_ant_env
  process_arguments $*
  call_ant stage

buildprod.sh
  . ./build-common.sh
  set_ant_env
  process_arguments $*
  call_ant local


Actually I still can improve the build script by passing an extra argument, but I am afraid we get used to use different shell to manage different environment, so I just leave it now.

The most important thing is how to import another shell into your shell script:

1.
. ./buld-common.sh

2. then you can the function, like calling the local function:
   set_ant_env

From this small improvement, I learned some thing about the unix shell, not bad. And more important what I learned is whenever you feel the pain, especially it will be painful over and over, do not just let it control you, you should to face it and think about how to solve it. Because it is good chance to measure you incompetence and a good chance for you to improve your skills.