Forum: Ruby On Enterprise Ruby

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 Shaw (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 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 [(c) 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 (TM) 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

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.

 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

On Tue, 27 Mar 2007, Alex Young wrote:

> 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 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

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.

Tomas Pospisek's Mailing Lists wrote:
>>> 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.

Personally, any (and every) time I hear the word "enterprise software", 
I
can only think of enormously over-engineered, bloated software full of 
more
WTFs than you can shake a stick at, and if it actually does work is 
nothing
short of surprising. Ruby is the language us Pragmatic programmers use. 
The
whole point is to create only what you need and *exactly* what you need, 
no
more, no less, and Ruby lets us get there (at least for me) faster than 
any
other language I've ever used. If the resulting product after months of
development can be classified as "enterprise", well then more the 
better.

From personal experience, it would take me less time to write libraries 
that
don't exist if I'm doing major software development in Ruby than it 
would
take me to deal with other languages with tons of said libraries, just
because of the barriers intrinsic in said languages (I'm looking at you,
Java).

Ruby IS ready for prime time, and it has been for some time now. Just 
take a
look at www.revolutionhealth.com if you don't believe me. Mr AOL 
himself,
Steve Case, is starting up a new health insurance company with a massive 
web
portal written in Rails.

So yeah, no more of this "Ruby isn't ready" crap, because it is. And 
please,
stop using the word "enterprise". It may have started off good, but 
scores
and scores of bad code has tarnished the word.

Jason

Jason Roelofs wrote:
> So yeah, no more of this "Ruby isn't ready" crap, because it is. And 
> please,
> stop using the word "enterprise". It may have started off good, but scores
> and scores of bad code has tarnished the word.

A corollary to my other points: every time someone uses the word
"enterprise," there is almost certainly a better, more specific word for
what they actually mean.  A corollary to my corollary: almost every time
someone uses the word "enterprise" they are misunderstood, because the
listener assumes a larger subset of "enterprise" than the speaker 
intends.

On Mar 27, 2007, at 8:45 AM, Richard Conroy wrote:

>> three
> 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.
>

Agreed, Ruby has ruined my Sr. Java Engineer job.  I can't tell you how
many times I have thought, "Damn, this would look/work so much better if
I could use Ruby."

On 3/27/07, Alex Young <alex@blackkettle.org> wrote:
> 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.

You have also hit on another anti-Ruby point - that Ruby should be
able to fully replace Java/C/.Net i.e. it is a requirement for 
enterprisey
Ruby.

Nobody considers that you can mix and match technology - that
you could get a simple web app interface to whatever working with
Rails or Camping on top of your big Java or .NET application
server.

Its certainly not Sun, IBM or Microsoft that are getting upset that
you want to program the agile ends of your app in Ruby. You
want to run your Rails apps on top of Glassfish and avail of
5/6/7 nines uptime and global transactions? Now you can.

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? :)

Alex

On Tue, 27 Mar 2007, Alex Young wrote:

>>>> equally valid choice, however. So, who or what are we, as a community,
> Maybe to you.  Not to me.  I've seen "enterprise" used with any/all of the 
> All of these are completely different, and refer to wildly disparate aspects 
>> 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.

If you ask different people, they will tell you different things on why
software sucks or not. Same with enterprise sw. You can never know for
certain, but you can be pretty certain if it covers most bullet points
named in this thread.

*t, turning the irony potentiometer slightly down again ;-)

--

Alexey Verkhovsky wrote:
> 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? :)
Sure :-)

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.

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.

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.

--
Rick DeNatale

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

On 27 Mar 2007, at 01:19, Alexey Verkhovsky wrote:
> community has
> to deal with.

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
----
raise ArgumentError unless @reality.responds_to? :reason

On Wed, Mar 28, 2007 at 01:06:20AM +0900, Alex Young wrote:
> Alexey Verkhovsky wrote:
[...]
> >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.
[...]
> 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.

Of Ruby and "the enterprise," which do you suppose is Mohammed and which 
is
the mountain? Thinking in terms of enterprises needing to wise up and 
take
advantage of what Ruby/Rails has to offer for their own good is at best
altruistic and at worst self-delusional. There is an advantage to us, 
the
early adopters (where early is defined here as before it got enterprise
attention), hobbyists, and such, if we can get enterprises (i.e. the 
"large
companies whose core business is not software" mentioned above) to use
Ruby/Rails to a significant extent. That advantage is a wider range of
profit opportunities with greater job security.

I actually wrote a lot more after that paragraph, but it wound up being
just a tangent. Ultimately, it is in our best interests to bring Ruby to
the enterprise, and to do so actively rather than allowing someone who 
has
*their* best interests in mind do it for us. Rest assured, there will be 
a
variety of attempts to make Ruby acceptable to the enterprise, and some 
of
them probably won't smell too good. Passively hoping it won't happen or
hoping that someone else will get it right is the best way to let it go
wrong.

> Alex
--Greg

>
> > 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

Gregory Seidman wrote:
>>> data and otherwise cooperate.
> altruistic and at worst self-delusional. 
My point was that either viewpoint is as valid as the other, not to say
that I prefer either one.  It all depends on the specific enterprise in
question.

<snip>
> I actually wrote a lot more after that paragraph, but it wound up being
> just a tangent. Ultimately, it is in our best interests to bring Ruby to
> the enterprise, and to do so actively rather than allowing someone who has
> *their* best interests in mind do it for us. 
We can only do that if we know what is missing, and what is not good
enough.  I don't know if it's possible to do a good enough job of
filling in the gaps without actually being *in* the enterprise in
question, with first-hand knowledge of the problem at hand.

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.

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

Gregory Seidman wrote:

> them probably won't smell too good. Passively hoping it won't happen or
> hoping that someone else will get it right is the best way to let it go
> wrong.


Probably a community effort similar to the OSS initiative is in order?

--
Phillip "CynicalRyan" Gawlowski

Rule of Open-Source Programming #9:

Give me refactoring or give me death!

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

> 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.

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.

:-) There are some interesting challenges here.

