# On Enterprise Ruby **URL:** \ **Category:** Rails\ **Created:** [March 27, 2007, 7:57am UTC](https://www.ruby-forum.com/t/on-enterprise-ruby/90267 "2007-03-27T07:57:47Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\ **Post date:** [March 27, 2007, 7:57am UTC](https://www.ruby-forum.com/t/on-enterprise-ruby/90267/1 "2007-03-27T07:57:47Z")
Q: What the hell is “Enterprise Ruby” anyway? A: Yet another ‘stack’ of crap so complex that any salesperson can use Steak and Strippers to easily sell it to management thanks to the bikeshedding effect. – 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 banks, telecoms, investment companies, newspapers… not just cool Web 2.0 startups anymore. Every middleware, operating system and IDE product vendor has a dynamic languages strategy. This is a new situation that Ruby community has to deal with. # Why do we care? Three major reasons: 1. 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 reason why you have to be working with Java or .NET today, unless you like it. 2. Community is changing. Ruby-talk / Rails-talk traffic is already bordering on insane, with a number of silly questions answered on page 10 of the Pickaxe steadily growing. It wasn’t like this four years ago, when I joined. 3. The threat that Zed S. refers to in the quote above. I call it “R2EE scenario”. 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 people working on Ruby gigs. Large enough to get funding and management support for initiatives like CruiseControl.rb and Rails continuous integration build. 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, though, it’s still the same straightforward approach to design and architecture that Ruby world is all about. # …and tomorrow Zed says: “Yet another ‘stack’ of crap so complex that any salesperson can use Steak and Strippers to easily sell it to management thanks to the bikeshedding effect.” Well, it may happen. Our cherished Ruby day jobs may yet turn into a nightmare of complexity and closed-sourced bloatware. Hopefully, we can at least have curly brackets instead of angled ones… Or maybe not. Agile movement, another Good Thing ™ that has recently gone mainstream, succeeded in rescuing many, in corporate IT and elsewhere, from the misery, which is heavyweight development process. This gives us hope. Maybe we can rescue ourselves and others from this other misery, which is bloated middleware? 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 do. 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. Open- sourced and not controlled by a middleware vendor. Rails. A framework that has been extracted from a real life application to 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 the right tone and serves as an example of what frameworks and libraries should look like in our brave new world. Experience. The history is repeated twice. First as a tragedy, and then a farce. It looks like both already happened. Now we can learn the lesson and not repeat it again. Culture. Before Ruby started turning mainstream, it was (to me, at least) this little quiet corner where one could escape the frustrations of one’s day job. Ivory tower architects who don’t code, complexity for the sake of 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 not all that sensitive to Steak and Strippers. But they have to make those decisions without solid, recent, firsthand user experience to rely on. So, the Bikeshedding Effect is the problem. Technology judgments are made by people who don’t code, relying on white papers, word of mouth and “common sense”. Ruby community can affect these things. After all, people in corporate IT read blogs and go to conferences, like everybody else. They hear you. I think, we should make it “common sense” that “enterprise Ruby stack” does not have bloated middleware within it, doesn’t need it, and doesn’t want it. 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, these words can become associated with bad things. And yes, staying away from the 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, $&#\* off!”, it’s “Enterprise, welcome! Bloatware, $&#\* off!” – Alexey V. Ruby programmer on corporate payroll cross-posted to Ruby-talk and RubyOnRails-talk