Self As Team

As a space junkie, I frequent nasa.gov and astronomy picture of the day sites to marvel at the universe and our attempts to learn and explore it. One of my favorite sites is the venerable Heavens Above created and run by Chris Peat. If you haven’t checked it out, please do so soon as it gives lots of very useful information for observing satellites such as space shuttles, international space station (which is large enough to be seen in the daylight hours), Hubble space telescope and hundreds of others. If you register with the site or plug in your location, you can get lists of dates/times to see things like the space station fly overhead. My kids think I’m a genius because I’ve been known to look down at my watch during dinner and announce that the ISS is about to fly overhead – we all run outside and I start a countdown and poof – right on cue – a big bright star starts a lazy, 5 minute pass overhead. All thanks to Chris Peat’s great web site. You can even get star maps and ground track paths to help you get oriented.

I sometimes forget to check the site so I setup an automatic twitter feed to send me reminders. Was very easy to do …
Read the rest of this entry »

Been having lots of fun playing with different versions of ruby using the ruby_switcher shell trickery. This is works great but it broke my slightly tweaked version of mategem (a shortcut for pulling up the gem source in text mate using bash’s auto-complete trick). I am working on a more complete workaround but in the mean time, I needed to replace the gem environment gemdir command with the hardcoded path to my main ruby gems directory. This works for the nominal case again but the longer term solution is to have the auto complete work across multiple gem directories (again based on the gem environment as established by ruby switcher. I’ll post more when I figure it out (or remember to).

I’m setting up a new MacBook Pro and everything is going so much better than on a previous configuration (with a vendor supplied mac ports, etc…) but that is another story. I was setting up autotest and growl and ran into the same issues that I discovered with Leopard and growlnotify (see here, here and here). Anyway, none of the suggested configs worked at all this time around.

So I played around with the settings and ended up with this config which (knock on wood) seems to work pretty well.

I started with the following versions:

1. Leopard 10.5.8
2. ZenTest 4.1.4
3. Growl 1.1.6
4. autotest-growl gem 0.1.6
5. autotest-fsevent 0.1.1
6. autotest-rails 4.1.0

I didn’t need to make any adjustments to the growl configuration (via System Preferences) as reported in some solutions.

I added the following to the ~/.autotest file

require 'autotest/growl'
require 'autotest/fsevent'
Autotest::Growl::show_modified_files = true
Autotest::Growl::remote_notification = false
Autotest.add_hook :initialize do |at|
%w{.git .svn .hg .DS_Store ._* log}.each {|exception|at.add_exception(exception)}
end


I added some appropriately named images to the suggested ~/.autotest-growl directory per the really good (don’t skip over them, lots to learn if you have used an older config) instructions.

I then renamed the growlnotify app in /usr/local/bin to /usr/local/bin/growlnotify.wrapper (make sure it is executable with chmod if needed) and added the following wrapper (taken from Craig P Jolicoeu’s suggestion) as /usr/local/bin/growlnotify


#!/bin/bash
exec /usr/local/bin/growlnotify.wrapped -w "$@" &


That was it, autotest (and other apps) growl everytime now. Pretty easy (after I tried three or four other things that didn’t work). It seems the networked approaches with -H and other configs didn’t really work for me. The simplified wrapper seems to be all that is needed.

The other reported issues about growl not working if configured near the dock didn’t seem to cause me any issues (dock is on the bottom, growl is lower left).

Now my little robot friend (autotest) keeps me honest without fail.

Hope this helps.

I am sure I have my annoying ways of working but there is one thing that drives me nuts about some of the teams I’ve worked with.

Showing up to a meeting late.

The thing I like about scrum is even though we meet daily, we end up with fewer planned meetings (lots of ad-hoc white board sessions but they are very focused and productive). The thing I don’t like about scrum is having to wait for 5 or 10 minutes for the team to assemble. Sure there are things you can try and do to stop this behavior. I hate the idea of a ‘late jar’ where you contribute $1/minute you are late (donated to charity or food for the sprint review, etc) because if you agreed to attend a meeting at a certain time, then get there on time. On high performing teams, this isn’t as much of an issue. In some of the dysfunctional teams I’ve worked on, this is chronic.

I suggest that if you have 10AM meeting, then at 9:58, head over to the meeting rather than wait until 10:05 to go. Sure, you’ll wait around for 30 seconds or so but at least your team won’t be waiting on you.

Should be low-hanging fruit but is never seems to get picked.

Have spent the last few days working in Vista rather than OS X and it was looking fairly bleak until I spent some time updating my favorite editor. I have never liked full blown IDE’s (like Eclipse) for rails work. My first editor and still favorite is emacs. Textmate keeps my fingers humming on OS X but emacs is also running somewhere too. On windows, emacs is the main tool but I never really invested the time to update it (was running 21.x and 22.x versions which is quite old). So I spent some time this weekend to update it to 23.1.50 and add the ruby and rails modes. After some missteps, I finally have a fairly nice environment with pretty nice rails support. It even has snippets and quick navigation and refactoring (quickly create partials or helpers for example). I even have the ‘railscast’ theme so it looks pretty nice (at least what I’m used to on my Mac).

I can’t wait to go back to the Mac but at least I can be more productive while I’m slumming in Vista. The LONG delay on starting ruby processes (like tests, console, etc…) is sapping my will to live tho…

The info on rails and emacs on the web was pretty good but if someone wants my formula, I’ll be glad to post it.

Developing projects using ant is pretty easy and straight forward. One convention I like to follow is to organize each component in the system to have its own local build file. These builds can be aggregated by higher level builds very simply. This gives great flexibility while developing since you can build only what you need while working on it and yet you (or continuous integration) can easily perform a full build/test. If you have lots of similar components, your ant scripts might begin to have lots of duplication in them unless you start refactoring the common pieces into includes. In the old days (prior to ant 1.6), there wasn’t an obvious way to include fragements. While reviewing some open source projects back in 1995 I stumbled across the xml include technique (below) that I’ve used a few times. I had forgotten about this until I was recently asked to make some recommendations on an older project’s build approach.
Read the rest of this entry »

I while back needed to add an audit trail to an older project. I found the acts as audited plugin and put it into play and it is great. I added my models to it and added a way to review the audit trail online – all good – until…

I started added audits for my model associations. This went well until I wanted to audit a has and belongs to many (HABTM) association which as you know, doesn’t have to have a backing model (it simply relies on a join table that is named a particular way). Sigh. On a few HABTM as sociations, I actually had a model but our smarted myself (and followed an older web recipe) and created the model without id’s.  These associations do not work with this plugin.

No way to get there from here exept to convert HABTM to has many through. Further evidence why HABTM is shortcut that only leads to pain later if you need to extend the associations (like adding audit trails).

Avoid HABTM and your life will be better…. just imagine having to convert 10 or more association tables to models on a production system that has 1000’s of parent objects. You see any fun in that? The superstitious would call how HABTM handles join objects as ‘magic’ which isn’t really very accurate. It is simply a conventional shortcut. My big problem with it is the lack of flexibility it gives you – it is one of those box-canyon paradigms that is hard to get out of.

Oh and another note, if you add acts_as_audited to your project late in the game, you may run into problems with migrations if any migrations load data. The reason is a fresh checkout will bring the audit code which will perform audits even on migrated data and since early migrations don’t have the audit table loaded yet (it is a later migration), you can’t migrate data. Sure you can just do a rake db:schema:load but that will leave you without some of your migration data.

An easy solution is to simply rename the acts as audited migration to be your first migration (mung the date in the file name). This tricks the migration to run first and all should be fine… Note, this even works if you have previously migrated and then do an update to get this new ‘old’ migration – the migration still runs even though it is out of sequence thanks to the schema_migrations table which keeps up with what migrations have been run.

It is such a joy to have such great technologies at our fingertips. Ruby on Rails can be a fantastic productivity booster for projects but I often find I get huge benefits from it for simply exploring ideas or working up a quick functional prototype. By adding on things like customized generators that suit your client’s configuration and customizable menus, you can get to a workable prototype in record time (minutes to hours).

Part of the benefit of working with rails projects is the speed with which you can refactor and scaffold your way into different configurations. This can sometimes get you into trouble if an experiment or plugin doesn’t work. The best solution I’ve found for this is to ALWAYS initialized your fresh rails project into a git repository. This is like having infinite idea or skill mulligan’s for your project – a great safety net that let’s you go fast without fear.

Ryan Bates’s excellent screen cast series had a nice review of using git with rails and one of the commenters (Pete Yandell) offered a script to simplify life. This script sets up a standard rails project into git with the proper ignores. I modified the original script slightly to avoid placing .gitignore files into the empty directories within the .git directory. This is a harmless change but it seems cleaner to me. Here is my version of it:


#!/bin/sh
cat < .gitignore
log/*.log
tmp/**/*
db/*.sqlite3
coverage
doc/app/*
EOF
find . -type d -empty -exec touch {}/.gitignore \;
git init
echo "TODO - provide project README" > README
git add .
git commit -a -m "Initial import."

(here’s the gist)

This script works great (on OS X anyway) for setting up a project in git. This allows me to extend the ‘prototype’ from hours to multiple days if I need to without losing control or risking breaking the whole thing with a laps of concentration. I can create branches for experimental ideas and quickly switch back and forth. As long as my migrations are current and especially if I’m using data generators like populator, I can switch between branches to show my client a few different ideas or behaviors within seconds.

It is so great to have a (revisable) history of what I’ve done on a project. I can also quickly stash an idea away to work on it later. No matter what I do on the prototype, I can always recover back to some previous spot without much fuss or concern.

This technique works so well because it is all self contained within your rails directory and because it is such a low-overhead and fast approach.

The approach works like this:

1. rails some_new_project
2. cd some_new_project
3. git-rails
4. work on project for minutes or weeks with frequent checkins
5. create branches, rebase, squash commits, what ever – repeat previous steps
6. if want to keep it, move it to a public repo, if not simply rm -rf the entire directory…

Rails and git are really two powerful tools that have greatly revolutionized my personal work flow. I get to move quickly and with the assurance that I can undo any bad ideas. Infinite idea mulligans. I also get to practice using git even if my client is stuck on subversion (or worse). I highly recommend ALWAYS setting up your rails projects this way.

I’m a big believer in project transparency. I also like to utilize a hub and spoke model where a central project intranet site is available for the team to pull from rather than relying on emails or file stores. A simple wiki with a landing page is all you really need. Especially if your client is phobic about using hosted tools (e.g., Mingle/Campfile). With a team portal, keeping the content up to date should be automatic if the content is derived from your code. Wouldn’t it be nice if documentation about your project was always up to date? Wouldn’t it be even nicer if this documentation could include easy to digest change logs, list of todos/notes and other information? Well, this post will show you how easy it is to do just that.

Read the rest of this entry »

I was working on a scrum team that wanted to make our burn down charts available on our wiki. We tried the movable type chart plugins and they worked ok but we lacked the control we needed. I had heard about google charts and after looking into them I realized that we might be able to coax these to produce the charts we were missing. To my surprise this was quite easy to prototype but a little harder to do in practice. The nice thing about the google charts, is they are essentially image tags with specifically built URL’s. Constructing the URL can be a challenge but in general the performance we observed was great and the price (free) can’t be beat. You can read more about it here.

Read the rest of this entry »