Cheers,
  Benj

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.

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

> 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

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?

On 3/27/07, S. Robert James <srobertjames@gmail.com> wrote:
> 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 Wed, Mar 28, 2007 at 10:04:08PM +0900, Jason Roelofs wrote:
> >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

There are several things wrong with that statement. First, plans for 
.NET
have nothing to do with the relative merits of open classes, though I'd 
be
interested in reading about what is being planned concerning open 
classes
in .NET if you have a citation. Second, the issue is not open classes
themselves, which can be used effectively and appropriately, but as an
example (along with method_missing) of features that are often misused 
in
the name of cleverness and at the expense of maintainability.

> way!
http://www.loudthinking.com/arc/000516.html

It's a post by DHH, primary author of the "opinionated" Rails code. Like 
it
or not, he is a mover and shaker in the Ruby world and in this article 
he
says, "...I consider stored procedures and constraints vile and reckless
destroyers of coherence."

> 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.

The post I refer to above is based on the naive assumption that there is
such a thing as an "application database" that is distinct from an
"integration database." Anyone who has worked in any enterprise (defined 
as
a company whose core business is not software but has custom software
needs) knows that every database is an integration database. There will
eventually be a need for multiple applications to interact with the 
data.

The common response is that the application for which the database is 
its
"application database" is responsible for providing access to the data 
to
other applications via web services. This is a reinvention of the wheel,
not to mention an unnecessary layer of abstraction. RDBMSs have been
successfully, effectively, and efficiently supporting various
authentication and permission models for decades, not to mention 
supporting
constraints to maintain data integrity. It is foolish, not to mention
arrogant, to propose writing new, unproven code to implement what 
already
exists and works well.

> 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.

Wow, where did all that come from? Ruby is a great language, no 
question.
It is the right tool for many jobs. It could be better, though, and it
could be the right tool for more jobs with some improvements. Most of 
the
improvements I've seen suggested have to do with libraries (e.g. soap4r)
and coding discipline.

You aren't likely to see many people on this list suggesting that it 
needs
static typing, nor that open classes were inherently bad, nor even 
saying
that it needs to be more like C# or Java at the language level. The 
ability
to integrate with existing systems, however, requires a lot of library 
code
that does exist in the Java and C# world and is missing, buggy, and/or
inefficient in the Ruby world. When these libraries exist in an 
efficient
and dependable form enterprise adoption will be smoother and more 
common.

> 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).

Paragraphs like the two above go a long way toward explaining where
accusations of arrogance come from.

> 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.

I've learned and used dozens of languages. I've even enjoyed many of 
them,
including Ruby. I understand Ruby, JavaScript, C, C#, and C++ deeply (as
well as a few other mini-languages like awk and SQL). They each have 
their
strengths and weaknesses which make them each the right tool for certain
kinds of jobs. There is, unsurprisingly, some overlap. I've made money
programming some of the languages I know, including Ruby. I am currently
employed developing a large Ruby on Rails site, though not really for an
"enterprise" by the definition I gave above.

At a previous job, however, I was working in VB.NET on a massive 
internal,
mission-critical piece of software for a genuine "enterprise" using a 
vast
database (both in schema and in number of rows) that was accessed by
multiple applications. Every DB interaction was through stored 
procedures
for security and accountability reasons. They weren't using any
constraints, but they should have been and the lack of constraints 
resulted
in invalid and corrupt data that had to be detected and cleared manually 
on
a regular basis. Though one of the applications was a web app, Ruby on
Rails would have been the wrong tool. In fact, there was no part of the
massive system that would have been well-served by Ruby. It required too
much integration with existing systems in ways that Ruby doesn't do 
well.
Someday, perhaps, Ruby will have the library support to make it the 
right
tool, but not yet.

To be clear, I like Ruby and I think it is the right tool for a variety 
of
profitable work, including what I am doing now. By the same token, I 
think
that many of the problems that "enterprises" need to solve are 
ill-served
by Ruby and its present ecosystem (e.g. library support). I also think 
that
ecosystem can be improved, if we put in the time and effort to do so.

> Jason
--Greg

>
> http://www.loudthinking.com/arc/000516.html
>
> It's a post by DHH, primary author of the "opinionated" Rails code. Like
> it
> or not, he is a mover and shaker in the Ruby world and in this article he
> says, "...I consider stored procedures and constraints vile and reckless
> destroyers of coherence."


