Business application building with Ruby

[Alexey Verkhovsky]

I am contemplating a project, and I have a question:
What components would you use to build a business application in Ruby?

Suppose, you were asked to write a business application. Typical,
no-thrills business app. Reasonably small database, few dozen users (all
internal), some reporting functionality, couple of batch interfaces,
nothing fancy. To give an example, think about sales / stock control
system for a wholesale trader of electronic goods. Or vehicle tracking
system in a truck company. Or something similar.

Naturally enough, one would want to do it in Ruby
But for a job like this, you need a certain set of technologies, namely:

1. A database
Java world: Oracle, MySQL or another relational DB of your choice

2. Some way to persist domain objects and manage transactions
Java world: entity EJBs, JDO, hand-coded DAOs, O/R <censored> mappers,
etc

3. An RPC (remote procedure call) mechanism for communication between
the front-end and the back-end (assuming that the front-end is a thick
GUI).
Java world: session EJBs, servlets

4. A thick GUI
Java world: Swing

5. A Web GUI
Java world: JSP, XSLT, XMLC and all the other stuff

6. An asynchronous communications infrastructure
Java world: message-driven EJBs

Doing the whole thing in Ruby is already experimental enough, so the
choice is limited to mature, production-grade stuff.

What would you use?

If this has been discussed before, I am sorry. Please point me to a
relevant thread in the archives.

Best regards
Alexey Verkhovsky

 

[gabriele renzi]

il Sun, 11 Jul 2004 07:27:23 +0900, Alexey Verkhovsky <[email protected]>
ha scritto::

not that I did this, but I'd expect:

1. A database

postgresql with PL/ruby for the triggers

2. Some way to persist domain objects and manage transactions
Java world: entity EJBs, JDO, hand-coded DAOs, O/R <censored> mappers,

active record and lafcadio seem to be the more mature O/R mapping
layers.
Madeleine and ruby/DBI may be good choice, too.

3. An RPC (remote procedure call) mechanism for communication between
the front-end and the back-end (assuming that the front-end is a thick
GUI).

druby (DRB) is widely used and included in the standard library

4. A thick GUI

fox and gtk bindings have been around for much time. maybe qt and wx
are nicer to you, but bindings are younger

5. A Web GUI

eruby, amrita

6. An asynchronous communications infrastructure

not sure here, but maybe Rinda (part of DRB) may be useful?

 

[Kirk Haines]

On Sun, 11 Jul 2004 07:27:23 +0900, Alexey Verkhovsky wrote

I do this regularly, though most of the work so far has tended to be much
more centric on web based applications.

1. A database
Java world: Oracle, MySQL or another relational DB of your choice
MySQL

2. Some way to persist domain objects and manage transactions
Java world: entity EJBs, JDO, hand-coded DAOs, O/R <censored>
mappers, etc

Kansas has been maturing wonderfully for my purposes for this.

3. An RPC (remote procedure call) mechanism for communication between
the front-end and the back-end (assuming that the front-end is a
thick GUI). Java world: session EJBs, servlets

drb. Works great.

4. A thick GUI
Java world: Swing

TK, Qt, Fox

5. A Web GUI
Java world: JSP, XSLT, XMLC and all the other stuff

I've use Iowa very successfully for this every day for a couple of years.

6. An asynchronous communications infrastructure
Java world: message-driven EJBs

I am using Drb/Rinda/Tupleserver pretty effectively for this. No problems
with it at all so far.


Kirk

 

[Alexey Verkhovsky]

Thanks for the responses.

What should I make of the somewhat scary fact that most of the
components mentioned, including ALL persistence layer stuff, have
version numbers 0.something?

I thought, by convention, the first version that project developers
consider "production-grade" would be numbered 1.0. Am I wrong?

Best regards,
Alexey Verkhovsky

 

[Austin Ziegler]

What should I make of the somewhat scary fact that most of the
components mentioned, including ALL persistence layer stuff, have
version numbers 0.something?

I thought, by convention, the first version that project developers
consider "production-grade" would be numbered 1.0. Am I wrong?

Well, it's not really scary, since you can tweak them yourself. To me,
a 1.0 means that the product is feature-complete, relatively bug free,
and has been worked for scalability. Thus, what you can read from
these versions is that (1) people are using them, (2) they aren't
"feature-complete" according to the author, (3) they may have bugs,
and (4) they may not be as scalable as they should be.

For Ruwiki (not really part of the concepts you are examining), I have
a planned feature set, so Ruwiki won't reach 1.0 until those features
are in place.

-austin

 

[gabriele renzi]

Thanks for the responses.

What should I make of the somewhat scary fact that most of the
components mentioned, including ALL persistence layer stuff, have
version numbers 0.something?

I thought, by convention, the first version that project developers
consider "production-grade" would be numbered 1.0. Am I wrong?

