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.

No comments:

Post a Comment