For the record, I do agree mostly with this blog post.  In terms of 
quick
development, and mostly in testability, stored procedures are evil. I've
worked in a complex integrated Oracle environment before, I'll just say 
that
it's something I will never, ever do again. Writing untestable code, of 
any
kind, is the one thing I absolutely HATE to do.

That said, I don't agree on the same stance for database referential
integrity. The database is in place to hold data and to make sure
relationships exist and are correct, and as such means have been put in
place (constraints, referential integrity) to help with this. I can very
easily see situations where multiple apps access the same database, so 
yes,
the database needs to know something about relationships (and this stuff
*can* be tested).

However, if your Rails application is the only one who will be hitting 
the
database, then constraints and RI can be used but are unnecessary.

Jason

> However, if your Rails application is the only one who will 
> be hitting the database, then constraints and RI can be used 
> but are unnecessary.

I disagree; if nothing else, they act as sanity tests for ActiveRecord
and your domain objects.

- donald

On 3/27/07, S. Robert James <srobertjames@gmail.com> 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.

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.

Wow, some excellent discussion has been generated.  I'd like to
clarify a few things, from my point of view:

1. I use Ruby extensively.  I use Rails extensively.  I'm using them
currently for a large health care project.  I've also used them
previously in other projects.  I think they're great.

2.  The problems I've raised are problems that I've encountered, in my
personal experience, with Ruby, and with Rails.  I'm pained by the
attitude that "Ruby (+-Rails) is perfect, and pointing out any
advantages of other platforms is heresy, subject to excommunication".
We need to be able to see our weaknesses in order to grow.  Isolation
brings stagnation.

3. Library maturity.  Some suggested that we could solve the maturity
problem by raising the version numbers.  I think that suggestion
expresses the problem that I'm raising better than I ever could.

3. Clever code: Please read what I wrote.  Dynamic typing is
wonderful.  Open classes can be used for good or evil.  But clever
code is always bad.  What's the difference? If you use the power of
the language to better convey the inherent patterns, that is good.
But, if you violate expectations, possibly saving a line or two, but
obscuring what's happening underneath, that is bad.  Some examples of
the latter are abusive method_missing use, and gratutitous runtime
redefinition of classes.

4. Databases.  I got two responses here.
* Some saying "yes, referential intergrity is indeed worthless".  I
doubt anyone saying this ever worked on a database that a) stores
millions of records b) must last many years or c) has very little
tolerance for failure.  Believe me, eBay has developed their own
database layer in Java, to handle massive scalability and
parallelization.  That's not the same thing as just haphazardly
throwing things into a "dumb, persistent hash".

* and some saying "no one ever said that".  To this, I not only offer
the posts cited by others, but the responses to this thread itself.  I
will point out that there's been a lot of community wide improvement
here - a lot of ignorance has been overcome.  DHH has certainly come
around on this, and it's to his credit.

Solutions?
Well, the cultural issues are the most dangerous - esp. the clever
code issue.  But, as an individual, you're not forced here.

I'd really, really, really like to see a decent soap4r - I'd even be
willing to sponsor.  Ruby prides itself - rightfully so - on how
"there is no step 3".  Here's one issue we're the opposite is true.
Consuming a Web Service with a complex WSDL is child's play in .NET,
but takes a lot of work to get right using soap4r. (Sometimes, I just
give up, and capture the XML off the wire, and template it!).

Perhaps JRuby will address these and library issues, but I think JRuby
is targeted more towards using Ruby to talk to Java, not enhancing
Ruby in its own right.  Perhaps over time, as more people adopt Ruby,
all of these issues will be addressed more...

How much work is it to get to a good soap4r?


Aur

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

> 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

S. Robert James wrote:
> Perhaps JRuby will address these and library issues, but I think JRuby
> is targeted more towards using Ruby to talk to Java, not enhancing
> Ruby in its own right.  Perhaps over time, as more people adopt Ruby,
> all of these issues will be addressed more...

Au contraire...JRuby aims to be the best Ruby possible on the JVM. If
that ultimately means we solve some issues (threading, performance,
unicode, scaling) before/better than the C implementation, so be it. But
it will still be Ruby, and we intend to run all the same apps unmodified
(or as close to unmodified as possible).

- Charlie

On Thu, 29 Mar 2007, Charles Oliver Nutter wrote:

> unmodified as possible).
I think Robert was hinting toward the idea that once JRuby is "usable"
(however that might be defined) it will have access to Java's mature
libraries, instead of using Ruby's XML, SOAP, ... (others?), which are 
not
as far as Java's.
*t

--

On Thu, 29 Mar 2007, SonOfLilit wrote:

> How much work is it to get to a good soap4r?

Look at the code. Last time I was debuging it I didn't stumble over a
single (!) line of comments - but maybe I wasn't looking well enough, or
my memory might be flawed. Anyway - I gave up.

And if you want to hack on SOAP you better know the specs (in addition 
to
the XML ones), which isn't a small bite either.

So I guess my answer is: it's not trivial.
*t

--

