Q: What the hell is “Enterprise Ruby” anyway?
A: Yet another ‘stack’ of crap so complex that any salesperson can use
and Strippers to easily sell it to management thanks to the bikeshedding
– Zed S. (author of Mongrel) at QCon 2007
Fellow Rubyists, Ruby is now mainstream.
Like it or not, we are there. Ruby applications are now developed for
telecoms, investment companies, newspapers… not just cool Web 2.0
anymore. Every middleware, operating system and IDE product vendor has a
dynamic languages strategy. This is a new situation that Ruby community
to deal with.
Why do we care?
Three major reasons:
It gives us all an opportunity to convert our love of Ruby into a day
job. If you are a good Ruby programmer in North America, there is no
why you have to be working with Java or .NET today, unless you like it.
Community is changing. Ruby-talk / Rails-talk traffic is already
bordering on insane, with a number of silly questions answered on page
the Pickaxe steadily growing. It wasn’t like this four years ago, when I
The threat that Zed S. refers to in the quote above. I call it
I love #1 and hate #2, but it’s #3 I want to talk about today.
Enterprise Ruby now
ThoughtWorks, the company I work for, has a fairly large number of
working on Ruby gigs. Large enough to get funding and management support
initiatives like CruiseControl.rb and Rails continuous integration
Large enough, in fact, that we can look at our own projects and say “OK,
this is what Ruby stack in the corporate IT world should look like”.
Turns out, it’s LAMP, bunch of Mongrels and Rails on x86 servers. Sounds
familiar, eh? OK, “enterprise” Ruby apps usually have to talk to Oracle,
instead of MySQL, they may have to authenticate against LDAP or
ActiveDirectory, some need messaging, reporting, or even the dreaded
WS-Deathstar [© DHH]. There are some special needs. Fundamentally,
it’s still the same straightforward approach to design and architecture
Ruby world is all about.
Zed says: “Yet another ‘stack’ of crap so complex that any salesperson
use Steak and Strippers to easily sell it to management thanks to the
Well, it may happen. Our cherished Ruby day jobs may yet turn into a
nightmare of complexity and closed-sourced bloatware. Hopefully, we can
least have curly brackets instead of angled ones…
Or maybe not. Agile movement, another Good Thing ™ that has recently
mainstream, succeeded in rescuing many, in corporate IT and elsewhere,
the misery, which is heavyweight development process. This gives us
Maybe we can rescue ourselves and others from this other misery, which
Or should we all seek refuge in “three men and a Web 2.0 site” shops? I
immensely respect the aforementioned men and their lifestyle choices.
Especially them whose company name starts with a number. Seriously, I
But this is not the only way.
I think, Ruby community has the opportunity, the power, and the duty to
prevent R2EE from happening.
What will help?
Ruby. Beautiful language that has been evolving for some years.
and not controlled by a middleware vendor.
Rails. A framework that has been extracted from a real life application
make development easier and faster. Not designed by a committee to solve
every problem of the world, including the imaginary ones. Again,
open-sourced and not controlled by a middleware vendor. Rails is not the
last framework you will ever need (which is a good thing!), but it sets
right tone and serves as an example of what frameworks and libraries
look like in our brave new world.
Experience. The history is repeated twice. First as a tragedy, and then
farce. It looks like both already happened. Now we can learn the lesson
not repeat it again.
Culture. Before Ruby started turning mainstream, it was (to me, at
this little quiet corner where one could escape the frustrations of
day job. Ivory tower architects who don’t code, complexity for the sake
complexity, design by committee, premature standardization - all those
things did not belong here. They were culturally unacceptable.
Let’s keep it this way!
Despite the popular impression, most corporate IT decision makers are
all that sensitive to Steak and Strippers. But they have to make those
decisions without solid, recent, firsthand user experience to rely on.
the Bikeshedding Effect is the problem. Technology judgments are made by
people who don’t code, relying on white papers, word of mouth and
sense”. Ruby community can affect these things. After all, people in
corporate IT read blogs and go to conferences, like everybody else. They
I think, we should make it “common sense” that “enterprise Ruby stack”
not have bloated middleware within it, doesn’t need it, and doesn’t want
Make it culturally unacceptable.
I want to ask one more question: why is the E-word anathema in this
community? Yes, people choose fancy words for self-description. Yes,
words can become associated with bad things. And yes, staying away from
whole thing is a possible lifestyle choice. Changing the game is another
equally valid choice, however. So, who or what are we, as a community,
sending those “$&#* off!” signals to?
I think, we should clarify our message. It’s not “Enterprise, $&#*
it’s “Enterprise, welcome! Bloatware, $&#* off!”
– Alexey V.
Ruby programmer on corporate payroll
cross-posted to Ruby-talk and RubyOnRails-talk