In all the recent talk (some would say hype) about the Ruby programming
language,relatively little has been said about Ruby’s usefulness in
enterprise development shops, but that is beginning to change. Francis
sidesteps the usual debate by turning the question around. What do
enterprise developers need, that they’re not getting from their tools
today? Based on the answers to that question, he looks at what Ruby
currently has to offer in the area of entrprise infrastructure.
zoat wrote:
In all the recent talk (some would say hype) about the Ruby programming
language,relatively little has been said about Ruby’s usefulness in
enterprise development shops, but that is beginning to change. Francis
sidesteps the usual debate by turning the question around. What do
enterprise developers need, that they’re not getting from their tools
today? Based on the answers to that question, he looks at what Ruby
currently has to offer in the area of entrprise infrastructure.
Enterprise-Ruby Wish List
Why no mention of http://www.pragmaticprogrammer.com/titles/fr_eir/ ?
On 10/4/06, Joel VanderWerf [email protected] wrote:
Why no mention of http://www.pragmaticprogrammer.com/titles/fr_eir/ ?
I’m guessing that you’re asking why I didn’t mention that book (or any
other) in my piece. The short answer is that the piece is a survey of
existing infrastructure, not a literature survey. A slightly longer
answer
is that I was trying to address needs that are faced by enterprise
developers in general, not needs faced specifically by Ruby
developers. I
think that enterprise software infrastructure can benefit from some new
components written in Ruby, irrespective of whether the development
language you subsequently choose for any given project is Java, Ruby, or
something else. As always, “use the best tool for the job,” and I’m
trying
to explore whether some new enterprise-class infrastructure can, and
should,
be written in Ruby rather than the default choice (Java).
A small example: let’s say you’re a Java programmer accustomed to using
JMS.
If I offered you a message-queueing product that supported JMS but was
“better” in measurable and compelling ways than what you use now (and
parenthetically happened to have been written in Ruby), wouldn’t you
want to
give it a try?
Francis C. wrote:
On 10/4/06, Joel VanderWerf [email protected] wrote:
Why no mention of http://www.pragmaticprogrammer.com/titles/fr_eir/ ?
Francis, you make good points in your reply (snipped). I was asking why
the blurb claimed that “relatively little has been said about Ruby’s
usefulness in enterprise development shops”, though there is a book on
the subject. I should have made clearer I was talking about the
ruby-talk posting, and not your article.
On 06-10-04, at 13:29, Francis C. wrote:
answer
to explore whether some new enterprise-class infrastructure can,
and should,
be written in Ruby rather than the default choice (Java).A small example: let’s say you’re a Java programmer accustomed to
using JMS.
If I offered you a message-queueing product that supported JMS but was
“better” in measurable and compelling ways than what you use now (and
parenthetically happened to have been written in Ruby), wouldn’t
you want to
give it a try?
Not necessarily. I mean, I have Ruby experience, but if I didn’t, I
don’t know as that I’d want to have to learn a new language to use a
new tool, even if it is “better” (unless it’s vastly “better” and not
just marginally).
On 10/4/06, Joel VanderWerf [email protected] wrote:
Francis, you make good points in your reply (snipped). I was asking why
the blurb claimed that “relatively little has been said about Ruby’s
usefulness in enterprise development shops”, though there is a book on
the subject. I should have made clearer I was talking about the
ruby-talk posting, and not your article.
Ah sorry, thanks for clarifying. I suppose the operative word in my
sentence
is “relatively.” There has started to be some good commentary on Ruby
for
enterprises (Dave T.’ recent talk also), but by volume it’s still
“relatively little.” Part of my goal in writing about this is to incite
more
conversation on the subject ;-). But again, I’ll stress my POV that Ruby
has
benefits to offer enterprises not just for people who already know and
love
to program in Ruby, but for many other people as well, and I think this
is a
very key point. Enterprise infrastructure could possibly be a new
“killer
application” (ouch, sorry to be trite) for Ruby.
On 10/4/06, Jeremy T. [email protected] wrote:
just marginally).
In my example, what I asked was: what if I offered you a
message-queueing
product that supported JMS … and happened to be written in Ruby.
No one’s asking you to learn a new language, that would be singularly
poor
marketing.My point with this example is that there are elements of
today’s application-support stack that could do with some major
improvements, and Ruby might be a good language to use for them.
On Thu, 5 Oct 2006, Francis C. wrote:
A small example: let’s say you’re a Java programmer accustomed to using JMS.
If I offered you a message-queueing product that supported JMS but was
“better” in measurable and compelling ways than what you use now (and
parenthetically happened to have been written in Ruby), wouldn’t you want to
give it a try?
well, i heard you can catch java - that’d scare me off.
-a
On 10/4/06, [email protected] [email protected] wrote:
well, i heard you can catch java - that’d scare me off.
Fair enough. But if you were the Java programmer in this example, would
you
be afraid you might catch ruby?
I wouldn’t mind being the cause of that infection
On 10/4/06, [email protected] [email protected] wrote:
well, i heard you can catch java - that’d scare me off.
AFAIK you cannot “catch” unless you “try”
Likewise
Robert
-a
–
in order to be effective truth must penetrate like an arrow - and that is
likely to hurt. – wei wu wei
–
Deux choses sont infinies : l’univers et la bêtise humaine ; en ce qui
concerne l’univers, je n’en ai pas acquis la certitude absolue.
- Albert Einstein
On 10/4/06, Francis C. [email protected] wrote:
On 10/4/06, [email protected] [email protected] wrote:
On Thu, 5 Oct 2006, Francis C. wrote:
A small example: let’s say you’re a Java programmer accustomed to using
JMS.
Fair enough. But if you were the Java programmer in this example, would you
be afraid you might catch ruby?
I wouldn’t mind being the cause of that infection
Well as one of those java programmers who is really seriously looking at
using Ruby for enterprise stuff, I am going to chime in here.
My initial opinion: Ruby is a really sweet sell to experienced Java
developers.
Its conceptually very easy to get productive quickly with it, and
‘Least Surprise’
is not blogger speak, but an actual real phenomenon. When half of the
recursion you have written in your professional career is in your first
non-toy
ruby program it shouldn’t work straight after you iron out the last
interpreter
error.
In fact any Java developer who has been with it from the start is in a
really
good position to evaluate Ruby with an open mind, as many of the topics
being
discussed about Ruby/Rails prime time readiness, are things that Java
developers have lived through.
Mostly enterprise developers are most interested in ‘can do anything’.
Which
more or less translates to:
- runs on anything
- talks to any system
- has good libraries
Certainly as an enterprise developer I have seen projects get
rewritten when a library
comes up short and can’t do the job. Its an area of concern for me that
the
enterprise libraries in Ruby have ‘Wet Paint’ signs on them.
Enterprise developers
expect the libraries to be there, and to just work as advertised. This
translates
to being complete, and proven in the field.
Depending on what kind of enterprise work you are doing, you are
generally
not that interested in performance if you are honest with yourself.
Certainly
a lot of the performance issues I see are due to poorly conceived
application
protocols between machines.
Enterprise developers care about tools and support ecosystems (possibly
a bit too much), and can’t understand why Ruby and Unicode generates
hundreds of heated arguments and very little quality technical
discussion.
They mightn’t even need it, but the fact that the debate is so heated is
worrying.
Theres also other little things that we worry about, like bundling Ruby
applications conveniently (doesn’t seem hard, unless you are talking
about
Rails), obfuscating source for support reasons (not IP-protection, but
to
protect against meddlers) and how cross platform it really is (counting
everything here, including 3rd party library portability, performance
parity
etc.) - I mean Rails for instance seems very unix biased.
Some other points - that Prag Prog book nailed it with ‘Low Ceremony
Distributed Apps’ btw. He totally described the enterprise app mentality
to distributed computing. I am warming to that book already - I have
climbed out the smoking ruins of two many big-M Middleware
solutions.
On Oct 4, 2006, at 10:59 AM, Francis C. wrote:
In my example, what I asked was: what if I offered you a message-
queueing
product that supported JMS … and happened to be written in
Ruby.
No one’s asking you to learn a new language, that would be
singularly poor
marketing.
elements of
today’s application-support stack that could do with some major
improvements, and Ruby might be a good language to use for them.
How about one written in Java which supports Ruby (and C, Python,
PHP, Perl, C#, C++, Pike, as well as JMS)?
-
Install and start ActiveMQ ( ActiveMQ )
-
‘gem install stomp’ or http://svn.codehaus.org/stomp/ruby/trunk/
–
require ‘stomp’
client = Stomp::Client.new(“username”, “password”, “localhost”,
61613)
client.subscribe(“/queue/SOMETHING.NIBBLE”) do |msg|
puts msg.body
end
client.join
require ‘stomp’
client = Stomp::Client.new(“username”, “password”, “localhost”,
61613)
10.times { client.send(“/queue/SOMETHING.NIBBLE”, “Hello!”) }
-
See ActiveMQ for more
details on getting the exact behavior you want. -
See http://dev.tirsen.com/trac/activemessaging for a framework
around it which is designed to play nicely with a certain popular web
framework in Ruby. -
See also Gozirra ( Germane-Software :: Software
Gozirra/ ) for a lighter-weight messaging solution which supports the
same spread of clients.
-Brian
On 10/5/06, Brian McCallister [email protected] wrote:
How about one written in Java which supports Ruby (and C, Python,
PHP, Perl, C#, C++, Pike, as well as JMS)?
Install and start ActiveMQ ( ActiveMQ )
‘gem install stomp’ or http://svn.codehaus.org/stomp/ruby/trunk/
Thanks, Brian. Actually I know a fair bit about ActiveMQ, and it’s the
main
reason why I think the Ruby world would do well to come up with a
competitor. You’re making a classical case for not re-inventing the
wheel,
but ActiveMQ is not the easiest product to use, nor is it particularly
graceful to require all manner of external bindings. It’s also the kind
of
committee-designed rather than use-case-driven effort you’d expect from
Java. Perhaps the obvious rejoinder is that a little pain never hurt
anyone,
but then the success of Rails suggests that there may be a market for a
better way. There are other, more widely-used solutions in the Java
world
that are commercial and very expensive. And there is also a very-well
funded
project afoot in the Java world (AMQP) which is intended to bring real
standardization to message-broker implementations and reduce costs. That
is
another strong clue that there is an unfilled gap. I’ve been working on
a
Ruby implementation of AMQP, which should be ready for early looks quite
shortly now.
I don’t know anything about Gozirra. Have you used it?
On Fri, 6 Oct 2006, Francis C. wrote:
project afoot in the Java world (AMQP) which is intended to bring real
standardization to message-broker implementations and reduce costs. That is
another strong clue that there is an unfilled gap. I’ve been working on a
Ruby implementation of AMQP, which should be ready for early looks quite
shortly now.
please release early! i’ve been looking for such a beast to base a
peer-to-peer clustering idea on…
-a
How about one written in Java which supports Ruby (and C, Python,
PHP, Perl, C#, C++, Pike, as well as JMS)?
Install and start ActiveMQ ( ActiveMQ )
‘gem install stomp’ or http://svn.codehaus.org/stomp/ruby/trunk/
Any plans on adding ssl connectivity to the ruby stomp gem? And has
it seen much production use? Hard to tell from the website.
On Oct 6, 2006, at 2:01 PM, snacktime wrote:
Any plans on adding ssl connectivity to the ruby stomp gem?
Certainly doable, I just have always used it on trusted networks 
Will prod it this week coming week, time allowing.
And has it seen much production use? Hard to tell from the website.
The Stomp connector for ActiveMQ has seen a lot of use (and has grown
the knobs that accompany).
The ruby connector has fewer war stories, but has served me and a
couple others fairly well so far. Not sure the extent of its use. The
protocol is downright trivial, so adjusting a client is pretty
straightforward (I think).
-Brian
On Oct 5, 2006, at 11:32 AM, Francis C. wrote:
Java.
How is it difficult to use?
curl -O http://…/incubator-activemq-4.0.2.tar.gz
tar -zxvf incubator-activemq-4.0.2.tar.gz
sh ./incubator-activemq-4.0.2/bin/activemq
At which point it is listening on port 61616 for its native protocol
and 61613 for stomp. I’ll post a screen cast demonstrating it, if you
like.
Would you mind expanding on “committee-designed” I am very curious
about what makes you say so. James and Hiram account most of the core
design, though quite a few other folks have been contributing.
In terms of external bindings, you mean the fact that we specced out
the Stomp transport protocol independently of ActiveMQ? If you look
through the stomp-dev archives you’ll see a lot of the same names as
on activemq-dev (plus a number of others). If I thought it added much
value I’ll happily roll an activemq gem so the names match
Perhaps the obvious rejoinder is that a little pain never hurt anyone,
but then the success of Rails suggests that there may be a market
for a
better way. There are other, more widely-used solutions in the Java
world
that are commercial and very expensive. And there is also a very-
well funded
project afoot in the Java world (AMQP) which is intended to bring real
standardization to message-broker implementations and reduce costs.
Do you mean Qpid, nee Blaze, ( All Incubator Projects By Status
qpid ) which is the code developed by JPMorgan, Redhat, and IONA
which is aiming to also join Apache? There are both Java and C++
based servers in the works, though the AMQP protocol is still
evolving behind closed doors 
AMQP is a very interesting protocol, it looks and feels, to me, more
like an API expressed in bytes over the wire than an app level
transport protocol because so much of the messaging server’s internal
capabilities are specced out as part of the wire protocol.
Interestingly, ActiveMQ was designed by a small group of folks with
lots of commercial messaging server experience, AMQP and Qpid by a
committee of vendors with one big customer 
The Java version does
use MINA though, which rocks!
That is another strong clue that there is an unfilled gap. I’ve
been working on a
Ruby implementation of AMQP, which should be ready for early looks
quite
shortly now.
Sweet! Make sure to mention it on the qpid dev list, they’ll be excited!
I don’t know anything about Gozirra. Have you used it?
Only early versions for mucking about purposes. It is basically a
minimal Stomp server implementation.
-Brian
Francis C. wrote:
ActiveMQ is not the easiest product to use, nor is it particularly
graceful to require all manner of external bindings. It’s also the kind of
committee-designed rather than use-case-driven effort you’d expect from
Java.
Apache software cumbersome and hard to use! Further in the news at nine:
Water is wet!
Sheesh.
The fact that specifically Apache developers have a penchant for writing
documentation on the edge of useless is rather known. (Witness the
Struts taglib docs. If you dare.) The fact more or less everything they
ship relies on two-three classes from commons-collections, requiring you
to download the horrendous iterators and stuff that was long since added
to the JDK from when that library came to be along, and commons-logging,
that I have yet to see do anything else than pointlessly wrap log4j or
JDK1.4 wrapping for the whole time an application exists also tells
books about what to expect in the ways of graceful dependencies.
And all that would be fine if you weren’t provably wrong, since despite
all flaws, Apache projects on the whole are still able to knock up
foolproof startup scripts. (Thanks to Brian McCallister for pointing
that out.)
Also, the overgeneralising vaguely to nag at [insert name of language
that isn’t Ruby here] doesn’t quite make me trust you more as a
technology journalist. It comes across as so much cheap
community-pandering.
If you have nothing good to say…
David V.
(Can we -finally- stop with the cheap shots at not-Ruby?)
On 10/6/06, David V. [email protected] wrote:
(snip)
Also, the overgeneralising vaguely to nag at [insert name of language
that isn’t Ruby here] doesn’t quite make me trust you more as a
technology journalist. It comes across as so much cheap
community-pandering.If you have nothing good to say…
David V.
(Can we -finally- stop with the cheap shots at not-Ruby?)
I stand by my point, expressed in the InfoQ piece, that there are
several
areas of enterprise infrastructure that are lacking in demonstrable
ways.
One of them is message-queueing, a core technology for application
integration that is, in my opinion, seriously underused due to lack of
real
understanding of its capabilities, and also challenges with the
available
tools. Most of the enabling technology used in message-oriented
integration
today is proprietary and not open, frighteningly expensive, and not
interoperable (by design). ActiveMQ is a very valuable, impressive, and
competent step in the direction of opening things up. I won’t try to
convince you or anyone else that ActiveMQ is not suitable for all uses,
and
that there is room for an alternative or two. Why should Rubyists
consider
creating such an alternative? Because of Ruby’s unique attributes, and
also
because of the stylistic conventions that have evolved in our community,
a
Ruby-based alternative may be better in measurable and meaningful ways,
particularly regarding ease of deployment, configurability, and
integration
with other technologies. One size doesn’t necessarily fit all.
What are my qualifications to say things about message-queueing that you
don’t want to hear? I’ve designed several commercial MQ systems over the
last ten years that have met with commercial success. I’ve designed both
wire protocols and APIs for MQ, going back long before JMS or Jabber
were
invented. I come to this forum to learn new things that I didn’t know
before. You haven’t said anything that qualifies so far, but I’m still
listening.
And has it seen much production use? Hard to tell from the website.
The Stomp connector for ActiveMQ has seen a lot of use (and has grown
the knobs that accompany).The ruby connector has fewer war stories, but has served me and a
couple others fairly well so far. Not sure the extent of its use. The
protocol is downright trivial, so adjusting a client is pretty
straightforward (I think).
Well, after playing around for only an hour I managed to run into this
bug in activemq when using stomp. Basically, if a consumer
disconnects in a bad way the broker can get stuck, and you’ll never
see your messages.