On Saturday 09 August 2008 10:20:27 brabuhr / gmail.com wrote:

> There have been some forays into leveraging more advantage of gems in rails:

"Gem-based development" sounds very close to what I meant -- but there doesn't 
seem to be much mention of how one might go about this as a _process_, only a 
few tools that might be useful.

Gem dependencies are nice, but all that does is encourage the use of gems 
rather than rolling your own functionality. I don't think this was ever a 
problem -- do people actually roll their own HTML parsers to use with Rails? 
At least the people I work with seem to be smart enough to use things like 
hpricot, or rfeedparser.

Gem plugins is a step in the right direction -- but it's still not 
particularly easy, compared to simply developing a plugin as an SVN external 
(or with piston) -- or simply adding another model to your existing app.

And if you look at the name, it seems very much like "gem plugins" are simply 
an approach to making plugins easier. It's still an approach of plugging 
something into an existing app.

I'm not sure what is needed, technologically, to make this happen -- maybe 
it's simply better scaffolding -- but I'm thinking that about the only thing 
that should be in the application is the routing. Everything else could be 
split off into re-usable components -- and at a fine granularity.

Of course, that's my opinion, and it runs directly contrary to the 37signals 
approach, which seems to be: Develop a monolithic app first, and don't 
abstract anything until you've repeated it at least three times. Re-usable 
components, in that model, are created by extracting them from an existing 
app.