David Bolton Strikes Again

Jamis Buck’s influence on Ruby and Rails development cannot be overestimated, so I was excited this morning to read that he has switched back from Textmate to Vim.  I made a similar switch about six weeks ago, though unlike Jamis I don’t have a long history with Vim (some casual use over ssh connections, essentially), so there’s been a lot of learning for me.  But too many things annoyed me about Textmate to overlook.  For instance, no window splitting!  In 2008!

I’ve been an editor floosy over the last couple of years though — for Ruby work I’ve had love affairs with Eclipse, Netbeans, Textmate and now Vim, but Vim looks like it’ll be the one to stick — so much power and configurability, and all straight from the keyboard.

Next, to try out Jamis’s fuzzy finder extension, and NERD tree (a project drawer mentioned in the comments of his blog post).

I stumbled over an annoying set of refactorings this morning.

First, the site Refactor My Code, which I’ve heard about and seen a couple of times but never really investigated.  One of the refactorings showed DRY taken a bit too literally, and in a way which I see all too often.  The original poster quite rightly wants to reduce his ActionMailer code, but how to do it?

The first responder has the best solution: refactor the core of the methods to a standard ’send mail’ method.  The only improvement I would make is to add a yield, thus allowing customisation via a block.  Using this method incurs one line per a new variation (though this could be more if a block is used).

The next two refactorings are not so good.  One uses define_method to add the methods dynamically.  The other uses method_missing.  In both cases this is misguided.

Using define_method is pointless: it results in marginally fewer lines of code than the previous solution, but  loses flexibility.

Use method_missing is the same — using Ruby tricks where none are needed.  Since templates need to be defined for each email to be sent, there’s no real advantage to automagically processing with method_missing, since you’ll know which emails are going to be sent by the templates you’ve defined.

The define_method refactoring was voted higher than the first refactoring, which only goes to prove that programmers often prefer being tricky to being practical.  Ruby programmers unfortunately take DRY to extremes, and this is just another case in point.

Just a quick note to say that The Rubyist is a fantastic read for anyone interested in modern Ruby development.  The magazine format lends itself to a mode and tone that blogs couldn’t reproduce — obviously the articles can’t cover what is happening right now, so instead we’re treated to more general software topics and ideas.

I’d love to have a hard copy, but it appears that is only an option in North America right now.

Anyway, highly recommended!

Subversion ignore commands drive me up the wall.  Git’s ignore is much easier to use, and consistent.

Here is the process I followed to add svn:ignore to a newly added directory that hadn’t yet been committed to the SVN repo.  The magic here is the “-N” flag on the add command, since that stops the recursive add (which would add the git directories), and you can then set svn:ignore afterwards.

svn add active_scaffold_list_filters/ -N
svn ps svn:ignore ".git" active_scaffold_list_filters/
svn add active_scaffold_list_filters/*
svn ci


Simon Brown has some excellent commentary on the idea of “Technical Project Managers”:

In essence, teams get in a Technical Project Manager because they think people in this role can successfully undertake the project management *and* architecture roles on the project. Unfortunately, my experience suggests that this isn’t always the most successful approach.

I’ve seen this several times over the years — one can do the Project Management, or one can do Architecture, but almost without fail it seems impossible to do both at the same time on a reasonably sized project.  One role will be more emphasised than the other, at the detriment of the background role.

Both these roles are of such importance that crossing concerns is asking for trouble.  At a pinch, I would recommend using part time resources for each role, rather than one resource trying to cover both roles.

Yesterday I hosted a small team of programmers in our first Crossroads sprint — a day of working through issues the dedicated team at the Crossroads charity in Hong Kong have found in using some of their internal systems.  The idea being that as Rails experts, we could donate some of our time each month to helping our friends in Hong Kong out.

Brad, Adam, Nick and myself (with Matt and Steve online at Crossroads to answer our questions) spent most of the day getting setup and working on some small issues, that gave us a good introduction to the system and the coding approach over at Crossroads, and coordinating with the ThoughtWorks product Mingle, we were able to resolve several issues.

All in all, a good start to our relationship with the Crossroads team.  It felt fulfilling to be donating our time to such a worthy cause.

Last month, I gave a talk at the Ruby on Rails Oceania (RORO) Sydney meeting about a charity that a good friend of mine is involved in, Crossroads.  They’re based in Hong Kong, and began moving their systems to Rails earlier this year.

So I’ve acted as a facilitator in trying to get a few local Rails developers together to do some charitable work for Crossroads.  Last night we had our first meeting, and all systems are GO!  We’ve decided provisionally to meet perhaps one day a month to work on some Crossroads code.  As Matt from Crossroads says, the help we can give is very highly leveraged in that every hour we volunteer is actually worth many times that, since we will be helping create more efficient systems for delivering tens of thousands of tonnes of charitable goods around the world each year.

This is the beginning, and I hope to report back in the future with news of some very good and useful work done for our friends in Hong Kong.

Great quote from Steve Yegge (in a much longer transcript on javascript):

JSON and XML are muscling in on each others’ space, and there are bristles, OK, and it’s so silly! It’s silly. The whole thing, right? I mean, XML is better if you have more text and fewer tags. And JSON is better if you have more tags and less text. Argh! I mean, come on, it’s that easy. But you know, there’s a big debate about it.

I’ve just made my first contribution on GitHub:

http://github.com/lightningdb/activescaffold/

Basically, I forked Active Scaffold, patched it to work with Rails 2.1, and committed back to GitHub, then sent out “pull” requests to others with related forks.  Now I’ve been notified that my patch has been pulled into other forks, excellent!

Getting my head around Git hasn’t been a priority, but even with my scant knowledge, this was relatively painless.  And colloborating on GitHub (even from my early impressions) just seems so natural and easy, even brilliant.

For a trip down memory lane, Jeff Atwood’s latest blog post about growing up with BASIC is a must read.

I grew up with GW-BASIC in the mid-80s.  I loved programming, and I actually made some reasonably complex software.  I’m convinced the accounting software I created was what landed me a scholarship to a prestigious private school here in Sydney.  Other software: a graphics program, many, many games (culminating in a loderunner type game with *a level designer*), a text editor and many others.  I even built an interpreted language *IN BASIC* (these days the cool kids would call it a DSL, and yes, I was crazy and young).