On 3/29/07, Tomas Pospisek's Mailing Lists <tpo2@sourcepole.ch> wrote:
> > scaling) before/better than the C implementation, so be it. But it will still
> > be Ruby, and we intend to run all the same apps unmodified (or as close to
> > unmodified as possible).
>
> I think Robert was hinting toward the idea that once JRuby is "usable"
> (however that might be defined) it will have access to Java's mature
> libraries, instead of using Ruby's XML, SOAP, ... (others?), which are not
> as far as Java's.
> *t

On JRuby 'usability': I was at a Spring (the Java DI framework) 
conference
recently where Spring global transaction support (i.e. really difficult 
to do,
even in Java, enterprisey stuff, go-to-jail-if-you-get-it-wrong etc. 
etc.) got
dependency injected into Java code, and then bubbled up the call stack
to Ruby code running on top of it. All through JRuby.

Good enough for me.

Also consider that the Java library space is not a mature superset of 
the
Ruby library space. Ruby brings a lot of interesting techniques to Java
developers. By using both you have *increased* the amount of tools
available to you.

Tomas Pospisek's Mailing Lists wrote:
> I think Robert was hinting toward the idea that once JRuby is "usable" 
> (however that might be defined) it will have access to Java's mature 
> libraries, instead of using Ruby's XML, SOAP, ... (others?), which are 
> not as far as Java's.
> *t

Sure, I understand that...and I agree with Richard that Ruby's libraries
also bring a few gems to the table as well. I just intended to dispel
any rumor that JRuby was "just about bringing Ruby to Java", since it is
also our goal to make as great a standalone Ruby as we can.

- Charlie

OK, I'd like to ask about technology problems. Specific obstacles that 
make
Ruby either less appealing, or not at all feasible on some corporate IT
projects.

So far, only messaging was mentioned on this thread.

The other thing people on ThoughtWorks Ruby projects complained about 
was
continuous integration. CruiseControl.rb is our solution to that 
problem.

We also hear some bitching about production deployment. I think with the
advent of Mongrel it's much less of an issue, but it's been a fast 
moving
target over the last couple of years, and new people find it hard to 
figure
out the current state of the art.

What else?

I think even messaging has become less and less of a detriment.
Reliable Messaging from Assaf Arkin gives you a solid pure-Ruby option
and stomp gives you the ability to talk to ActiveMQ servers (and
there's a new library that's being worked on for the new fangled
messaging dealies from Java).

All in all, I think messaging is less of a detriment.

Though, soap4r has made me kill small animals before out of
frustration.  That should probably be fixed, eh?  Google SoC anyone
(even though it's too late)? ;)

--Jeremy

On 3/29/07, Alexey Verkhovsky <alexey.verkhovsky@gmail.com> wrote:
> advent of Mongrel it's much less of an issue, but it's been a fast moving
> target over the last couple of years, and new people find it hard to figure
> out the current state of the art.
>
> What else?
>
> --
> Alex Verkhovsky
>


--
http://www.jeremymcanally.com/

My free Ruby e-book:
http://www.humblelittlerubybook.com/book/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

> 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.

> We also hear some bitching about production deployment. I think with the
> advent of Mongrel it's much less of an issue, but it's been a fast moving
> target over the last couple of years, and new people find it hard to figure
> out the current state of the art.

Personally I think this is a cop out.  If we're in the enterprise we've
got um... let's see... SANS, Firewalls, VPN's, Oracle, LDAP, blah blah
blah blah blah...

All of which are *trivial* to deploy?  No.  But people don't complain 
(or
maybe they do) about those...

I think the problem is that Ruby (and Rails) is hyped as being "easy" 
and
so people start thinking along the lines of "ftp my app to my website 
and
it will automatically run like most of my php apps do" instead of
something a bit more complex.

The sad thing is that in PHP's case it's only easy since most web hosts
include every module under the sun by default.  If you're on your own 
box,
suddenly all those little requirements (--with-gd, --with-png,
--with-jpeg, --with-freetype, --with-imap, etc.) suddenly lead to a 
*lot*
of dependency installing... which can be at least as hard as deploying a
Rails app.

<pointy hat on>
The problem with Ruby is that who do I sue if something goes wrong? 
Java,
I sue Sun.  .NET, I sue Microsoft.  Oracle, I sue Oracle.  But Ruby?
PostgreSQL?  Rails?  There's no one for me to sue so my a$$ isn't 
covered
so forget it.
</pointy hat off>

I'm partly joking, but at my last job they wouldn't let us run 
PostgreSQL
for this exact reason.  A year later I hear that they are using 
PostgreSQL
because it's more cost efficient to deploy.  Heh.  And PostgreSQL *has*
companies you can get official support from...

-philip

On 3/28/07, Jason Roelofs <jameskilton@gmail.com> wrote:
> For the record, I do agree mostly with this blog post.  In terms of quick
> development, and mostly in testability, stored procedures are evil.

It's also possible that the terming of things as "evil" doesn't help.
While there are clear and valid arguments against their use, stored
procedures aren't "evil" any more than any other string of characters
is[1].

Clearly we prefer to use an object wrapper rather than writing actual
SQL, but sometimes you *do* need to hand over a task to to system
which is most suited to performing it, and often that is the database
itself. You can certainly minimize the amount of raw SQL that you have
to type in the common cases, but eventually we're all going to hit a
task that takes hours via ActiveRecord, but only a few minutes in SQL,
right?

Stored procedures are just a way of making this logic available to
other non-Ruby application (see: integration database; see:
interoperability). That's all, really.

It's fine to be opinionated, but if you're going to say (or at least
imply) "Hey, relational people, yeah? I know you've got years of
computer science and information theory behind you, but you know what?
SQL BLOWS! What's that? You can prove that your query is optimal? Who
cares! Wooo! Ruby! Wooo!" then people who DO need to deal with stored
procedures, integration databases and other applications quickly going
to start ignoring *everything* you say, including the valid and useful
parts.

Clearly I'm exaggerating. The point is that to you can't convince
folks in "enterprisey" situations that they might see some benefit
from using Ruby as part of their process if you've already alienated
them; we can't go around declaring that everything we don't like is
"evil", or "just wrong", and so on. A little bit of understanding goes
a long way.


[1] That said, as I chant the darke incantation "CREATE PROCEDURE
"summoning" AS INSERT INTO my_house SELECT * FROM hell" why do I
suddenly smell fire and brimstone? ;).

