David Bolton Strikes Again

Okay, I’m out of net contact (and thus svn repo contact) for the next three days — what better opportunity to try out Git? I hear about it constantly, and I’m starting to tear my hair out with waiting for svn commits.

But installing git and the git-svn tool on OS X appears to be problematic. Everyone seems to have their own magic voodoo to make it work. And in this regard, I’m no different. I had to blend 4 different recipes to get it going.

Here’s how I did it:

1. installed subversion and it’s language bindings from http://downloads.open.collab.net/binaries.html
2. built expat and git from source:
   
   curl -O http://surfnet.dl.sourceforge.net/sourceforge/expat/expat-2.0.1.tar.gz
   tar xvzf expat-2.0.1.tar.gz
   cd expat-2.0.1
   ./configure --prefix=/usr/local
   make
   sudo make install
   cd..

   curl -O http://kernel.org/pub/software/scm/git/git-1.5.4.tar.gz
tar xvzf git-1.5.4.tar.gz
cd git-1.5.4
./configure --prefix=/usr/local
make
sudo make install
cd ..


3. To remove an error about “can’t find SVN/Core.pm”, I added /usr/local/lib/svn-perl to $PERL5LIB.

And the litmus test is:

git-svn --version

Now, peepcode screencast in view, I start in the git world. How excitement.

Occasionally I find myself thinking with my Java hat on. Today was one such day. Looking at a legacy Order model from a Java system that we’re rebuilding in RoR, I noticed that it had two status columns — perfect for acts_as_state_machine! Or so I thought. But acts_as_state_machine isn’t really made to track multiple states on one object, and so I found myself with a little problem. How was I going to make this work?

Once I’d snapped out of thinking in the Java mould, it was obvious. These status fields could be broken out into separate models (with other relevant information, of course), each of which uses acts_as_state_machine. Thus I use the association mechanisms of Rails to help me, and work can keep trundling on nicely.

Then later this evening, reading the transcript for a Bruce Tate interview on the Ruby on Rails Podcast, I came across this relevant quote — describing similar thought processes:

I talked about the object-relational mappers that Java has, and all the inheritance modeling that you can do on the Java side, and trying to shoehorn my Java thought process into the Rails model. That took me to a sad place [smiling] and we don’t want to be in a sad place, we want to go to the happy place. So I learned to stretch the way that I think about various problems, like, for example, instead of trying to build a whole inheritance model, sometimes I’ll use polymorphic associations.

So instead of saying: “OK, everything on my website is content,” well, if I were to follow the Rails inheritance model, then everything would be crammed into a content table, and all the sub-classes of that would be with different properties. That’s clearly not a manageable solution. One of the things that I can do, though, is break out a small content descriptor that I can then add to a class with polymorphic associations.

Obie Fernandez recently launched his new services company, HashRocket, and initially it seems the 3-2-1 Launch service that promises to have a production app up and running in 3 days (with 3 weeks of requirements gathering) has gathered most of the attention. This is super, and a great manifestation of the productivity that us Rails people have become enamoured with.

But I think the other service is more interesting. Rescue Mission will save your Rails project from disaster, and it’s an idea that I don’t think has been talked about enough in the Rails community — what do we do if a project is not going to plan? Obie and Co will no doubt find steady work in this area.

I think this topic of project rescues naturally segues into an even more interesting area — maintaining existing Rails applications. To this point, a majority of Rails work has been actively building new applications. It’s the sort of work everyone enjoys. But we are coming up to a time where our older Rails apps are about three years old, and there’ll be a time soon when Rails apps need to be maintained by people who didn’t build them, people who have no history with the codebase.

How are we going to maintain these applications? Some of the ‘ancient’ (i.e. 18 month old!) Rails code I’ve seen (written by both myself and others) would make a modern Rails programmer shudder. Do we go through and rewrite this? Or should we just aim for test coverage and let old bad code lie. When we do decide refactoring is necessary, will our tools support us? And what about upgrading? Should we upgrade old apps to Rails 2? These questions are just the tip of the maintenance iceberg as well.

I don’t have answers, but my feeling is that Ruby will be a blessing and a curse when it comes to maintenance. More expressive code will be easier to maintain simply by having less plumbing and fewer lines of code, but on the other hand, our toolsets are nowhere near as advanced as a Java programmer’s toolkit, where maintenance is a way of life for many developers.