On Enterprise Ruby

Ruby
41

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.

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.

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

42

On 29 Mar 2007, at 17:52, Philip H. wrote:

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.

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

43

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”

44

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.

45

On 3/28/07, Jason R. [email protected] 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? ;).

46

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

Luis

47

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

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 G. II [email protected]

48

On Fri, 30 Mar 2007, S. Robert J. 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 H.

49

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 N. [email protected]

50

On Mar 29, 2007, at 7:35 PM, S. Robert J. 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 G. II

51

On Fri, 2007-03-30 at 09:35 +0900, S. Robert J. 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

52

On 2007-03-30, S. Robert J. [email protected] 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 H.

53

On 3/30/07, Jeremy H. [email protected] wrote:

On 2007-03-30, S. Robert J. [email protected] 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.

54

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

55

On 3/31/07, Nasir K. [email protected] wrote:

  1. Slightly bigger consultancy/contracting work but mostly under $20k
    variety.
  2. Free software but paid support (again very small scales 2-5k support)
  3. 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

56

On 3/31/07, Nasir K. [email protected] wrote:

  1. For fun “scratch the itch” projects. [I belong to this one]

…

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

On 4/1/07, Pat M. [email protected] 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

58

S. Robert J. 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
59

Alexey V. wrote:

On 3/31/07, Nasir K. [email protected] 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.

  1. 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? :wink:

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/

60

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