On 29 Mar 2007, at 17:52, Philip Hallstrom wrote:
> <pointy hat on>
> The problem with Ruby is that who do I sue if something goes  
> wrong?  Java, I sue Sun.  .NET, I sue Microsoft.  Oracle, I sue  
> Oracle.  But Ruby? PostgreSQL?  Rails?  There's no one for me to  
> sue so my a$$ isn't covered so forget it.
> </pointy hat off>

I spent most of last year mired in this argument over Ruby. Needless
to say that project is now being written in "safe" J2EE, the delivery
deadline has been pushed back by 12-18 months, and I no longer work
for the company concerned. All because the business folks wanted to
be able to sue someone if things go wrong. And yes, they really are
that clueless that they think Sun can be put in the frame.


Ellie

Eleanor McHugh
Games With Brains
----
raise ArgumentError unless @reality.responds_to? :reason

Rumor has it that Microsoft is planning something big on Ruby, my guess 
is a
VM or a JRuby equivalent on .NET, better than the CLR bridge.

Overall the acceptance in enterprise world of Ruby is a good thing, it 
will
further enhance the library support and tooling overtime.
Yes there will be substandard programmers churn bloated code and its a
shame, but it is something you have to learn to ignore and live with.
Ruby community has come a long way on the path of open source and
programmer-focused initiatives. It is very unlikely that a heavy weight
corporate R2EEing coup could ever take place, short of that I feel safe 
as
long as I write clean code and am actually happy that more and more 
people
are talking about Ruby.

- Nasir

PS: In the recently held SD West conference, Joe  O'Brian had a talk on
"Ruby in the Enterprise"

> PS: In the recently held SD West conference, Joe  O'Brian had a talk on
> "Ruby in the Enterprise"

Joe O'Brien's company EdgeCase held a whole conference on Enterprise
Ruby (and Rails) in February. eRubyCon, or something like that.

erubycon was rescheduled to July 16-18.  You can see more details at
http://erubycon.com/

Luis
http://www.luisdelarosa.com

Really? You can't respect the idea that a library which not even the
developers feel comfortable calling "production ready", and which
hasn't stood the test of time, may very well have a high number of
bugs?  Esp. the kind that show up in nonstandard deployments or heavy
usages?

Now, a lot of people have written "there are plenty of buggy libraries
with high version numbers".  This is most certainly true.  But, to
invoke Aristotle:

(version > 1) --> high reliability IS NOT TRUE
But,
high reliability --> (version > 1) CAN STILL BE TRUE

