Enterprise-Ruby Wish List by Francis Cianfrocca

Discussion in 'Ruby' started by zoat, Oct 4, 2006.

  1. zoat

    zoat Guest

    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.
    http://www.infoq.com/articles/Enterprise-Ruby-Wish-List
     
    zoat, Oct 4, 2006
    #1
    1. Advertising

  2. 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.
    > http://www.infoq.com/articles/Enterprise-Ruby-Wish-List
    >



    Why no mention of http://www.pragmaticprogrammer.com/titles/fr_eir/ ?

    --
    vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
     
    Joel VanderWerf, Oct 4, 2006
    #2
    1. Advertising

  3. Francis Cianfrocca wrote:
    > On 10/4/06, Joel VanderWerf <> 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.

    --
    vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
     
    Joel VanderWerf, Oct 4, 2006
    #3
  4. On 06-10-04, at 13:29, Francis Cianfrocca wrote:

    > On 10/4/06, Joel VanderWerf <> 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?


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

    --
    Jeremy Tregunna
     
    Jeremy Tregunna, Oct 4, 2006
    #4
  5. zoat

    Guest

    On Thu, 5 Oct 2006, Francis Cianfrocca 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
    --
    in order to be effective truth must penetrate like an arrow - and that is
    likely to hurt. -- wei wu wei
     
    , Oct 4, 2006
    #5
  6. On 10/4/06, Francis Cianfrocca <> wrote:
    > On 10/4/06, <> wrote:
    > >
    > > On Thu, 5 Oct 2006, Francis Cianfrocca wrote:
    > >
    > > > A small example: let's say you're a Java programmer accustomed to using

    > > JMS.

    <snip>
    > 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.
     
    Richard Conroy, Oct 4, 2006
    #6
  7. On Oct 4, 2006, at 10:59 AM, Francis Cianfrocca 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. ;-) 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.


    How about one written in Java which supports Ruby (and C, Python,
    PHP, Perl, C#, C++, Pike, as well as JMS)?

    1) Install and start ActiveMQ ( http://incubator.apache.org/activemq/ )

    2) 'gem install stomp' or http://svn.codehaus.org/stomp/ruby/trunk/

    3)
    --
    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!") }
    --

    4) See http://incubator.apache.org/activemq/stomp.html for more
    details on getting the exact behavior you want.

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

    6) See also Gozirra ( http://www.germane-software.com/software/Java/
    Gozirra/ ) for a lighter-weight messaging solution which supports the
    same spread of clients.

    -Brian
     
    Brian McCallister, Oct 5, 2006
    #7
  8. zoat

    Guest

    On Fri, 6 Oct 2006, Francis Cianfrocca wrote:

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


    please release early! i've been looking for such a beast to base a
    peer-to-peer clustering idea on...

    -a
    --
    in order to be effective truth must penetrate like an arrow - and that is
    likely to hurt. -- wei wu wei
     
    , Oct 5, 2006
    #8
  9. On Oct 5, 2006, at 11:32 AM, Francis Cianfrocca wrote:

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


    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, ( http://incubator.apache.org/projects/
    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
     
    Brian McCallister, Oct 5, 2006
    #9
  10. zoat

    snacktime Guest

    > How about one written in Java which supports Ruby (and C, Python,
    > PHP, Perl, C#, C++, Pike, as well as JMS)?
    >
    > 1) Install and start ActiveMQ ( http://incubator.apache.org/activemq/ )
    >
    > 2) '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.
     
    snacktime, Oct 6, 2006
    #10
  11. 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
     
    Brian McCallister, Oct 6, 2006
    #11
  12. --------------enigC6365D70D34BAE1367528BE4
    Content-Type: text/plain; charset=ISO-8859-1
    Content-Transfer-Encoding: quoted-printable

    Francis Cianfrocca 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 Vallner
    (Can we -finally- stop with the cheap shots at not-Ruby?)


    --------------enigC6365D70D34BAE1367528BE4
    Content-Type: application/pgp-signature; name="signature.asc"
    Content-Description: OpenPGP digital signature
    Content-Disposition: attachment; filename="signature.asc"

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (MingW32)

    iD8DBQFFJwlOy6MhrS8astoRAoLQAJ0Qs/8bQdn7qJJ9B2fU/Q6iWd+sVACffYjz
    YjjSjf+UPruK2RXCjU2abC8=
    =u+/B
    -----END PGP SIGNATURE-----

    --------------enigC6365D70D34BAE1367528BE4--
     
    David Vallner, Oct 7, 2006
    #12
  13. zoat

    snacktime Guest

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

    http://issues.apache.org/activemq/browse/AMQ-724
     
    snacktime, Oct 7, 2006
    #13
  14. On Oct 7, 2006, at 1:24 AM, snacktime wrote:

    > 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.
    >
    > http://issues.apache.org/activemq/browse/AMQ-724
    >


    Did you use 4.0.1 or the upcoming 4.0.2 (in RC and being voted on
    right now)? As the bug mentioned, it's been fixed in 4.0.2.

    The binaries being voted on:

    http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC4/maven1/
    incubator-activemq/distributions/

    -Brian
     
    Brian McCallister, Oct 7, 2006
    #14
  15. zoat

    Tim Uckun Guest

    I took a brief look at activemessaging. Looks great. Then I take a
    look at the roadmap and see that all the tickets logged are actually
    spam.

    No tickets logged, no milestones defined. I take a look at the
    timeline and it's all spam too so no code checked in either.

    To me this is one of the biggest frustrations of dealing with ruby and
    rails. The libraries are in a unfinished state and are not being
    worked on actively. Examples.

    The DBI ADO library is b0rked. The answer seems to be to use ODBC. I
    volunteered to work on the libraries if somebody could integrate my
    work with DBI but nobody is interested.

    I was excited about railscron and it's been dumped and replaced with
    something which has no cron functionality at all (threading problems
    from what I can gather).

    I tried various AGI implementation for asterisk and the same story.
    RAGI hasn't been touched in a year, the rubyforge forums questions go
    unanswered, patches that were submitted are not integrated, bugs not
    fixed, etc.

    I don't know what the answer is. I am grateful that talented people
    have dedicated their time and effort to create these libraries in the
    first place but it's very hard to tell which libraries are robust,
    which ones are abandoned, which ones are not being worked on because
    they are stable and don't need any more work.



    On 10/6/06, Brian McCallister <> wrote:
    > On Oct 4, 2006, at 10:59 AM, Francis Cianfrocca 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. ;-) 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.

    >
    > How about one written in Java which supports Ruby (and C, Python,
    > PHP, Perl, C#, C++, Pike, as well as JMS)?
    >
    > 1) Install and start ActiveMQ ( http://incubator.apache.org/activemq/ )
    >
    > 2) 'gem install stomp' or http://svn.codehaus.org/stomp/ruby/trunk/
    >
    > 3)
    > --
    > 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!") }
    > --
    >
    > 4) See http://incubator.apache.org/activemq/stomp.html for more
    > details on getting the exact behavior you want.
    >
    > 5) 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.
    >
    > 6) See also Gozirra ( http://www.germane-software.com/software/Java/
    > Gozirra/ ) for a lighter-weight messaging solution which supports the
    > same spread of clients.
    >
    > -Brian
    >
    >
    >
     
    Tim Uckun, Oct 8, 2006
    #15
  16. zoat

    Guest

    On Mon, 9 Oct 2006, Tim Uckun wrote:

    > The DBI ADO library is b0rked. The answer seems to be to use ODBC. I
    > volunteered to work on the libraries if somebody could integrate my
    > work with DBI but nobody is interested.


    I'm interested. Give me a good DBD::ADO and I'll get it added to DBI.


    Kirk Haines
     
    , Oct 8, 2006
    #16
  17. zoat

    Guest

    On Mon, 9 Oct 2006, Tim Uckun wrote:

    > I took a brief look at activemessaging. Looks great. Then I take a
    > look at the roadmap and see that all the tickets logged are actually
    > spam.
    >
    > No tickets logged, no milestones defined. I take a look at the
    > timeline and it's all spam too so no code checked in either.
    >
    > To me this is one of the biggest frustrations of dealing with ruby and
    > rails. The libraries are in a unfinished state and are not being
    > worked on actively. Examples.
    >
    > The DBI ADO library is b0rked. The answer seems to be to use ODBC. I
    > volunteered to work on the libraries if somebody could integrate my
    > work with DBI but nobody is interested.
    >
    > I was excited about railscron and it's been dumped and replaced with
    > something which has no cron functionality at all (threading problems
    > from what I can gather).
    >
    > I tried various AGI implementation for asterisk and the same story.
    > RAGI hasn't been touched in a year, the rubyforge forums questions go
    > unanswered, patches that were submitted are not integrated, bugs not
    > fixed, etc.
    >
    > I don't know what the answer is. I am grateful that talented people
    > have dedicated their time and effort to create these libraries in the
    > first place but it's very hard to tell which libraries are robust,
    > which ones are abandoned, which ones are not being worked on because
    > they are stable and don't need any more work.


    google 'rpa' (ruby production archive). for some reason, it didn't take off
    like gems - imho it was a powerful idea...

    cheers.

    -a
    --
    in order to be effective truth must penetrate like an arrow - and that is
    likely to hurt. -- wei wu wei
     
    , Oct 8, 2006
    #17
  18. zoat

    snacktime Guest

    On 10/7/06, Brian McCallister <> wrote:
    > On Oct 7, 2006, at 1:24 AM, snacktime wrote:
    >
    > > 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.
    > >
    > > http://issues.apache.org/activemq/browse/AMQ-724
    > >

    >
    > Did you use 4.0.1 or the upcoming 4.0.2 (in RC and being voted on
    > right now)? As the bug mentioned, it's been fixed in 4.0.2.
    >
    > The binaries being voted on:
    >
    > http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC4/maven1/
    > incubator-activemq/distributions/
    >


    I was using 4.0.1. But 4.0.2 is even worse. In addition to the bug
    still being there, activemq has a memory leak, at least on freebsd,
    and I ran into another bug where it hangs on shutdown. Definitely not
    ready for production use by my standards.

    Chris
     
    snacktime, Oct 13, 2006
    #18
  19. zoat

    Tim Uckun Guest

    I googled RPA and all I got was a wiki filled with spam.

    Here is a suggestion for people running wikis and trac.

    Use captcha.
     
    Tim Uckun, Oct 29, 2006
    #19
  20. On 10/29/06, Tim Uckun <> wrote:
    > I googled RPA and all I got was a wiki filled with spam.
    >
    > Here is a suggestion for people running wikis and trac.
    >
    > Use captcha.


    Better yet: don't. Better to use a Wiki that does other proactive
    stuff. Most CAPTCHA implementations wouldn't even remotely pass any
    disability testing.

    -austin
    --
    Austin Ziegler * * http://www.halostatue.ca/
    * * http://www.halostatue.ca/feed/
    *
     
    Austin Ziegler, Oct 30, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    13
    Views:
    739
    Valmont
    Aug 22, 2006
  2. dave

    [PROPOSAL] mailing list

    dave, Jun 8, 2005, in forum: Ruby
    Replies:
    18
    Views:
    201
    Austin Ziegler
    Jun 10, 2005
  3. Rodrigo Bermejo
    Replies:
    0
    Views:
    137
    Rodrigo Bermejo
    Jan 16, 2007
  4. Roger Pack

    ruby wish-list

    Roger Pack, Oct 15, 2007, in forum: Ruby
    Replies:
    170
    Views:
    1,296
    Roger Pack
    Oct 8, 2008
  5. Roger Pack
    Replies:
    3
    Views:
    128
    Roger Pack
    Dec 3, 2008
Loading...

Share This Page