Tuesday, May 15, 2007

Code Generation In Action Is AWESOME

Blogged about this book being on the way from Amazon; now it's here.



I just started it and I'm on page 7, but it's very exciting. I'm absolutely going to recommend this book to anybody who wants to use Rails on enterprise-level projects. The criticism that Rails is simplistic for that problem space is easily adressed and overcome with the methods between page 0 and page 7. I'm not even kidding.

(Actually, it's not explicitly addressed - the book predates Rails, and may have significantly influenced its design - but if you see how he addresses enterprise-scale code bulk problems with code generation in a J2EE context, it's pretty easy to map that general strategy to Rails. He uses it to get around J2EE's ORM issues, the bulk and inconvenience of J2EE, and of course that's already handled in Rails with ActiveRecord - but you could just as easily use it to write a program in Ruby to write a Rails app for you. In fact his template-generation techniques are pretty similar to scaffolding, but there's no reason any Rails developer couldn't write their own scaffolding generator, and customize it for a particularly large, complex application, or for Ajax scaffolding rather than plain old vanilla scaffolding.)

Anybody who cares about Rails at all should get this book immediately.

I've always been a fan of code generation, having written Perl & Unix shell scripts to auto-generate Perl & Unix shell scripts since way back in the day, but this is some really awesome shit. It never occurred to me that it should be an architectural strategy.

I wish I had time to back all this enthusiasm up with a substantive review, but I'm going to be lucky if I even get the whole thing read before RailsConf. Long story short, though, anybody who admires Lisp's macros needs to realize that Lisp doesn't have a monopoly on code which writes code. You can write code which writes code in any language which runs on Unix, and if you're not doing that, you're doing things by hand which should be handled programmatically - like, for instance, BUILDING APPLICATIONS.

Seriously, this is a good book. It makes you wonder why in the hell you have to write has_and_belongs_to_many in Rails models and explicitly specify a habtm-style join table in the migrations when the proper approach is obviously to write a script to auto-generate all that boilerplate for you. It's ironic that so many people who love Rails never take the time to emulate its design in their coding practices. If you're building a gigantor-mungus enterprise app in Rails, you should only ever type the words has_and_belongs_to_many once - when you're writing the program that will thereafter do that typing for you. That may sound facile to the average Rails developer, but the average Rails developer works within a relatively small problem space. What about when you're on an enterprise project with 158 different tables? Do you really want to type has_one or belongs_to over 150 times? Do you really want to type out all those :foreign_key parameters by hand? Of course you don't.

This is a COOL book.

2 comments:

  1. Jack Herrington gave a Google TechTalk on code generation in August 2006, and it's online.

    The sample chapters from Code Generation were what actually got me into Ruby. =)

    ReplyDelete
  2. Oh, damn...you already linked to that video from the earlier post, I'm sorry.

    ReplyDelete

Note: Only a member of this blog may post a comment.