I've used http-access2, soap4r, REXML, popen4, rubygems, etc., and the
Ruby interpreter itself, and eventually hit bugs in every single one
of these, at least on some platforms.  (Yes, I do search for bug
reports and file one if there isn't one already).  It's gotten to the
point where, if I'm faced with an inexplicable bug in my code, I make
sure to stop debugging my code and confirm that the library it is
using is itself bug free.  This is a far cry from where things should
be (cf. 'select() isn't broken'), and is a lot less than the QA
provided by J2EE or Microsoft, for that matter (there - I praised
Microsoft publicly - now I've definitely lost your respect :-) .)

QA aside, Ruby's library coverage leaves a lot to be desired.  It
seems there's a consens on soap4r.  What about HTTP accesss? cURL is
wonderful, and has great bindings to dozens of languages - but Ruby is
left with http-access2, which is very underpowered compared to cURL.
What about image processing?  Look at all the complaints of
reliability, memory leaks, and restarting daemons you get with
RMagick!  What about file compression?

Another point: error handling.  Half the core libraries provide very
cryptic error messages when something goes wrong.  Google the mailing
lists and you'll see lots of cries for help.  This is another area
which needs improvement.

On Mar 28, 10:07 pm, James Edward Gray II <j...@grayproductions.net>

I'm glad to hear that, Charlie.

My major point is about libraries: I think JRuby will open up a lot of
the industrial strength libraries to Ruby.  My concern, though, is
that JRuby will not focus on helping Rubyists do Ruby better, but
rather help Rubyists talk with Java apps.  I'm glad to hear that your
goals are larger than that.

I think the best - perhaps only - way to make something like this
happen is to make interfaces, which are fully in the Ruby spirit and
style - that harness Java's libs underneath.  Ruby style interfaces to
SOAP, to XML processing, to network protocols, to message passing,
etc. - with the elegance and succintness of Ruby, but powered by
Java's industrial strength mettle.

What do you say?

On Mar 29, 5:00 am, Charles Oliver Nutter <charles.nut...@sun.com>

On Fri, 30 Mar 2007, S. Robert James wrote:

> wonderful, and has great bindings to dozens of languages - but Ruby is
> left with http-access2, which is very underpowered compared to cURL.
> What about image processing?  Look at all the complaints of
> reliability, memory leaks, and restarting daemons you get with
> RMagick!  What about file compression?

So write something better.  Be the person who steps up and fills a void,
instead of the person who just whines about perceived voids.

> Another point: error handling.  Half the core libraries provide very
> cryptic error messages when something goes wrong.  Google the mailing
> lists and you'll see lots of cries for help.  This is another area
> which needs improvement.

So subscribe to ruby-core and provide patches.


Kirk Haines

On Fri, 2007-03-30 at 09:35 +0900, S. Robert James wrote:
> What about HTTP accesss? cURL is
> wonderful, and has great bindings to dozens of languages - but Ruby is
> left with http-access2, which is very underpowered compared to cURL.

Just FYI...

http://curb.rubyforge.org/

The current version is 0.1.2 though, so maybe it's not "ready" for you
=)

Best,
Andre

On Mar 29, 2007, at 7:35 PM, S. Robert James wrote:

> You can't respect the idea that a library which not even the
> developers feel comfortable calling "production ready", and which
> hasn't stood the test of time, may very well have a high number of
> bugs?

I'm disappointed by your gross generalization.  For example, you have
no idea how I think or choose version numbers.

When I first released FasterCSV, I wanted to be darn sure the parser
just worked. I didn't feel I could recommend people replace CSV with
FasterCSV without being very confident it worked.

To give myself that confidence, I ran FasterCSV and CSV over all the
real-world CSV data I could get my hands on, verifying they produced
the same results, except where I wanted FasterCSV to make different
choices.  I got some of the most clever people in Ruby to dream up
all the edge cases they could and I tried those too.  I actually got
a bug report to remove tests from FasterCSV at one point, because the
exhaustive coverage just took too long to run.

The parser worked, damn good, at version 0.1.0 though.  Trust me.
Only one bug has ever been found in FasterCSV's parser.  (There have
been plenty in my interface and shortcuts, of course.)

However, when I designed FasterCSV, I knew I wanted to add in all the
niceties I've always wished CSV would do for me.  So 0.1.0 was
already superior to CSV, in my opinion, but I decided I would call it
1.0.0 when it did everything I wanted.

People began using the library immediately and it was very popular
long before it hit 1.0.0.  It was not what I would call buggy software.

James Edward Gray II

S. Robert James wrote:
> style - that harness Java's libs underneath.  Ruby style interfaces to
> SOAP, to XML processing, to network protocols, to message passing,
> etc. - with the elegance and succintness of Ruby, but powered by
> Java's industrial strength mettle.
> 
> What do you say?

Absolutely! This is exactly the right thinking. I don't want JRuby to
become incompatible with Ruby any more than you all do, but there are a
lot of great libraries to be harnessed on the Java platform. Finding a
way to expose them for JRubyists while not diverging from the C Ruby
world is going to be a great challenge holding great promise.

One great example of a way to potentially harness cross-impl
capabilities would be a "good" GUI API that can be backed by a number of
libraries. JRBuilder for JRuby takes a Swing-based approach, but the DSL
it provides could probably be morphed into something more general 
purpose.

In general I think this is where the best cooperation is to be found,
making common APIs that work across implementations, allowing migration,
compatibility, and above all, a few solid standards everyone can follow.
Rails works on both Ruby and JRuby. So do RubyGems, Rake, RSpec, and now
I managed to get Mephisto working. But on JRuby they use different
libraries and a different VM. These are the kinds of cross-impl,
cross-platform success stories we should be focusing on for the future
of Ruby.

- Charlie

On 2007-03-30, S. Robert James <srobertjames@gmail.com> wrote:

> I've used http-access2, soap4r, REXML, popen4, rubygems, etc., and
> the Ruby interpreter itself, and eventually hit bugs in every single
> one of these, at least on some platforms.

I've used Oracle and hit bugs.  I guess that proves that Oracle isn't
enterprise ready.  (OK, it was Oracle 8, but still...)

Regards,

Jeremy Henty

On 3/30/07, Jeremy Henty <jeremy@chaos.org.uk> wrote:
> On 2007-03-30, S. Robert James <srobertjames@gmail.com> wrote:
>
> > I've used http-access2, soap4r, REXML, popen4, rubygems, etc., and
> > the Ruby interpreter itself, and eventually hit bugs in every single
> > one of these, at least on some platforms.
>
> I've used Oracle and hit bugs.  I guess that proves that Oracle isn't
> enterprise ready.  (OK, it was Oracle 8, but still...)

I don't think these are concerns that Robert has.  They're concerns
that the enterprise community as a whole has, he's just essentially
relaying them to us.

We're not discussing the legitimacy of these concerns.  For the most
part we believe they're just ill-conceived.  But the fact is that they
exist, and because they exist we can't explain them away with plenty
of reason.

Simply put, we can't address those concerns directly.  We must ask why
those concerns exist, whether we want to eliminate them, and why, if
not, we don't want to.

Ultimately does this come down to a question of developing culture.
Is the current Ruby culture willing to accept an enterprise culture in
the future?  Are we threatened by them?  Are we going to let them in
but still treat them as outsiders?  Should we try to exclude them
completely?

Bottom line is that curiosity will win over flimsy reasons every
time...so unless you have a damn good reason as to why we should
exclude the enterprise, they're going to make their way into our
culture.  We should do what we can to make them comfortable, and
hopefully guide them to a better way but understand when we can't.  If
we're afraid that our culture will be ruined by a tiny drop of poison,
we don't have a culture strong enough worth protecting.

I largely agree with Pat's comments.

Most of the people I know who are writing code in Ruby (or Rails) fall 
in 6
broad categories.

1. For fun "scratch the itch" projects. [I belong to this one]
2. Open source projects (Rubyforge/Sourceforge), again for fun or "in 
good
spirit"
3. For profit, but mostly small consultancy work for small "Mom and Pop"
enterprises.
4. Slightly bigger consultancy/contracting work but mostly under $20k
variety.
5. Free software but paid support (again very small scales 2-5k support)
6. Marginal scripting work inside big companies. (underground/stealth 
Ruby
activity)

I have three questions for Rubyists -

- Is this the trend they have seen in their enviornments too?

- If yes then is this the trend we want to continue to see going 
forward?

- Is a big sized company, like IBM selling "enterprise software" [think
Websphere] written in Ruby for a license and a price tag, an anathema?

Personally I think that as the popularity of Ruby grows and there are 
more
and more adopters, it is inevitable that there will be some enterprise 
spin
to it with big corporations coming with their own "Enterprise Edition"
software in Ruby, including the runtimes.
Rails has been a big differentiator and has broken the glass ceiling 
imposed
on other "scripting" languages. Now that Ruby is in limelight, I think
Rubyists owe it to themselves to capitalize on this business 
opportunity.

~nasir

On 3/31/07, Nasir Khan <rubylearner@gmail.com> wrote:
> 4. Slightly bigger consultancy/contracting work but mostly under $20k
> variety.
> 5. Free software but paid support (again very small scales 2-5k support)
> 6. Marginal scripting work inside big companies. (underground/stealth Ruby
> activity)

fwiw, my company doesn't fall in any of those categories.  We're a
"real" company building "real" software, and our software is built
entirely on Python and Rails.  Revenues are definitely over $20k and
hopefully waaaaaaay more than that.

Pat

On 3/31/07, Nasir Khan <rubylearner@gmail.com> wrote:
>
> 1. For fun "scratch the itch" projects. [I belong to this one]


...

6. Marginal scripting work inside big companies. (underground/stealth 
Ruby
> activity)



> - Is this the trend they have seen in their enviornments too?

No. ThoughtWorks is not a small consultancy, and we have several 
commercial
Ruby gigs sized 10 to 20 people. There is also this commercial product:
http://studios.thoughtworks.com/mingle-project-intelligence. It is 
written
in Ruby, too.

- Is a big sized company, like IBM selling "enterprise software" [think
> Websphere] written in Ruby for a license and a price tag, an anathema?


Something like WebSphere (huge clump of expensive closed-sourced 
middleware)
- yes, methinks. In my experience, 9 times out of 10, these things 
create a
lot more problems than they solve.

On 4/1/07, Pat Maddox <pergesu@gmail.com> wrote:
>
> fwiw, my company doesn't fall in any of those categories.  We're a
> "real" company building "real" software, and our software is built
> entirely on Python and Rails.  Revenues are definitely over $20k and
> hopefully waaaaaaay more than that.

Same here, except our combination is PHP and Rails. There is nothing
"toy" about what we are doing.

Then of course there is 37 Signals and ThoughtWorks.

Ryan

Alexey Verkhovsky wrote:
> On 3/31/07, Nasir Khan <rubylearner@gmail.com> wrote:
>>
>> 1. For fun "scratch the itch" projects. [I belong to this one]

I do that, and a little more. I don't have that many itches to scratch,
but Ruby made my life a little easier, but I want to, someday, make
money off my skills. Be it Ruby or application development in general.

> 
> 6. Marginal scripting work inside big companies. (underground/stealth Ruby
>> activity)

I'd say that depends on what "marginal" is. I'm pretty sure most big
companies (non-specialized in IT) don't really care how a particular job
is done, as long as it is done fast and reliable.
At least, as long as it is for internal use.

>> - Is this the trend they have seen in their enviornments too?
> 
> No. ThoughtWorks is not a small consultancy, and we have several commercial
> Ruby gigs sized 10 to 20 people. There is also this commercial product:
> http://studios.thoughtworks.com/mingle-project-intelligence. It is written
> in Ruby, too.

So, I'm not too much out of my mind, when I learn Ruby and want to make
a profit out of the skills I learn. That is good to know. May I cite
ThoughtWorks Studios when I'm applying for jobs as a reference of "Real
World Ruby" usage? ;)

> Something like WebSphere (huge clump of expensive closed-sourced 
> middleware)
> - yes, methinks. In my experience, 9 times out of 10, these things create a
> lot more problems than they solve.

Well, I'm doubting that it would be possible to write "real" bloatware
in Ruby, considering it's tendency to write in a test-driven and agile
manner. On the other hand, I've never seen a Ruby project of such a
dimension.


--
Phillip "CynicalRyan" Gawlowski
http://cynicalryan.110mb.com/

Eek! That was supposed to be My Special Law, _MY_ special law, I tell
you!

T/

On 4/1/07, Phillip Gawlowski <cmdjackryan@googlemail.com> wrote:
>
> I'm pretty sure most big
> companies (non-specialized in IT) don't really care how a particular job
> is done, as long as it is done fast and reliable.
> At least, as long as it is for internal use.


Actually, most do, and rightly so. After an initial release, a 
successful
application has to be maintained for the next 10 to 30 years. At some 
point
it becomes "legacy", which typically means "nobody really understands 
how
this stuff works anymore; reflecting new business changes is too slow 
and
too expensive, if at all possible". Some applications become legacy on 
day 1
of production. Some don't. Choice of technology plays a big part here.

Obscure languages become dead languages. To be stuck with an app written 
in
a dead language is bad in a number of very tangible ways. Well, more and
more people who make those decisions do not put Ruby in the obscure 
category
anymore.

May I cite ThoughtWorks Studios when I'm applying for jobs as a 
reference of
> "Real
> World Ruby" usage? ;)


There are better examples out there, considering that Studios haven't
released anything yet.

Well, I'm doubting that it would be possible to write "real" bloatware
> in Ruby, considering it's tendency to write in a test-driven and agile
> manner.


So far, people who choose Ruby are people who have a taste for tools and
practices. Alas, much software is created by people with no such taste, 
and
fragile code can be written code in any language.

Alexey Verkhovsky wrote:

> Actually, most do, and rightly so. After an initial release, a successful
> application has to be maintained for the next 10 to 30 years. At some point
> it becomes "legacy", which typically means "nobody really understands how
> this stuff works anymore; reflecting new business changes is too slow and
> too expensive, if at all possible". Some applications become legacy on 
> day 1
> of production. Some don't. Choice of technology plays a big part here.

Yes, I've experienced that first hand at my old employer. Whole sections
of code that have been forgotten, or that had no documentation anymore.

And because of a (self-inflicted) lock in with two vendors, together
with (really) a bad case of featuritis, the software became a nightmare.
And this is a SMB, mind, and not nearly in the same league as SAP or 
IBM.

> So far, people who choose Ruby are people who have a taste for tools and
> practices. Alas, much software is created by people with no such taste, and
> fragile code can be written code in any language.

As a newby to programming in general (sans two short episodes with C#
and PHP), I've noticed that Ruby makes it really easy to write good,
and, more importantly, readable code.
I can only speak for myself, but I'm drawn to write my code
object-oriented where it makes sense, and in as few lines as possible,
while still maintaining flexibility.

Of course, this avenue opens itself up slowly, as I learn more and more
about Ruby and programming practices in general. One month ago, I
wouldn't have grasped the point of Unit::Test, but now I'm taking a good
deep look at it, and I'm going to work with that, too. (It feels filthy
to write more than 10 lines of precedural code without tests.)