1.0 means "we've reached all we wanted to do".
Known and widely used projects, such as openssl still have a versione
number under 1.0, yet they can absolutely be considered production
grade.

 

[Neil Stevens]

Thanks for the responses.

What should I make of the somewhat scary fact that most of the
components mentioned, including ALL persistence layer stuff, have
version numbers 0.something?

I thought, by convention, the first version that project developers
consider "production-grade" would be numbered 1.0. Am I wrong?

I think you're right, but some developers have forgotten that the point of
the version number is to be a sign to the users. They instead choose
numbers that have meaning to the developers but don't give the users any
sign of the importance of each version.

This is what happens when someone who's good at coding gets burdened with
release management.

 

[Kirk Haines]

Thanks for the responses.

What should I make of the somewhat scary fact that most of the
components mentioned, including ALL persistence layer stuff, have
version numbers 0.something?

In my case, with Kansas, it's because there are some features that I would
still like to put into the library before I get to a 1.0, and because my
documentation is poor. The 0.x versioning is more of a counter than
anything, right now.

Ditto with Iowa. I've been using it for production software for two years.
But there are still a couple things I want to add. I probably should just
cut to the chase and get a version 1.0 released, really.


Kirk Haines

 

[Alexey Verkhovsky]

I probably should just
cut to the chase and get a version 1.0 released, really.

Surely, if those other features can be honestly considered as the scope
of version 1.1.

There are many people who think that life is too short to touch anything
with version number less than 1.2.

Best regards,
Alexey Verkhovsky

 

[James Britt]

On Sun, 11 Jul 2004 21:07:33 +0900, Alexey Verkhovsky wrote



In my case, with Kansas, it's because there are some features that I would
still like to put into the library before I get to a 1.0, and because my
documentation is poor. The 0.x versioning is more of a counter than
anything, right now.

Ditto with Iowa. I've been using it for production software for two years.
But there are still a couple things I want to add. I probably should just
cut to the chase and get a version 1.0 released, really.

Similar case with Blogtari. It runs rubyxml.com and ruby-doc.org, plus
some number of other sites. There are still some issues, and some
features I want to add, and some of the API may change, but it's
basically stable.

The use of version number < 1 often means that some features are yet to
be added, the API may change, or there are bugs to be worked out.

Code also often reaches the 1.0 state when the owner realizes he or she
just doesn't have any more time to work on it, and simply wants to stamp
it as "done."

For most libraries you really need to read the release notes to see what
it does, and if it does it reliably. v0.x may mean "it doesn't do all
it should, but what it does do it does well."

James

 

[Neil Stevens]

For most libraries you really need to read the release notes to see what
it does, and if it does it reliably. v0.x may mean "it doesn't do all
it should, but what it does do it does well."

That's why version numbers less than one are meaningless. If the user has
to guess and read the documentation anyway then the version number conveys
no information to the user.

 

[Kirk Haines]

On Mon, 12 Jul 2004 00:02:27 +0900, Neil Stevens wrote

That's why version numbers less than one are meaningless. If the
user has to guess and read the documentation anyway then the version
number conveys no information to the user.

The user has to read the documentation regardless of the version number.
Version numbers are subjective. With the iterations of certain features
that Iowa has gone through, I could easily have it numbered at 2.x now.
That doesn't tell you any more than 0.2.x does, though. It may give you a
different impression, but you still don't know anything until you do your
research.

One of the reasons that I am reticent to go to a version 1.0 yet is, in
fact, not related to the software at all. Rather, it's the documentation.
My documentation needs to be to the point where at least most of the main
things that a person should know to successfully use the software is laid
out in an accessible manner. I've been answering questions from one fellow
for about a week now who is experimenting with Iowa that are illustrating to
me a number places where my documentation is obviously lacking. To my mind,
the availability of sufficient documentation is perhaps an even more
important aspect of labeling something version 1.0 than the software feature
set.

It could be version 9.3.7 or version 0.0.5, but if there isn't sufficient
documentation for one to do due diligence research, the version number is
not particularly important except as a counter.


Kirk Haines

 

[Neil Stevens]

It could be version 9.3.7 or version 0.0.5, but if there isn't sufficient
documentation for one to do due diligence research, the version number is
not particularly important except as a counter.

Then how about using dates as versions? Call the release made tomorrow
20040712.

That won't drive off users who are going to make the reasonable assumption
that anything below 1.1 can't be trusted for real work, it'll let you
distinguish one release from another, and everyone wins.

 

[Gavin Sinclair]

Then how about using dates as versions? Call the release made tomorrow
20040712.

That won't drive off users who are going to make the reasonable assumption
that anything below 1.1 can't be trusted for real work, it'll let you
distinguish one release from another, and everyone wins.

It's not a reasonable assumption. The points made against that
assumption by various people carry more logic than your mere
assertion.

