Ryan Carson has published his latest interview with Rails creator: David Heinemeier Hansson, where David mentions, amongst other things, that good frameworks should be extractions and not just abstractions. This isn’t exactly the first time he’s mentioned it, but you might find it interesting to note that he singled out Rails components as being an obvious culprit of high-level component bloat, a part of Rails I’ve noticed that I’ve refactored away from on numerous occasions.
I often hear requests for plugins to help with multi-step forms, and after having just implemented a multi-step checkout process I can tell you it’s definitely not a straight-forward extraction. Just figuring out form validation and storage is hard enough–do you use multiple ActiveRecord classes, one ActiveRecord class or ActiveForm objects; do you store them in sessions, cookies or the database; do you store the objects themselves or just the attributes? I think there’s just too many opinions you’d either have to account for or ignore, and either way it’d probably be better off just documenting the different approaches than a code library to encapsulate them.
On the flip side there were a few great candidates for extractions on that same project, either because I’ve reused the exact same code from a previous project or intend to do so for my next one. These were mainly SimpleAuthorisation, app-wide HTTP password protection for the initial private stage of app development; and AccessibleFormBuilder, used to manage label tags and validation messages.
Spending less time abstracting is something I’m really striving for. The fundamentals are so thoroughly solved in Rails that it’s often not worth the time looking for the perfect plugin–just troop ahead and implement it how ever you can, abstracting and extracting the good bits only after you have it working successfully.
Tim Lucas