My .02EUR

--
Phillip "CynicalRyan" Gawlowski
http://cynicalryan.110mb.com/

Rule of Open-Source Programming #6:

The user is always right unless proven otherwise by the developer.

Il giorno 01/apr/07, alle ore 10:34, Pat Maddox ha scritto:

>> spirit"
>
> fwiw, my company doesn't fall in any of those categories.  We're a
> "real" company building "real" software, and our software is built
> entirely on Python and Rails.  Revenues are definitely over $20k and
> hopefully waaaaaaay more than that.

Mine too, I develop a web 2.0 project that already attracted
customers like TomTom and Havaianas - and bigger (and when I say
bigger I mean BIGGER) names that I'm not sure I can post right
now ... The project is http://www.zooppa.com, and Ruby has been
choosen over other technologies because we can react to changes in no
time.
Ruby is a real technology with real, measureable benefits over
competitors (and issues too of course, just actually we have more
benefits than everything else :)

   ngw

I suppose it is worth capturing in a "new" post, but...

We're now a year later ... from the original post by Alexey.  Rails is 
well on its way (even considering Twitter).

But, I'm not sure Ruby is any further along as an accepted Enterprise 
(regardless of your definition) technology.  Yes, there a slew of new 
books, blog posts, libraries, etc...but, what about adoption.

I would still assert that the job opportunities are the same...excluding 
Rails work.

The only interesting new developments here are with JRuby and IronRuby. 
That fact that both exist would indicate someone from the Enterprise 
would is interested.  JRuby probably more than IronRuby will bring the 
potential of true Enterprise development with Ruby to bear.

Anyone else care to play catch up?

Kit