Time to break it down

Posted by Tom on 2007-11-14

Over in the forums, finnhiggins is letting us know that keeping up with the all the changes to Hobo is a lot of work.

Hobo has some fantastic ideas that the rest of the Rails community could learn from, but keeping them all tied into a single package that is a very difficult dependency to track is making them pretty inaccessible to developers for the moment. Some more decoupling during development would be killer, IMHO.

“Can we have this in its own plugin?” is a very often heard request from the folk following Hobo. One that we’ve been saying no to.


The reason we’ve given is that there are a lot of interdependencies between the different parts of Hobo. Keeping all these parts separate will add an overhead to the development effort – possibly a significant overhead when you take into account all the extra management associated with having multiple sub-projects. And for what? There would be benefits for those who don’t want to use all of Hobo, but not so much for those who do. If you put it like that it doesn’t sound too tempting.

I’m going to say it plainly – we got it wrong.

James and I have just been chatting this over and come to the conclusion that the benefits of a collection of de-coupled Hobo “modules” far outweigh the costs:

  • The development overhead of keeping things separate is something we should be doing anyway. A monolithic code-base is just going to get increasingly unwieldy.

  • A collection of plugins will be more enticing to newcomers – it’s easier to adopt Hobo features one by one than to go the whole hog in one go and say “this one’s going to be a Hobo App”. (This exact point was made by a DRYML fan on the blog ages ago – hey, we get there in the end!)

  • It’s easier to document and to learn smaller plugins with well defined interfaces to each other.

  • We think and hope that smaller modules with more sharply defined purposes will be more likely to encourage quality contributions from all you ace developers waiting in the wings :-)

  • It’s easier to benefit from other projects. Say we decide that ez_where or Ambition are much better than Hobo’s (lame) find extensions, we can drop that plugin like a hot-coal and grab the new shiny one. In other words – Hobo needs to stop trying to be the best at too many things.

Yep - we’re doing this!

The truth is that the Hobo code-base is already fairly well structured, so there’s really not as much work involved as one might fear.

We’ve had a bit of a scribble on the white-board and the initial stab at a logical breakdown looks like this:

  • Model layer

  • General model extensions (Field Types?): Rich types, ‘fields do’ declaration, migration generator. (note that the migration generator needs the field declaration stuff, so it wouldn’t make sense in a plugin of its own)

  • Extensions to attribute assignment semantics.

  • def_scope

  • Permission system

  • Controller layer

  • Resource controller (hobo_model_controller), including web-methods

  • Data filters / search

  • Autocomplete support

  • View layer

  • DRYML + core tags

  • Rapid tag library

So that’s looking like a set of 9 plugins/gems. The idea is that any of these plugins can be used with or without any of the others, subject to some dependencies of course (Rapid probably won’t work too well without DRYML!)

We’ve pretty much convinced ourselves that this is the way forward now for Hobo. It’s going to have an impact on the documentation schedule, because it makes no sense at all to write docs before breaking things down. On the other hand, documenting Hobo in small chunks will make the job much easier and should mean you’ll get well documented parts of Hobo even sooner.

I’m planning to launch into this work pretty much immediately. Big change coming!