Rails, plugins, engines and the burden of generic solutions
This is inspired by a post by DHH last year, but recently un-earthed by myself. I’m good at that—finding things that everyone else already knows. The gist of the post is that generic solutions, like plugins, generators and such, are of decreasing value as the problem size gets bigger. For example, the tiny Textmate URL plugin is brilliant, as are some other things that extend the base model. Unfortunately, other bits and pieces that people have generously donated to the world are of less and less value as they try and solve bigger and bigger problems.
Let’s take for example role-based access control, or just a freaking login system. There are numerous options in Rails. I looked at all of them. They all suck in one way or another. Not because they don’t work—though that is true of some of them—but because they don’t work the way I need them to work for my situation. They also make all sorts of assumptions that are incompatible with my needs. What I have found useful is gazing at them, pulling out bits and pieces that are nice solutions to specific solutions.
Even more useful, though, is the idea of “recipes.” Take for example the Rails Recipes book that Chad Fowler is writing. Rather than try and give huge solutions to big problems, it solves lots of the little things that you need to piece together to make a system work. I took the login and authorization system in it, extended it, changed it, and made it fit my needs. Why? Because it was simple, clearly explained and I quickly understood how it could work for me.
Does this solution work for everyone? Nope. But sometimes what you need isn’t code, but a “recipe” for how to solve the problem—a roadmap.
This entry was posted at 9:52 am on 16 March 2006 and is filed under Programming, Ruby. You can follow any responses to this entry through the post-specific RSS 2.0 feed.
Both comments and pings are currently closed.
[...] Un lunatico minore triggered an insight. Ruby is more like the unix world: make little tools, make them do one thing, and make them do it good. Then leave it to others to chain those tools together. Very much like the Linux-world, where you have one program (eg. wget) that can talk HTTP. Then, you have another thingy that can do encryption (ssh). When you want to talk encrypted HTTP, you take wget, put ssh after it, and tadaa! Compare this with the Java-world. There are Java programs that can talk HTTP. If you want to talk encrypted HTTP, though, you have to be lucky that the original programmer thought of that, otherwise you’re out of luck. Said in a different way: all Java programmers have to invent the world for you, and they all have to solve all problems. [...]