Using dates betrays any notion of a planned release schedule, so it's
not a win-win situation.

Gavin

 

[James Britt]

It's not a reasonable assumption. The points made against that
assumption by various people carry more logic than your mere
assertion.

Using dates betrays any notion of a planned release schedule, so it's
not a win-win situation.

Two apps, both at version x.y.z, may be in very different states of
reliability and feature creep.

But for any given release if you are using Foo 0.2.0, and see that
version 0.2.1 is out, it should mean something different than if 0.3.0
comes out.

Dates do not allow one to indicate if a release is major or minor.

The version numbers of a given app should at least serve as some sort of
code/feature "distance" marker, though the meaning will vary among
applications.

If there is any sort of consensus among Rubyists on release number
guidelines then perhaps some kind soul may offer to write them up and
put them on rubygarden.

 

[Keith P Hodges]

Can anyone tell me if REXML cn bepersuaded to generate using double
quotes rather than single quotes

ie.

<div class="hello">

rather than

<div class='hello'>


I am also strugling to persuade REXML not give me attributes with
normalized values.

In the following

<a href="javascript:window.open('http:// .......... ">....</a>

I get

<a href="javascript:window.open(&apos;http:// .......... ">....</a>

thanks in advance for any help

Keith

 

[Gavin Sinclair]

Gavin Sinclair wrote:

Two apps, both at version x.y.z, may be in very different states of
reliability and feature creep.

But for any given release if you are using Foo 0.2.0, and see that
version 0.2.1 is out, it should mean something different than if 0.3.0
comes out.

Dates do not allow one to indicate if a release is major or minor.

The version numbers of a given app should at least serve as some sort of
code/feature "distance" marker, though the meaning will vary among
applications.

If there is any sort of consensus among Rubyists on release number
guidelines then perhaps some kind soul may offer to write them up and
put them on rubygarden.

Since RubyGems is concerned with version numbers, Jim Weirich has
written a RationalVersioningPolicy on the RubyGems wiki at
http://rubygems.rubyforge.org.

According to that policy, every time a backwards-incompatibile API
change occurs, the major version number gets bumped. I guess there's
an implicit caveat for very early versions of a project, otherwise
we'd have version numbers like 15.0.1 frequently. Jim?

Cheers,
Gavin

 

[Sean Russell]

Can anyone tell me if REXML cn bepersuaded to generate using double
quotes rather than single quotes

Nope. You can submit a feature request, though, at:

http://www.germane-software.com/cgi-bin/roundup/rexml

and I'll add it when I get a chance. This week is pretty busy and I
haven't had any time to do any REXML work, but I should have some time
to work on it this weekend.

If you need to replace quotes with apostrophes, hack the
Attribute#to_string method in rexml/attribute.rb and just replace them
yourself. It isn't an ideal solution, but it should suffice for a
short-term fix.

I am also strugling to persuade REXML not give me attributes with
normalized values.

They should be normalized for proper XML. REXML does not generate
HTML, which is an SGML language. For instance, <br>s in HTML are not
closed. There's a whole section in XSL that talks about how XML
should be re-formatted to be "proper" HTML.

In the following ....
I get

<a href="javascript:window.open(&apos;http:// .......... ">....</a>

REXML always uses apostrophes, so this can't really be what you're
getting. In any case, there isn't a way to turn off normalization in
REXML attributes at the moment.

This shouldn't be a problem with modern browsers; I think even IE, as
non-conformant as it is, accepts entities in attributes.

--- SER

 

[Francis Hwang]

I don't think there's any consensus as to what version numbers mean.
In the case of Lafcadio I can tell you that although it's not done,
it's also used on real systems handling real users and non-trivial
volume. (I believe the same can be said for ActiveRecord, too.)

The site where I mainly work gets 3m hits/month; that's backed by
Lafcadio. In fact I make sure to always have a stable bugfix branch
and a dev branch so users can choose their level of risk. I use the
stable bugfix branch for that main site.

Francis

 

[zuzu]

I don't think there's any consensus as to what version numbers mean.
In the case of Lafcadio I can tell you that although it's not done,
it's also used on real systems handling real users and non-trivial
volume. (I believe the same can be said for ActiveRecord, too.)

The site where I mainly work gets 3m hits/month; that's backed by
Lafcadio. In fact I make sure to always have a stable bugfix branch
and a dev branch so users can choose their level of risk. I use the
stable bugfix branch for that main site.

Francis

to start with, http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html

FreeBSD (perhaps the *BSDs in general) seem to have defined a standard
for what versioning should mean. not just release vs. current vs.
stable, but also their numbering.

so patterns exist to stablize what versioning should constitute.

i dislike dating because it doesn't actually tell you anything. a
next day release tells you as much as a version++ . but versioning
should _add_ relevent information to that.

-z