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.

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.

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.

Before I get into how this could be used, take a look at some examples in this sample gallery.

Ok, how does this help?

First thing to note is the above samples are all generated on the fly using the google chart api. If you look at the image url’s you’ll see that all of the chart parameters/colors/data/format etc… are provided on the url line to google. This is simple but you obviously don’t want to do this by hand. This is where you can get creative. Say you have a web based data source (say one that stores project story points by sprint), you could coax that web service to produce json or xml data to your static page which could run some embedded javascript to produce a url to the Google charts API. Not totally trivial but since there are no server side elements (other than your feed), you can do this with minimal infrastructure.

I experimented with a simple rails app that allowed us to record the story point progress and plans on a few sprints. One of the side effects is it could produce nice looking burn down charts by generating the necessary url to feed to google charts. I’ll try to post more about this later with some examples (sanitized).

Until you check in something that breaks (fails a test or worse yet, doesn’t compile). Then your little groupie is more like a stalker. Not only does it display a nasty web page (in shades of red) about the build YOU broke but it probably sent out a raft of emails about it. Pretty embarrassing.

This is actually a love hate thing. Every successful project I’ve worked (within the last 8 years) on has used continuous integration in one form or another. The pseuso standard in the industry has been Cruise Control. It is a pretty simple java based process and it can handle very complex setups. The big downside is it is a real big pain to setup.

Enter cruisecontrol rb.

What is cruise rb

This is essentially a cruise control written by the Thought Works guys in Ruby/Rails. The neato thing is this variant of cruise is a breeze to setup. Literally took 5 minutes. On our Redhat server it went something like this:

1. wget http://rubyforge.org/frs/download.php/27495/cruisecontrolrb-1.2.1.tgz
2. tar zxvf cruisecontrolrb-1.2.1.tgz
3. cd cruisecontrolrb-1.2.1
4. ./cruise add guide –url svn://some/repo/we/had/trunk
5. ./cruise start &
6. Add a redirector in apache to redirect */cruise/* to localhost:3333 (which is where cruise starts)
7. sudo /usr/sbin/httpd -k restart

That’s it. (almost… read about some of the slight config tweaks I needed to make below)

Too easy.

Notes / Next Steps

Note, this version of cruise is limited to svn only (other SCM’s are in the works, and there is a patch for at least git out there somewhere). This cruise can support java (or other) projects as well as long as you tell it how to build.

Some Minor Hacks – cruise rb is RoR after all…

I actually needed to do a simple set of changes to make cruise’s dashboard (it’s webapp) happy behind the apache redirector (the redirector is needed because 03 doesn’t have port 3333 open to the outside world).

1. add ActionController::AbstractRequest.relative_url_root = “/cruise” to the config/environment.rb file
2. modify the public/stylesheets/*.css files so url(/images/…) were replaced with url(/cruise/images/…) throughout.

Continous integration is like zentest for the entire team but can also do some really useful things like building team / project documentation.

In some recent projects, we were creating sites with a consistent  ‘intranet’ look and feel (mandated by the client’s web guidelines).  Doing this each time was a pain because of the need to rework the style sheets, layouts and copy in css images. Lots of  moving parts and hard for the some of the less experienced team members to get right without lots of help. I kept thinking, it would be great if there was some way to generate the boilerplate web menus for our apps so you can get up and running in minutes.  This is where taking a little time to create a generator and package it as an internal gem that each team member can install and use.

You have all used generators (scaffold, migration, model, etc…) in your rails projects. A generator is run from your project root directory and it builds or modifies your files to do something useful.  I’m a big fan of Ryan Bate’s nifty generators so I adopted that as the basis for incorporating the intranet styled menus I needed. This took some experimentation to get right but pretty soon I had a repeatable generator that mostly copied in images and tweaked the application.html.erb layout. To make this extendable, I developed a simplified menu approach driven from a single yml file.  In a future post, I’ll post more details about how this worked if there is interest.

The generator started life as a simple plugin to and was later converted easily into a gem.  The nice thing about rails is any gem that is a generator will automatically be available to you via script/generate.  I placed this gem on our team site with instructions and we all added it to our gem repositories.

Now if you wanted to quickly set up your new rails app to look like a real intranet page (for this client), you simply ran the generator in your new rails project and tweaked the config/menu.yml file.  This was great for prototyping or brainstorming in a meeting with customers.  From new rails app to internal app in seconds.

We used this gem to retrofit older apps into the desired look and feel and used it on several new apps and prototypes.  The team was digging it but a bigger buzz was created after I put together a screencast demonstrating how easy it was to use.  The rapid development ability of rails was lost on them until we added the ability to rapidly make stock apps look like their ‘client intranet’ apps.  We adopted this approach to generate different layouts so we could evaluate a site in one of three different ‘themes’.  Note, these themes were quite different and involved much more than simple css changes.  The genetators made this very easy to experiment with.

There are quite a few limitations to what a generator can and cannot do but that is what make them so easy to work with for tasks like this.