Professional Web Applications Themes

choosing ruby? - Ruby

We are on the way to start a new project, a web application with a bunch of pages and the following features: *) users are maintained within a persistent repository (it could be as easy as a yaml file, we are talking about no more than 10 users); first page is a login page, of course *) through these pages (around 10, warning & error pages included) a user can invoke a transaction on a legacy system ==> we already have java code that encapsulate a transaction or we can rewrite it in ruby, it is a simple text based ...

  1. #1

    Default choosing ruby?

    We are on the way to start a new project, a web application with a bunch
    of pages and the following features:
    *) users are maintained within a persistent repository (it could be as
    easy as a yaml file, we are talking about no more than 10 users); first
    page is a login page, of course
    *) through these pages (around 10, warning & error pages included) a
    user can invoke a transaction on a legacy system ==> we already have
    java code that encapsulate a transaction or we can rewrite it in ruby,
    it is a simple text based protocol over sockets, just like a telnet session
    *) some transactions may not be invoked directly through the webapp, but
    they are scheduled instead for late night execution; of course, we can
    store these info in a yaml file too, there is no real need of a
    relational db
    *) we are talking initially about 2-3 transactions per day (not very
    hard, isnt'it?)

    We have an (almost-)ready framework in java for building webapps.
    Although that, we are asking ourselves if developing in ruby could be a
    better choice, mainly in terms of development speed. Infact, having
    around 2 or 3 transactions per day I don't think that application speed
    really matters (as long as users will not complain). We are just ruby
    newbies, but we like it. We are considering perl too, because in our
    team there's a perl fan, sponsoring mason for this project.

    We can develop:
    *) everything in java
    *) mix ruby (html-based frontend, maybe fastcgi or mod_ruby) and java
    (transaction invocation)
    *) everything in ruby,
    *) mix perl and java (we have tried a 30' spike with Inline::Java, it
    seems to work)
    *) everything in perl.

    If we mix ruby & java I was thinking about using rjni or rjava.

    One thing to take into account is that the application will be deployed
    on a Sun cluster (5500, I guess) and I am not sure that the customer
    will permit to compile the ruby interpreter there. They are quite
    "conservative", if you know what I mean.
    I know that this depends on os version, but may I expect to find in any
    "official" place an already compiled interpreter for Solaris /whatever/?
    This thing may affect negatively the whole choice. Unfortunately the
    customer is pretty rigid on things like that.

    Apart from that, development speed is the most important thing in this
    project: not very comfortable, but sometimes you have to do it. Even if,
    or because of we are quite in a rush we follow an XP process, applying
    the whole set of practices like TDD, continuous integration, small
    releases, etc. We don't want just to hack some code together. We are
    quite experienced in java, a lot less in ruby, and even less in perl,
    but with the latter we have at least an experienced person.

    I'm sharing this with you both for hearing your opinions and for letting
    you understand which kind of silly things may encourage or prevent ruby
    adoption.

    Thanks!
    Giuliano

    --
    If you want to send me an email in the address you have to write 'p',
    then a dot, followed by 'bossi' at 'quinary', another dot and 'com' at last

    Piergiuliano Guest

  2. #2

    Default Re: choosing ruby?


    "Piergiuliano Bossi" <it> schrieb im
    Newsbeitrag news:bv5moi$q2a$tiscalinet.it... 
    session 

    Considering all this I'd recommend to go for plain Java. Reasons:

    - you're quite proficient in Java

    - the JSP / Servlet framework is there and not really
    difficult to understand (IMHO) if you know web app
    basics (HTTP, HTML, control flow etc.) In your case
    that seems sufficient, no need for some fancy web
    app framework (don't use Struts)

    - not mixing languages means saving yourself a lot of effort and
    a huge source of bugs

    - you might not even be allowed to use Ruby
    (because of interpreter compilation)

    Next would be Ruby since it is IMHO more easily learned than Perl and
    there are webrick, eruby and others.

    I would not consider Perl since you don't benefit in this situation:
    Learning Ruby is easier and you don't need the additional speed that Perl
    exposes over Ruby for some applications.

    Kind regards

    robert

    Robert Guest

  3. #3

    Default Re: choosing ruby?

    On Tue, Jan 27, 2004 at 10:29:56PM +0900, Robert Klemme wrote: [/ref]

    I'm sorry to have to tell you that rjni is at best alpha :-(
    I've got a nearly feature-complete version in my local repository but I
    haven't released it, since I don't see myself spending much time on
    it in the near future, and I don't want to mislead anybody into
    thinking so.

    --
    _ _
    | |__ __ _| |_ ___ _ __ ___ __ _ _ __
    | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
    | |_) | (_| | |_\__ \ | | | | | (_| | | | |
    |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com

    The most important design issue... is the fact that Linux is supposed to
    be fun...
    -- Linus Torvalds at the First Dutch International Symposium on Linux

    Mauricio Guest

  4. #4

    Default Re: choosing ruby?


    I would recommend Ruby wherever appropriate, but in this case, I agree
    with Robert. His list of reasons was sound, I won't repeat them.

    The only thing I would disagree with in his recommendation, is that you
    *should* use an app framework - but not a fancy one. Struts is too
    bloated for small apps and too big a learning curve. But having
    something to easily do validation and unmarshalling of request
    parameters is useful.

    I'd use maverick with throwaway controllers and velocity instead of
    struts and jsp.

    http://mav.sourceforge.net

    -don


     

    Don Guest

  5. #5

    Default Re: choosing ruby?


    "Don Dwoske" <com> schrieb im Newsbeitrag
    news:com... 

    Thanks! :-)
     

    Exactly. Well, it depens on what you cann an "app framework". A servlet
    container does a lot of what one might expect from a framework. But,
    yeah, it should be lightweight.
     

    Exactly.
     

    With Java the Servlet Container (aka Tomcat) takes care of marshalling and
    unmarshalling data. Plus you need some library that can handle multipart
    POSTS (also available from apache.org).

    Validation is another story, but that's usually easy in a Servlet given
    the size of this webapp.
     

    I don't know maverick, but I'd like to comment on velocity. For the last
    webapp we did we evaluated velocity, too, but came to the conclusion that
    JSP is the better choice:

    - better integrated, all the nifty details are
    already handled by the servlet container, i.e.,
    you don't need to write your velocity servlet,
    you don't need to take care of modification
    checks for the templates

    - JSP's are compiled into classes

    - better performance (your mileage may vary)

    - with upcoming JSP spec 2.0 and Tomcat 5 support for
    expressions all over the page, which means quite
    convenient JSP coding (no need for
    <c:out value="${fancyExpression}"/> but instead
    ${fancyExpression}

    Kind regards

    robert


    Robert Guest

  6. #6

    Default Re: choosing ruby?

    ------_=_NextPart_001_01C3E4F9.27AA81C2
    Content-Type: text/plain; cht="iso-8859-1"

    I'll second that recommendation for using Maverick.
    I've created a PowerPoint presentation on using Maverick that I'd gladly
    share if you're interested.
     
    > than Perl and 
    > speed that Perl 
    >
    >[/ref]


    -------------------------------------------------------------------------------------
    A.G. Edwards & Sons' outgoing and incoming e-mails are electronically
    archived and subject to review and/or disclosure to someone other
    than the recipient.

    -------------------------------------------------------------------------------------


    ------_=_NextPart_001_01C3E4F9.27AA81C2--

    Volkmann, Guest

  7. #7

    Default rjni

    Mauricio FernŠndez <com> wrote in message news:<ei.uni-stuttgart.de>... [/ref]
    >
    > I'm sorry to have to tell you that rjni is at best alpha :-(
    > I've got a nearly feature-complete version in my local repository but I
    > haven't released it, since I don't see myself spending much time on
    > it in the near future, and I don't want to mislead anybody into
    > thinking so.[/ref]


    Please _do_ release it. Perhaps you won't be having time to work on
    it in the future, but others may want to work on it. In fact if you
    don't think you'll be having time to work on it that's all the more
    reason to 'release it into the wild' so that others can build upon
    your foundation. As I recall, rjni was something that came out of the
    2003 European Ruby conference and at the time there was a lot of
    excitement about it because it is a great way to introduce Ruby into
    Java shops - don't let it die! If you set rjni free it will have
    more of a chance to develop and mature than if it sits in your local
    repository. Perhaps the best thing you can do now to help rjni
    development is to write up some minimal doentation on what you have
    at this point (maybe use rdoc to speed things up).


    Phil
    Phil Guest

  8. #8

    Default Re: choosing ruby?


    There are lots of ways to build Java webapps, so perhaps we shouldn't
    continue this thread for too long.. :-)
     

    I was referring of the marshalling / unmarshalling into a Java Bean from
    request parameters (and translation into proper primitive types) not the
    http decoding part - should have been more clear.

    He'll also have to deal with page navigation and control flow, one thing
    which Maverick gives you at low cost. Using 'logical' page names in the
    application instead of hardcoded forwards is nice to have for small
    apps, a must for large ones. Struts offers the same thing.
     

    Yup, he might not need anything... if he does, consider
    http://formproc.sourceforge.net/
    http://jakarta.apache.org/commons/validator/
     

    one more negative for velocity
    1. more jsp books to help you learn

    For the plus' of Velocity:

    1. IMO, shoter learning curve (don't need book :-)
    2. smaller, cleaner syntax - expressions already looks like the
    JSP 2.0 expression syntax
    3. promotes good MVC architecture - whereas JSP can be used
    in very wrong ways
    4. negligible performance hit
    5. does one thing very well

    [more opinion on the velocity web site]

    I have disliked JSP's since the beginning, and using them extensively
    has only confirmed it. JSP 2.0 is however a vast improvement.


    com 

    I wouldn't mind seeing that... I'm thinking of presenting something
    myself ...










    Don Guest

  9. #9

    Default Re: rjni

    il 27 Jan 2004 10:07:13 -0800, com (Phil Tomson) ha
    scritto::

     

    can I say that I agree?
    I wonder if the maintainer of rjava would like to adopt it, cause he
    already planned a jni bridge.
    gabriele Guest

  10. #10

    Default Re: rjni

    On Wed, Jan 28, 2004 at 03:09:56AM +0900, Phil Tomson wrote: 

    I have to confess it's not a matter of time -- it's just that I'm facing
    the need to rewrite it all in C (for performance) and frankly that's no
    fun :-|

    I'll clean it a bit, add some docs and release it as another technology
    preview.

    --
    _ _
    | |__ __ _| |_ ___ _ __ ___ __ _ _ __
    | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
    | |_) | (_| | |_\__ \ | | | | | (_| | | | |
    |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com

    Because I don't need to worry about finances I can ignore Microsoft
    and take over the (computing) world from the grassroots.
    -- Linus Torvalds


    Mauricio Guest

  11. #11

    Default Re: choosing ruby?

    Mauricio FernŠndez wrote: [/ref]
    >
    >
    > I'm sorry to have to tell you that rjni is at best alpha :-(
    > I've got a nearly feature-complete version in my local repository but I
    > haven't released it, since I don't see myself spending much time on
    > it in the near future, and I don't want to mislead anybody into
    > thinking so.[/ref]

    If you release rjni you will be granted 3 wishes ;-)



    Joel Guest

  12. #12

    Default Re: choosing ruby?

    Release the code!! If you don't have time others may. I may. =)

    Zach

    -----Original Message-----
    From: Mauricio Fernandez [mailto:com]
    Sent: Tuesday, January 27, 2004 8:52 AM
    To: ruby-talk ML
    Subject: Re: choosing ruby?


    On Tue, Jan 27, 2004 at 10:29:56PM +0900, Robert Klemme wrote: [/ref]

    I'm sorry to have to tell you that rjni is at best alpha :-(
    I've got a nearly feature-complete version in my local repository but I
    haven't released it, since I don't see myself spending much time on
    it in the near future, and I don't want to mislead anybody into
    thinking so.

    --
    _ _
    | |__ __ _| |_ ___ _ __ ___ __ _ _ __
    | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
    | |_) | (_| | |_\__ \ | | | | | (_| | | | |
    |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com

    The most important design issue... is the fact that Linux is supposed to
    be fun...
    -- Linus Torvalds at the First Dutch International Symposium on Linux



    Zach Guest

  13. #13

    Default Re: choosing ruby?

    Thanks to everybody for your valuable feedback.

    We have decided to go for java, using Velocity indeed (our own framework
    is based on Velocity).

    I entirely support the idea of having some working mechanism for
    ruby-java integration, even if not entirely mature.

    Having precompiled binaries of ruby interpreter for several platforms is
    an issue that may have impacts on a future choice. Is there anything we
    can do for that, as a community?

    Ciao, Giuliano


    Piergiuliano Bossi wrote: 

    --
    If you want to send me an email in the address you have to write 'p',
    then a dot, followed by 'bossi' at 'quinary', another dot and 'com' at last

    Piergiuliano Guest

  14. #14

    Default Re: rjni

    Mauricio FernŠndez <com> wrote in message news:<ei.uni-stuttgart.de>... 
    >
    > I have to confess it's not a matter of time -- it's just that I'm facing
    > the need to rewrite it all in C (for performance) and frankly that's no
    > fun :-|[/ref]

    Would it be premature optimization? In other words, do you have all
    the functionality you need with Ruby code yet? If you don't rewrite
    in C is the performance in Ruby acceptable?

    I think in most cases performance is probably acceptable. In cases
    like this, I (as a user) like having the option of using the pure
    Ruby implementation if possible because I'm not always in a position
    to compile the extension. So I would recommend that when you do the
    rewrite in C that you not actually replace the Ruby code, but offer it
    as an option.

    for example:

    begin
    require 'rjni.so' #try for the C implementation first
    rescue LoadError
    require 'rjni.rb' #if it's not available use the ruby implementation
    end

    Or, perhaps for the time being while you're implementing parts of it
    in C you could do something like:

    require 'rjni.rb'
    begin
    require 'rjni_speedup.so'
    rescue LoadError
    puts "no speed up available for now; going with pure Ruby
    implementation"
    end

    Where rjni_speedup.so contains the C implementations for various
    methods that could benefit from a C implementation. That way you
    don't have to think that you need to rewrite everything over in C
    before you can release, you can release small chunks of C
    implementation as you have time.
     

    cool.

    Phil
    Phil Guest

  15. #15

    Default Re: rjni

    On Thu, Jan 29, 2004 at 02:59:54AM +0900, Phil Tomson wrote: 
    >
    > Would it be premature optimization? In other words, do you have all
    > the functionality you need with Ruby code yet? If you don't rewrite
    > in C is the performance in Ruby acceptable?[/ref]

    The main slowdown comes from overloading. Simple methods can be
    dispatched at a rate of 30000/s or so on a 1700XP+ K7. However, once
    you get several methods with different signatures (but same name) this
    figure degrades quickly.
     

    An extension _is_ always needed (I don't think I could wrap all of JNI
    only with Ruby/DL). What I meant is that in the current code base only
    a basic JNI wrapping is implemented in C, and everything else (method
    dispatching, parameter conversion, simulation of singletons,
    exceptions...) is written in Ruby using the extension.

    [...]
     

    <grain_of_salt>
    That's a possibility... surely way more gratifying than having to write
    some 10000-15000 lines of tedious, boring C code, for a project I have
    personally nothing to gain from besides 'experience' (I do not use Java :P).
    Still, I took a look at my code today and felt like playing with
    it a bit more (I'm finding it exciting again :), but I just don't want to
    fool anybody into thinking I'll deliver a business-grade product: I can
    only withstand a limited amount of boring/tedious coding, there are
    so many interesting things competing with that (which do not require
    leaving Ruby, btw) ;-)
    </grain_of_salt>

    --
    _ _
    | |__ __ _| |_ ___ _ __ ___ __ _ _ __
    | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
    | |_) | (_| | |_\__ \ | | | | | (_| | | | |
    |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com

    Turn right here. No! NO! The OTHER right!


    Mauricio Guest

  16. #16

    Default Re: rjni

    Mauricio FernŠndez <com> wrote in message news:<ei.uni-stuttgart.de>... 
    > >
    > > Would it be premature optimization? In other words, do you have all
    > > the functionality you need with Ruby code yet? If you don't rewrite
    > > in C is the performance in Ruby acceptable?[/ref]
    >
    > The main slowdown comes from overloading. Simple methods can be
    > dispatched at a rate of 30000/s or so on a 1700XP+ K7. However, once
    > you get several methods with different signatures (but same name) this
    > figure degrades quickly.

    >
    > An extension _is_ always needed (I don't think I could wrap all of JNI
    > only with Ruby/DL). What I meant is that in the current code base only
    > a basic JNI wrapping is implemented in C, and everything else (method
    > dispatching, parameter conversion, simulation of singletons,
    > exceptions...) is written in Ruby using the extension.
    >
    > [...]

    >
    > <grain_of_salt>
    > That's a possibility... surely way more gratifying than having to write
    > some 10000-15000 lines of tedious, boring C code,[/ref]

    Can a tool like Swig help to automate the process? I wouldn't want to
    type in that much C code either. Check out http://www.swig.org and
    see if it will help you avoid all that coding.

    Phil
    Phil Guest

  17. #17

    Default [ANN] rjni: using Java from Ruby through JNI (was Re: choosing ruby?)

    On Wed, Jan 28, 2004 at 01:21:37PM +0900, Joel VanderWerf wrote: 
    > >
    > >
    > >I'm sorry to have to tell you that rjni is at best alpha :-(
    > >I've got a nearly feature-complete version in my local repository but I
    > >haven't released it, since I don't see myself spending much time on[/ref][/ref]

    Due to popular demand I have cleaned my latest code, added some API
    doentation and released it under

    http://www.thekode.net/ruby/rjni

    For the record:

    rjni exposes the Java Native Interface to Ruby. This allows the programmer
    to instantiate Java objects, manipulate them, etc.. from Ruby.

    Note that rjni is not meant to embed Ruby in Java, although it can be
    used to ease integration in that case.

    WARNING: THIS IS A TECHNOLOGY PREVIEW. THE SOFTWARE IS NOT EVEN ALPHA
    QUALITY AT THE MOMENT AND IS NOT MEANT TO BE USED YET. IT IS ONLY
    PROVIDED TO PRESENT THE TECHNIQUES EMPLOYED AND (HOPEFULLY) TO
    ACCELERATE THE DEVELOPMENT.
     
    >
    > If you release rjni you will be granted 3 wishes ;-)[/ref]

    Whom should I contact? :)

    --
    _ _
    | |__ __ _| |_ ___ _ __ ___ __ _ _ __
    | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
    | |_) | (_| | |_\__ \ | | | | | (_| | | | |
    |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com

    The state of some commercial Un*x is more unsecure than any Linux box
    without a root password...
    -- Bernd Eckenfels


    Mauricio Guest

  18. #18

    Default Re: [ANN] rjni: using Java from Ruby through JNI (was Re: choosingruby?)

    On Thu, 2004-01-29 at 11:34, Mauricio Fern√°ndez wrote: 

    Very cool. Do you suppose someone could move it over to the rjni
    project on RubyForge?

    http://rubyforge.org/projects/rjni/

    That might make it a bit easier for other folks to browse the code, make
    comments, and so forth...

    Yours,

    Tom



    Tom Guest

  19. #19

    Default Re: [ANN] rjni: using Java from Ruby through JNI (was Re: choosing ruby?)

    On Fri, Jan 30, 2004 at 01:44:34AM +0900, Tom Copeland wrote: 
    >
    > Very cool. Do you suppose someone could move it over to the rjni
    > project on RubyForge?
    >
    > http://rubyforge.org/projects/rjni/[/ref]

    Sure, I was the one who registered it ;)
    Expect to find it there in a while (I'm copying it right now)...

    --
    _ _
    | |__ __ _| |_ ___ _ __ ___ __ _ _ __
    | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
    | |_) | (_| | |_\__ \ | | | | | (_| | | | |
    |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com

    'Ooohh.. "FreeBSD is faster over loopback, when compared to Linux
    over the wire". Film at 11.'
    -- Linus Torvalds


    Mauricio Guest

  20. #20

    Default Re: [ANN] rjni: using Java from Ruby through JNI (was Re: choosing ruby?)

    On Fri, Jan 30, 2004 at 02:15:34AM +0900, Mauricio FernŠndez wrote: 
    >
    > Sure, I was the one who registered it ;)
    > Expect to find it there in a while (I'm copying it right now)...[/ref]

    Done. From now on, the latest version of rjni will also be available at
    http://rjni.rubyforge.org

    --
    _ _
    | |__ __ _| |_ ___ _ __ ___ __ _ _ __
    | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
    | |_) | (_| | |_\__ \ | | | | | (_| | | | |
    |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com

    'Ooohh.. "FreeBSD is faster over loopback, when compared to Linux
    over the wire". Film at 11.'
    -- Linus Torvalds


    Mauricio Guest

Similar Threads

  1. Replies: 0
    Last Post: November 1st, 05:21 PM
  2. Replies: 1
    Last Post: October 29th, 07:52 PM
  3. ruby-talk: 80813 (Rite/Ruby2.0 & Ruby vs OCaml)
    By Steven Lumos in forum Ruby
    Replies: 0
    Last Post: October 9th, 10:21 PM
  4. RubyConf, Ruby Central, Ruby Garden temporary outage
    By dblack@superlink.net in forum Ruby
    Replies: 1
    Last Post: September 10th, 03:46 PM
  5. [ANN] ruby-freedb, ruby-serialport, ruby-mp3info moved to Rubyforge
    By guillaume.pierronnet@ratp.fr in forum Ruby
    Replies: 0
    Last Post: August 31st, 11:57 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139