El Kahuna

I keep losing my Hudson instance so I am making this my memory for what to do each time

• Proxy
  • export http_proxy=”<address of proxy from browser>”
• MySQL
  • Much of this for MySQL is stolen from Yet Another Blog. Thank you.
  • yum install mysql-server
  • /usr/bin/mysqladmin -u root password 'new-password'
  • /usr/bin/mysqladmin -u root -h <hostname> password 'new-password'
  • service mysqld start
  • mysql --user=root mysql
  • CREATE DATABASE <dbname>;
  • CREATE USER '<username>'@'%' IDENTIFIED BY 'some_pass';
  • GRANT ALL PRIVILEGES ON <dbname>.* to '<username>'@'%';
  • FLUSH PRIVILEGES;
  • SOURCE createdb.sql;
  • exit;
• Jetty
  • wget "http://dist.codehaus.org/jetty/jetty-6.1.22/jetty-6.1.22.zip"
  • unzip and put it on the attached volume
  • cd /usr/local
  • ln -s /mnt/installs/jetty-6.1.22 jetty
  • don't forget to create tools and static dirs and
  • don't forget to chmod all dirs allow hudson access
• Fitnesse
  • wget "http://www.fitnesse.org/fitnesse.jar?responder=releaseDownload&release=20100103"
  • rename the crap you get and put it where you want

  • cd /usr/local
  • ln -s /mnt/installs/fitnesse_20100103 fitnesse
  • don't forget to chmod all dirs allow hudson access
  • java -jar fitnesse
• Gradle
  • wget "http://dist.codehaus.org/gradle/gradle-0.8-all.zip"
  • unzip and put it on the attached volume
  • cd /usr/local
  • ln -s /mnt/installs/gradle-0.8 gradle
  • export GRADLE_HOME=/usr/local/gradle
  • Then go into Hudson and add the Gradle plug-in and define a gradle build task

I love this.  The 5 Whys.  I’ve used this technique for years without knowing that it had a name or that it was associated with Toyota, Kanban, etc.  It just seemed like the right response to (usually) very talented people who come into work and say something like, “We should use ‘X’”  My rule was that if I could get to the 5th why without hearing, “I don’t know, I thought it would be cool”, then it was probably an idea worth investing in.

Use this technique with your teammates (or yourself) the next time someone has a great idea.

Can it survive the 5 Whys?

Of late I have been thinking of goal setting.  It’s such a simple and yet powerful idea.  Where do I want to go?  I think I want to go there.  How do I get there?  I think I’ll go that way.  Answering these simple questions provides a framework for tracking progress (when are we going to get “there”) and reacting to change (what do you mean they closed the pass?).  And yet I find in both personal and professional settings that “we” tend to go day to day without making use of this simple concept.

A road trip in the near future got me to thinking about analogy between a road trip and the setting of goals.  And how this analogy applies to life, work, and the software development process (which *is* work - at least for me).  On a road trip how do we know when we are “there”?  Well, likely as not we have a destination (the Grand Canyon, Rome, the mall) and we are “there” when we get there.  We have achieved our goal.  And likely as not we were checking our progress along the way.  Did we reach Albuquerque by noon?  Are we ahead of schedule?  Are we behind?  Are we lost?  And likely as not it allows us to react to change (want to see the world’s largest pistachio?  how about going to Las Vegas instead?).

In application of agile methodologies in the software development there is a similar pattern.  There are many destinations/goals (tasks, stories, sprints, releases, …) to use to guide my progress.  Using Test Driven Development (or Design if you prefer) (TDD) I write my test first.  I know that I am “there” when the test passes.  As I write more tests (and make them pass), I’ll begin to know if I am going to make Albuquerque (or in this case completion of my task/story) by noon.  As my tasks and stories progress I’ll begin to know if I am ahead of schedule or behind.  I will know how I am progressing relative to my goals.  Using this knowledge I am in a better position to react to changes / problems / issues.

I’m not talking about Gantt chart style travel (if its Tuesday it must be Belgium) style travel.  Nor Gantt chart task management (I’m 80% done on that task - what is it again).  That isn’t fluid decision making based on changes in your environment.  That is not reacting to change.  That is not open and honest communication.  Maybe that is why setting quarterly / annual objectives set via the HR process seem so disingenuous.

Set yourself guide posts.  Use them to guide (not dominate) your journey.