On Enterprise Ruby

ruby-talk
1

Q: What the hell is “Enterprise Ruby” anyway?
and Strippers to easily sell it to management thanks to the bikeshedding
effect.
– Zed Shaw (author of Mongrel) at QCon 2007

Fellow Rubyists, Ruby is now mainstream.

···

A: Yet another ‘stack’ of crap so complex that any salesperson can use Steak

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 Shaw 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 Verkhovsky
Ruby programmer on corporate payroll

cross-posted to Ruby-talk and RubyOnRails-talk

–~--~---------~–~----~------------~-------~–~----~
You received this message because you are subscribed to the Google Groups “Ruby on Rails: Talk” group.
To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~–~—

2

Alexey Verkhovsky wrote:

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?

The problem with the term "enterprise" is that it doesn't seem to have a clear, consistent definition as applied to software (or, indeed, to anything else), which, in a software-centric community, makes it pretty worthless as a description. As a result, it's not used within the community, and (speaking from my own point of view) we hear it from outside the community most often as "Ruby isn't ready for the enterprise," or "Ruby needs to support buzzword-feature-X to be taken seriously in the enterprise," so it's quite natural that a negative connotation should be attached - especially when those criticisms are unjustified.

Give us a rational, testable definition of "enterprise," and I think you'll find, negative connotations notwithstanding (and boy, do I love the term "enterprisey"), that the test will be passed without complaint. It's just the utterly nebulous terminology (and the woolly thinking that often seems to accompany it) which gets peoples' backs up.

I see this as quite orthogonal to the "enterprise -> bloatware" association, although that may well play a part, however justified or unjustified it is.

All strictly IMHO, of course.

···

--
Alex

3

As Yogi would say, "It's deja-vu all over again."

Back in the late-80s/early-90s Smalltalk had made a foothold in many
of those niches, particularly banking and investment, two hotbeds of
Smalltalk usage were Wall Street, and the Banhofstrasse in Zurich.
The driving factor was the need to do rapid application development
which was well suited to a dynamic object-oriented language. IBM even
had a mainframe Smalltalk for MVS and CICS.

I think what threw water on this was when Java came along, it was
available for no or low cost. The main Smalltalk vendors (IBM and
ParcPlace Digitalk) were still trying to make big bucks from license
fees. Java started building a large user base which eventually took
most of the wind out of Smalltalks sails. It's taken awhile for the
realization that Java just might not be dynamic enough to sink in.

So maybe Ruby has a good chance since it combines the dynamic nature
of languages like Smalltalk with an even more reasonable business
model than Java.

···

On 3/26/07, Alexey Verkhovsky <alexey.verkhovsky@gmail.com> wrote:

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.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

4

Call me a reactionary, but if we all just agree to ignore them they're bound to go away eventually.

Ellie

Eleanor McHugh
Games With Brains

···

On 27 Mar 2007, at 01:19, Alexey Verkhovsky wrote:

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.

----
raise ArgumentError unless @reality.responds_to? :reason

5

As soon as i see a want-ad in Cleveland,Ohio for a rails or ruby
programmer then
and only then will i call ruby 'mainstream'ed enough for even becoming
R2EE.
The biggest thing that is working against ruby now in corporate american
is the
not invented here syndrome..my boss still thinks that i'm only one of
three
people in the US that knows Ruby
  As a result, it's not used within the

···

community, and (speaking from my own point of view) we hear it from
outside the community most often as "Ruby isn't ready for the
enterprise," or "Ruby needs to support buzzword-feature-X to be taken
seriously in the enterprise," so it's quite natural that a negative

--
Posted via http://www.ruby-forum.com/\.

6

Alexey Verkhovsky wrote:

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?

The problem with the term "enterprise" is that it doesn't seem to have a clear, consistent definition as applied to software (or, indeed, to anything else), which, in a software-centric community, makes it pretty worthless as a description.

Um well, it's about as clear the expression "software that doesn't suck", which is intuitively understandable by anybody doing software I guess.

As a result, it's not used within the community, and (speaking from my own point of view) we hear it from outside the community most often as "Ruby isn't ready for the enterprise," or "Ruby needs to support buzzword-feature-X to be taken seriously in the enterprise," so it's quite natural that a negative connotation should be attached - especially when those criticisms are unjustified.

Enterprise means, neither the target nor the one delivering is a 3-man shop and it's not limited to a web-app. Enterprise means the problems you face when you're doing big, integrated apps.

Give us a rational, testable definition of "enterprise," and I think you'll find, negative connotations notwithstanding (and boy, do I love the term "enterprisey"), that the test will be passed without complaint. It's just the utterly nebulous terminology (and the woolly thinking that often seems to accompany it) which gets peoples' backs up.

Starting from the above definition and from my experience, enterprise means integrating accross system boundaries, and integrating means SOAP and XML (I am not arguing here that it can't be done differently). And SOAP and XML is where Ruby is not shining. Thus as a colorary "Ruby is not enterprise ready" as you say.
*t

···

On Tue, 27 Mar 2007, Alex Young wrote:

--
-----------------------------------------------------------
   Tomas Pospisek
   http://sourcepole.com - Linux & Open Source Solutions
-----------------------------------------------------------

7

Whenever someone says "not ready for the enterprise", the E-word usually
stands for "large companies whose core business is not software".

These places typically have post-technical managers in charge of strategic
IT decisions, lots of money to throw at IT problems (much more than a Web
2.0 startup), and a zoo of systems and applications, spanning the last 25
years of the history of computing. Some of those applications need to share
data and otherwise cooperate.

Rational enough? :slight_smile:

Alex

···

On 3/27/07, Alex Young <alex@blackkettle.org> wrote:

Give us a rational, testable definition of "enterprise,"

8

> banks, telecoms, investment companies, newspapers... Every middleware,
operating system and IDE product vendor
Call me a reactionary, but if we all just agree to ignore them they're
bound to go away eventually.

Nope. This is not going to happen.

Of Ruby and "the enterprise," which do you suppose is Mohammed and which

is the mountain
Neither of them should be the mountain.

there will be a variety of attempts to make Ruby acceptable to the

enterprise
Ruby *is* acceptable to "the enterprise". We were saying this since a year
and half ago, the difference now is that we have plenty of "enterprises" who
agree with this.

Alex

9

Image and market share aside (although those are important
considerations), what *real* limitations does Ruby have for large
scale apps ?

1. SOAP. This is a biggy. It's the top of my list of "real
hesitations before recommending Ruby". Large apps need to talk to
other apps. Often, this is via SOAP. Now, soap4r is buggy, poorly
documented, and worse of all, has very incomplete WSDL support.

2. Immaturity of Libraries. How many of the libraries that your
project depends on have version numbers < 1.0? 'Nuff said.

And there's also some serious cultural issues:

3. Clever code. Kent Beck says that when he uses a clever trick, he
feels bad, that's he wasn't capable of using a simple, well known
solution. Yet I see a lot of Rubyists - esp. Railers - who seem to
get a kick from programatically redefining a class or using
method_missing to avoid a comma somewhere. Come back to that 3 years
later, and good luck.

4. Arrogance. All those "databases are stupid, referential integrity
is for wimps, and CIOs should be fired" posts. Yuck! To me, the
rampant arrogance, combined with immaturity, is the greatest long term
risk to the health of Rails. Luckily, there's been a lot of
improvement here, with people recognizing that, yes, if you're
trusting your app with millions of dollars, you can't deal with it
like you do with your blog.

10

Call me a reactionary, but if we all just agree to ignore them
they're bound to go away eventually.

I think you're right. This is really something the programming
language ecosystem will handle automagically. If you look at the main
programming languages used at all the hip Web 2.0 startups, they're
using Lisp for user interface scripting and Smalltalk for their web
framework. The Smalltalk they're using runs on Unix and sometimes
quacks like Perl, and the Lisp they're using has this weird syntax
based on Java, but the long and the short of it is that quality wins.
Let the bloatware monkeys do what they want. It's their money to lose.

···

--
Giles Bowkett
http://www.gilesgoatboy.org

http://giles.tumblr.com/

11

Yeah, here in Ireland, the Team Lead asked if Ruby is so big, why aren't
we seeing it on job applications (for a Snr Java job). As if this implied
some universal truth. There was lots of bottom shelf answers I could
have used (it was a stupid comment) but what I said was:
"They are all gone to Google or contracting"

Having any significant experience with Ruby will change your perspective
on programming. 'Any old Java job' will cease to have any meaningful
attraction in a technical sense.

···

On 3/27/07, Dave Rose <bitdoger2@yahoo.com> wrote:

As soon as i see a want-ad in Cleveland,Ohio for a rails or ruby
programmer then
and only then will i call ruby 'mainstream'ed enough for even becoming
R2EE.
The biggest thing that is working against ruby now in corporate american
is the
not invented here syndrome..my boss still thinks that i'm only one of
three
people in the US that knows Ruby

12

Tomas Pospisek's Mailing Lists wrote:

Alexey Verkhovsky wrote:

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?

The problem with the term "enterprise" is that it doesn't seem to have a clear, consistent definition as applied to software (or, indeed, to anything else), which, in a software-centric community, makes it pretty worthless as a description.

Um well, it's about as clear the expression "software that doesn't suck", which is intuitively understandable by anybody doing software I guess.

Maybe to you. Not to me. I've seen "enterprise" used with any/all of the following connotations, among others:

- Integrating across system boundaries (your definition)
- Encompassing all business processes internally
- Used in a business environment
- Hot-deployable from a single central source across a network
- Having live failover capabilities
- Having good static analysis tools
- [3,4,5] 9's uptime

All of these are completely different, and refer to wildly disparate aspects of development, deployment and use.

This is my point, in a roundabout sort of way - while it's very easy to pick on any one of these and say "because Ruby doesn't meet this particular requirement out of the box, it's not worth looking at any further," that's to ignore the successes that people are having with Ruby in otherwise traditional environments, as alluded to by the OP.

<snip>

Starting from the above definition and from my experience, enterprise means integrating accross system boundaries, and integrating means SOAP and XML (I am not arguing here that it can't be done differently). And SOAP and XML is where Ruby is not shining. Thus as a colorary "Ruby is not enterprise ready" as you say.

Is that definition widely accepted? Is that what the term "enterprise" means in the expression "enterprise Ruby stack?" That's a honest question - it's not how I read it, but I'd like to hear your point of view.

···

On Tue, 27 Mar 2007, Alex Young wrote:

--
Alex

13

Alexey Verkhovsky wrote:

···

On 3/27/07, Alex Young <alex@blackkettle.org> wrote:

Give us a rational, testable definition of "enterprise,"

Whenever someone says "not ready for the enterprise", the E-word usually
stands for "large companies whose core business is not software".

These places typically have post-technical managers in charge of strategic
IT decisions, lots of money to throw at IT problems (much more than a Web
2.0 startup), and a zoo of systems and applications, spanning the last 25
years of the history of computing. Some of those applications need to share
data and otherwise cooperate.

Rational enough? :slight_smile:

Sure :slight_smile:

Defined like that, the statement "Ruby isn't ready for the enterprise" is just as easily reversed - "this enterprise isn't ready for Ruby." I say this because there certainly are enterprises using Ruby, and using it well, now - you're actually in a better position than me to know the truth of this.

--
Alex

14

Ruby has been acceptable to "enterprise" for a lot longer than that. I've been using it to deliver applications for banks, investment companies, mutual funds, construction companies, environmental management companies, and many others for 5 years. In most cases they didn't care one whit what the implementation language was so long as the project was delivered on time and on budget.

I never asked permission to start using Ruby in this way. I just started doing it and didn't worry about it, and in 5 years I can only count a single time where I ever lost work because I was going to do it in Ruby.

Most of the time businesses who's core business is not software just did not care about the details regarding how their needs were to be fulfilled. This was true before the Rails hype, and it's true now. We get almost every contract we go after, and they just don't care what the programming language is.

It's in the businesses and the business units where they do deal with software and software engineering regularly that they care. Those are the places that have taken a lot longer to break into with Ruby.

Kirk haines

···

On Wed, 28 Mar 2007, Alexey Verkhovsky wrote:

Ruby *is* acceptable to "the enterprise". We were saying this since a year
and half ago, the difference now is that we have plenty of "enterprises" who
agree with this.

15

About right, I'd say, except that _many_ / all of those application need to share data in my experience (utilising every single approach to sharing available: from shared file systems or registries, through to DBs and IP protocols, and no doubt lots of in house stuff). You've also got multiple businesses under one roof, all pulling in different directions and all with their own political and technical agendas and allegiances. And you've usually got some large and very poor code bases, and almost all of an application's lines will turn out to interconnection glue when you look at them.

:slight_smile: There are some interesting challenges here.

Cheers,
  Benj

···

On 27 Mar 2007, at 16:43, Alexey Verkhovsky wrote:

On 3/27/07, Alex Young <alex@blackkettle.org> wrote:

Give us a rational, testable definition of "enterprise,"

Whenever someone says "not ready for the enterprise", the E-word usually
stands for "large companies whose core business is not software".

These places typically have post-technical managers in charge of strategic
IT decisions, lots of money to throw at IT problems (much more than a Web
2.0 startup), and a zoo of systems and applications, spanning the last 25
years of the history of computing. Some of those applications need to share
data and otherwise cooperate.

16

2. Immaturity of Libraries. How many of the libraries that your
project depends on have version numbers < 1.0? 'Nuff said.

So, we'll all just add 1.0 to existing version numbers, and then the libraries will be mature.

3. Clever code. Kent Beck says that when he uses a clever trick, he
feels bad, that's he wasn't capable of using a simple, well known
solution. Yet I see a lot of Rubyists - esp. Railers - who seem to
get a kick from programatically redefining a class or using
method_missing to avoid a comma somewhere. Come back to that 3 years
later, and good luck.

Eh. There's a HUGE difference between leveraging language features such as open classes versus being clever just for the sake of being clever, and Ruby certainly doesn't have a corner on that market, either.

4. Arrogance. All those "databases are stupid, referential integrity
is for wimps, and CIOs should be fired" posts. Yuck! To me, the
rampant arrogance, combined with immaturity, is the greatest long term
risk to the health of Rails. Luckily, there's been a lot of

And, fortunately, there's a lot more to Ruby than the Rails world, too.

Kirk Haines

···

On Wed, 28 Mar 2007, S. Robert James wrote:

17

S. Robert James wrote:

Image and market share aside (although those are important
considerations), what *real* limitations does Ruby have for large
scale apps ?

1. SOAP. This is a biggy. It's the top of my list of "real
hesitations before recommending Ruby". Large apps need to talk to
other apps. Often, this is via SOAP. Now, soap4r is buggy, poorly
documented, and worse of all, has very incomplete WSDL support.

Who's working on this?

···

--
Alex

18

Image and market share aside (although those are important
considerations), what *real* limitations does Ruby have for large
scale apps ?

3. Clever code. Kent Beck says that when he uses a clever trick, he
feels bad, that's he wasn't capable of using a simple, well known
solution. Yet I see a lot of Rubyists - esp. Railers - who seem to
get a kick from programatically redefining a class or using
method_missing to avoid a comma somewhere. Come back to that 3 years
later, and good luck.

For the record, I hear that .NET version 3 is trying to implement open
classes, so on top of the responses already given, this is a completely moot
point

4. Arrogance. All those "databases are stupid, referential integrity

is for wimps, and CIOs should be fired" posts. Yuck! To me, the
rampant arrogance, combined with immaturity, is the greatest long term
risk to the health of Rails. Luckily, there's been a lot of
improvement here, with people recognizing that, yes, if you're
trusting your app with millions of dollars, you can't deal with it
like you do with your blog.

databases are stupid? RI is for wimps? Please, oh please show me posts that
say this! I would LOVE to talk to someone who seriously thinks this way!

What you probably saw, and heartily decided to misread was someone saying
*in a specific case* that a database was stupid because it added too much
complexity to a project.

As for arrogance, the only arrogance I see are people like you,
unfortunately. All you Java and C# people who have this odd fetish of trying
to discredit and bash any language that is even slightly different and for
some reason becoming popular. Dynamic Typing?! OH NOES You can't trust a
program without static typing! Open Classes! *feignt*. No, the arrogance is
on your side, the people like you who are hurting this industry with a
complete inability to adapt to, learn, and develop new ideas.

We like to call ourselves Pragmatic. Look into it, and if you haven't yet,
go buy Pragmatic Programmer and read it over and over again. You just may
learn something.

Tell me, have you even *tried* Ruby or Rails for more than a day? To be
honest, you're not saying a single thing new that I haven't seen on blog
posts or articles in the past 2 years of people who refuse to try Ruby
because it's different, it's new, and it's going to complicate their life
(how is of course never discussed, they are just so sure of it).

I'll say again, Ruby is most definitely ready for prime time and has been
for many years now. It's people like you who are hampering the inclusion of
this great language into the greater software world, mostly, I think,
because you people are afraid of change, deathly afraid. Well here's a news
flash: Software changes daily, and I really pity those people who have
missed out on this seemingly obvious fact.

Jason

···

On 3/27/07, S. Robert James <srobertjames@gmail.com> wrote:

19

Image and market share aside (although those are important
considerations), what *real* limitations does Ruby have for large
scale apps ?

1. SOAP. This is a biggy. It's the top of my list of "real
hesitations before recommending Ruby". Large apps need to talk to
other apps. Often, this is via SOAP. Now, soap4r is buggy, poorly
documented, and worse of all, has very incomplete WSDL support.

Tell me about a single library that has complete WSDL support. I've
been working with several Java libraries, .Net library, the customized
SAP Java library, and several other minor ones, and they all provide
some subset of WSDL spec and they all have interoperability problems.
soap4r has a very descent WSDL support as long as you don't go beyond
rpc/encoded style.

2. Immaturity of Libraries. How many of the libraries that your
project depends on have version numbers < 1.0? 'Nuff said.

You don't go too far with this attitude. I know several libraries with
version 0.x that have more features and less bugs than ones that carry
[1-9]+.x version tag.

And there's also some serious cultural issues:

3. Clever code. Kent Beck says that when he uses a clever trick, he
feels bad, that's he wasn't capable of using a simple, well known
solution. Yet I see a lot of Rubyists - esp. Railers - who seem to
get a kick from programatically redefining a class or using
method_missing to avoid a comma somewhere. Come back to that 3 years
later, and good luck.

I've no problem with a clever code. I've problem with an obscure code.

4. Arrogance. All those "databases are stupid, referential integrity
is for wimps, and CIOs should be fired" posts. Yuck! To me, the
rampant arrogance, combined with immaturity, is the greatest long term
risk to the health of Rails. Luckily, there's been a lot of
improvement here, with people recognizing that, yes, if you're
trusting your app with millions of dollars, you can't deal with it
like you do with your blog.

Take ebay.com as an example. They use neither the referential
integrity nor the database's transactional support. I guess from your
prospective this company is immature and arrogant.

···

On 3/27/07, S. Robert James <srobertjames@gmail.com> wrote:

--
Kent
---

20

1. SOAP. This is a biggy. It's the top of my list of "real
hesitations before recommending Ruby". Large apps need to talk to
other apps. Often, this is via SOAP. Now, soap4r is buggy, poorly
documented, and worse of all, has very incomplete WSDL support.

I have to agree on this one and it make me sad.

I've had to use this library three times in the last month and all three have been insanely painful. It is easier to just capture a well-formed request and fill it out as a template and this is tragic.

This has become the number one standard library I really want to see redone.

2. Immaturity of Libraries. How many of the libraries that your
project depends on have version numbers < 1.0? 'Nuff said.

And then you lost all of my respect...

James Edward Gray II

···

On Mar 27, 2007, at 8:05 PM, S. Robert James wrote: