Forum: Ruby on Rails Is this an elaborate hoax/troll?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Edward F. (Guest)
on 2006-03-29 02:54
(Received via mailing list)
I sure hope so:

http://duckdown.blogspot.com/2006/03/additional-th...

Seems like it's getting genuine rebuttals, though. It's actually kind
of amusing.
Giles B. (Guest)
on 2006-03-29 02:59
(Received via mailing list)
no, it's sincere. that's this totally crazy dude who DHH talks about
in his blog.

http://www.loudthinking.com/arc/000577.html
Giles B. (Guest)
on 2006-03-29 03:10
(Received via mailing list)
btw, I think he's doing it for the Google Ads revenue. his arguments
don't even make sense.
Ben R. (Guest)
on 2006-03-29 03:13
(Received via mailing list)
DHH has been writing about this on his blog:

Boy, is James McGovern enterprise or what!
http://www.loudthinking.com/arc/000577.html

Calling bullshit on the Enterprise A.s
http://www.loudthinking.com/arc/000578.html

Amusing...

On 3/28/06, Edward F. <removed_email_address@domain.invalid> wrote:
>
--
Ben R.
http://www.benr75.com
Tony P. (Guest)
on 2006-03-29 03:18
(Received via mailing list)
I've been trying to figure out how to retrieve a http head request
date using http-access2.

I thought this could work:

h = HTTPAccess2::Client.new()
res = h.head('http://involution.com')
print response.header['date'],"\n"

However, that seems to be returning Time.now.  Any suggestions?

FYI, you can view a http request by doing the following:

telnet involution.com 80
Trying 69.58.21.60...
Connected to involution.com.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
-----> Date: Tue, 28 Mar 2006 23:01:47 GMT <------- Date Header ----X
Server: Apache/2.0.52 (Red Hat)
Cache-Control: no-cache
Set-Cookie: _session_id=670e36e364a03785011afbfafbc15fde; path=/
Connection: close
Content-Type: text/html; charset=UTF-8

I'm looking at trying to find a way to see what time the server thinks
it
is to do some time zone correction foo.

Regards,

Tony
http://involution.com
David J. (Guest)
on 2006-03-29 03:41
(Received via mailing list)
I reviewed most of his arguments, and he is dead on.  These are exactly
the reasons that I cannot recommend  Ruby as an architecture language
for my company.  I love Ruby (so far), but it isn't ready for prime-time
in my day-to-day work environment (large company with over 8,000 users
on a real-time business critical system).

As I am working with Ruby and Rails, I am discovering both how nice this
combination can be and what its shortcomings are.  For the most part,
these are a matter of maturity, not principle.  Given another year or
two Ruby could be up to snuff.

With that said, I can recommend Ruby "as-is" for "bread and butter"
applications and utility scripting, and as a "watch" technology as
certain features mature.

At the same time, J2EE is showing its age.  After ten years of being
used to write web apps that babysit RDBMS's, J2EE is harder to use than
ever and slow as molasses at Cold Lake in January.  The EJB/DAO design
pattern quadruples the programmer's work with negative payback in
performance and reliability.

JRuby (Ruby running under a JVM) is actually very interesting to us, but
it is about 80 bugs away from being ready for active consideration.
JRuby offers the internationalization, threading, and other support that
regular Ruby does not yet, because the underlying JVM and Java runtime
classes support them.
John S. (Guest)
on 2006-03-29 03:52
(Received via mailing list)
Considering he is not directing his argument at Rails, I think he is
pretty much right. But Rails (or any web development environment) is
a completely different ballpark. His verbose argument boils down to
the fact that scripting languages are not good for commercial
applications, but he fails to mention they are great for web
applications.

-John

--
John S.
Computing Staff - Webmaster
Kavli Institute for Theoretical Physics
University of California, Santa Barbara
removed_email_address@domain.invalid
(805) 893-6307
Jón B. (Guest)
on 2006-03-29 03:59
(Received via mailing list)
Sorry.. But JRuby just mystifies me..... Why would you want to make
Ruby slower????

Can you just point out to me how running Ruby in a virtual machine is
going to improve anything?

Regarding the enterprise support for 8000 users.... I would say that
it's not really a problem for Ruby on Rails. It's more the headache of
the developer of the application rather than problems of the framework
builders. It's true that many things is immature and untested in Ruby
when it comes to high user base and things like load balancing is
really non-existent. But I frankly don't want it in there except as an
optional gem because I just simply don't want to know of it's
existence until I need to use it.

To sum it up... Yes... Rails is maybe not ready for the enterprise
market. But isn't it really OUR job to make it ready?


On 3/28/06, David J. <removed_email_address@domain.invalid> wrote:
>
> JRuby (Ruby running under a JVM) is actually very interesting to us, but
> > > no, it's sincere. that's this totally crazy dude who DHH talks about
> > > > of amusing.
>
> _______________________________________________
> Rails mailing list
> removed_email_address@domain.invalid
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
Jason P. (Guest)
on 2006-03-29 04:21
(Received via mailing list)
On Mar 28, 2006, at 5:41 PM, David J. wrote:

> I reviewed most of his arguments, and he is dead on.  These are
> exactly
> the reasons that I cannot recommend  Ruby as an architecture language
> for my company.

Good grief, if you'd read DHH's post at <http://www.loudthinking.com/
arc/000577.html> you'd see that the guy was initially claiming that
Ruby lacked support for regular expressions, instance variables, lack
of a packing system, no access control, etc. (and he did make these
claims, I read his entry myself before he edited it) and when
"bullshit" was called he rewrote them as the soft, amorphous points
that you're now agreeing with.

--
Jason P.
removed_email_address@domain.invalid

"The computer allows you to make mistakes
faster than any other invention, with the
possible exception of handguns and tequila."
David J. (Guest)
on 2006-03-29 05:22
(Received via mailing list)
I didn't see his original post.

His points (current posting) are not about the design of ruby, they are
about the maturity of the platform for use in large scale developments.
To you they may be amorphous, but to my day to day work they are
crippling (except for the powerpoint presentations - I can do without
those).

Give Ruby a year and it can easily be up to snuff, if the points are
addressed instead of shooting the messenger (however obnoxious he may
have been).
Jeremy H. (Guest)
on 2006-03-29 06:03
(Received via mailing list)
Could you be more specific about the points that actually matter to you?

I see very little in Rails that makes it less suitable for the typical
"enterprise" labelled application than either Java or .NET web
application frameworks. Nearly all enterprise applications are in fact
depressively simplistic front-ends to poorly designed databases that
meet the supposed needs of process designers far better than their end
users, and mostly exist only extend the fiefdoms of has-been
technology managers and the change management institutions that they
serve.

We call this politics and accept it as a given, and I am no different
- really I don't care. The spirit of Rails is so opposed to any sort
of enterprise development of this description that programming in this
language may as well not even be considered the same occupation as
programming in a corporate soup of powerpoints, paperwork, buzzwords
and vendor partnerships.

The battle for the enterprise is not worth winning, why fight it.

On 3/28/06, David J. <removed_email_address@domain.invalid> wrote:
> have been).
> > arc/000577.html> you'd see that the guy was initially claiming that
> > "The computer allows you to make mistakes
> Rails mailing list
> removed_email_address@domain.invalid
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
Jeremy H.
http://www.jeremyhuffman.com
David J. (Guest)
on 2006-03-29 06:05
(Received via mailing list)
On Tue, 2006-03-28 at 23:59 +0000, Jon Gretar B. wrote:
> Sorry.. But JRuby just mystifies me..... Why would you want to make
> Ruby slower????
>

If (big if) Ruby follows the pattern of other languages using the JVM,
it will compile the source to java byte code (.class file).  My own
benchmarks have established that a Java hotspot compiler (which
recompiles frequently used byte code to native code) will perform within
10% of hand optimized assembly language for the same tasks.  I was able
to trace the cause for the 10% difference to the stack frame handling,
which buys stack safety at the expense of a little performance.

If Ruby follows this pattern, the JIT runtime compilers should speed
ruby up to at least match Java.

If there are performance issues with the byte code being generated by
the JRuby compiler then those are best resolved by hitting the keyboard,
not the messenger.

> Can you just point out to me how running Ruby in a virtual machine is
> going to improve anything?
>
Off the top of my head ...

1. JIT compiler.

2. Unicode support is a huge thing for internationalization.  I was
surprised that Ruby kept all of the code page garbage of the '80s, given
the maturity of the C libraries supporting the unicode specification and
that Ruby's country of origin uses a non-latin alphabet.

3. With java's unicode support is also a mature library of character set
conversions.

4. Native support for threading is a critical thing if you are to make
vertically scalable apps.

5. Instant, painless migration path to allow reuse of existing mature
application logic.  I am not going to rewrite 2 million lines of my
company's java code in Ruby, but having that pre-existing work available
to reuse without change will save me a lot of effort in migration, and
make it easier to promote the Ruby platform in the long term.

> Regarding the enterprise support for 8000 users.... I would say that
> it's not really a problem for Ruby on Rails. It's more the headache of
> the developer of the application rather than problems of the framework
> builders.

The platform needs to support a few minimum constructs for that to work.
Delphi never made it as an enterprise platform because it did not
support the vertical scalability necessary.  Vertically scaling a Delphi
app required one to throw out hte "Delphi" parts of the environment
andbecome an Object Pascal programmer.  Java made it at the enterprise
level because the JVM handled the baseline requirements for vertical
scaling, and the core objects in the java runtime library were built to
handle it.

> It's true that many things is immature and untested in Ruby
> when it comes to high user base and things like load balancing is
> really non-existent. But I frankly don't want it in there except as an
> optional gem because I just simply don't want to know of it's
> existence until I need to use it.

Bingo ... but I need it available before I can even seriously consider
it.  Unfortunately, that stuff is not "tack on".  It impacts the core
design of the engine.  If the engine doesn't support it, the language
will never perform adequately under pressure.

There are areas where Ruby needs to mature to make it a viable
_enterprise_ platform.  Rails also has some areas it needs to address,
but those are not fundamentally issues with Ruby.  None of the issues
raised are with the fundamental designs of either product.

They are issues with their current level of maturity that can be
addressed better by hitting the keyboard than slamming the blogger.

> To sum it up... Yes... Rails is maybe not ready for the enterprise
> market. But isn't it really OUR job to make it ready?

I agree ... but slamming the messenger in a flame war doesn't resolve
the issues.  Taking his valid points (who cares about powerpoint
presentations) and resolving them would bring Ruby much closer to being
a viable enterprise platform.
Larry W. (Guest)
on 2006-03-29 06:26
(Received via mailing list)
I've read the arguments and they range from reasonable to foolish, but
the
real point is that he's 'not even wrong' as the saying goes.

I've been making my living as an engineering manager working on
commercial
enterprise Java aplicatations for almost 10 years now.  Ruby on Rails is
a
perfect example of a disruptive innovation - no it's not as good as java
in
some ways - time zone support for one - but it's waaaayyy better than
java
in other more important ways.  This guy's on his way to being the COBOL
programmer of 2010.

The idea, btw, that Java programmers/programs are inherently better at
architecture, btw, is an urban myth.
David M. (Guest)
on 2006-03-29 06:54
(Received via mailing list)
On 29/03/06, Jeremy H. <removed_email_address@domain.invalid> wrote:
> Could you be more specific about the points that actually matter to you?
>
> I see very little in Rails that makes it less suitable for the typical
> "enterprise" labelled application than either Java or .NET web
> application frameworks. Nearly all enterprise applications are in fact
> depressively simplistic front-ends to poorly designed databases that
> meet the supposed needs of process designers far better than their end
> users, and mostly exist only extend the fiefdoms of has-been
> technology managers and the change management institutions that they
> serve.

Sure, here's some that come to mind

Support for Oracle; while I haven't tried using Oracle with Rails
personally, there's enough people having trouble with it to make me
suspect that Oracle+Rails might not be a good combination

Support for DB2: last time I checked, this was still a problem, but
people were working on it.  Anyone know what state it's currently in?

Support for stored procedures and views: Rails has adopted a stance
that makes stored procs and views (in any DB) difficult to implement.
Never mind that Rails' "sweet spot" says that stored procs and views
aren't necessary; in any business-critical enterprise DB, an app
developer will only get access to data via views and stored procs, so
needs to be able to work with them.  It *can* be done in Rails (at
least with Postgres, which I've tried), but it's not trivial.

Support for legacy databases: again, Rails can be made to work with
non-Rails-conformant table and field names, but it's painful.  Not
such a big deal once you get your head around it, but having to do
this will start to slice into Rails' massive reduction in dev time and
resources over e.g. J2EE.

Lack of support for MQ: this may seem a bit left field, but anyone
with experience across a range of enterprise-class IT will be familiar
with sites that *mandate* all app-to-DB connectivity must go through
MQ.  Your app submits its "request" onto a queue, the database reads
your request and puts the response on another queue, your app picks up
the response from the queue.  It's big and clunky, but it works, is
rock solid reliable and you'll find it just about everywhere an IBM
mainframe is in place.  Sure, you could (probably) build a MQ
interface onto Rails, but it doesn't exist now.  You could use Rails
to bolt a Web services layer onto MQ, but now you've just increased
the scope of what you're developing quite significantly.

Development tools: RADrails is coming along, but it lags behind e.g.
Visual Studio by some way at present.  If your entire enterprise dev
team can be infected with the Rails bug, and is happy to put up with
dev tools of a significantly lower standard than what they're
currently using, fine, but most dev shops will have at least one old
guy in a cardigan who's memorised every aspect of Visual Studio and
will fight back if you try to take it away from him.

Don't get me wrong - Rails can do lots and lots of good stuff, and its
niche is a quite large in the scale of "massive enterprise system"
through "Mum's photo album" development tasks.  I really like Rails,
use it daily, and am slowly introducing it to places where I work with
promising results.  Building a prototype for some complex app in Rails
in a few hours is an absolutely KILLER way of demonstrating
productivity increases, and Rails fits with my subversive persona very
nicely.  I agree that in 12 months' time, it'll be a significantly
better fit for many enterprises.

However:
- not all enterprise apps are simple front ends on top of poorly
designed databases
- legacy databases and interfaces are all through enterprise IT shops,
and you'd better have a way of dealing with them if you're introducing
a bunch of new technology
- end-users often have an extremely high degree of input into app design
- many/most/all IT managers are constantly bombarded by "the next big
thing" from all their vendors, and Rails is just another "next big
thing" in their minds and will be treated accordingly
- J2EE and .NET actually work quite well in a lot of places, for a lot
of apps


Interested in others' thoughts on this - good thread

Regards

Dave M.
Jón B. (Guest)
on 2006-03-29 07:01
(Received via mailing list)
On 3/29/06, David J. <removed_email_address@domain.invalid> wrote:

> ruby up to at least match Java.
>
> If there are performance issues with the byte code being generated by
> the JRuby compiler then those are best resolved by hitting the keyboard,
> not the messenger.

But having a real ruby compiler (Something I understand is coming
built in version 2) is always going to be faster. The problem I have
always had with java is that virtual machines will ALWAYS slow things
down. It's just the way it works. Java is indeed faster now when
compiled(but with much higher memory use) but that is because of
compilation. I would think that a compiled ruby app would be much
faster.

>
> 4. Native support for threading is a critical thing if you are to make
> vertically scalable apps.
>
> 5. Instant, painless migration path to allow reuse of existing mature
> application logic.  I am not going to rewrite 2 million lines of my
> company's java code in Ruby, but having that pre-existing work available
> to reuse without change will save me a lot of effort in migration, and
> make it easier to promote the Ruby platform in the long term.
>

But why oh why Java??? The slowest thing available.... People started
developing in Ruby to get away from things like Java.


>
> The platform needs to support a few minimum constructs for that to work.
> Delphi never made it as an enterprise platform because it did not
> support the vertical scalability necessary.  Vertically scaling a Delphi
> app required one to throw out hte "Delphi" parts of the environment
> andbecome an Object Pascal programmer.  Java made it at the enterprise
> level because the JVM handled the baseline requirements for vertical
> scaling, and the core objects in the java runtime library were built to
> handle it.

Yes..... Also one of the reason Java won that battle is because for
some reason schools seem to prefer teaching Java. I just don't
understand why some developers incist on using java for desktop
applications for example. Being cross platform doesn't help if the
users dislike using the software because it is slow and unresponsive.
But your point is true. But it only says why Java won Delphi.


> I agree ... but slamming the messenger in a flame war doesn't resolve
> the issues.  Taking his valid points (who cares about powerpoint
> presentations) and resolving them would bring Ruby much closer to being
> a viable enterprise platform.

The messenger was not slammed because of the message. He was slammed
because:
A) Nobody likes people who proclaim themselves industry leaders when
ho showed many times that he had marginal programming knowledge
B) He didn't even seem to have looked at Ruby. His message was full of
errors and FUD. Even though he tried to hide it later. (ceck out JHH's
post to see what I am talking about)


--
Craig W. (Guest)
on 2006-03-29 07:03
(Received via mailing list)
On Wed, 2006-03-29 at 13:54 +1100, David M. wrote:
> > serve.
> Support for stored procedures and views: Rails has adopted a stance
> this will start to slice into Rails' massive reduction in dev time and
> interface onto Rails, but it doesn't exist now.  You could use Rails
>
> However:
>
>
> Interested in others' thoughts on this - good thread
----
I'll add my $ .02 - easy/good access to enterprise authentication system
and I say this because of the incredible amount of time that I have
wasted trying to make rails connect to an LDAP server.

Craig
David J. (Guest)
on 2006-03-29 07:05
(Received via mailing list)
On Tue, 2006-03-28 at 21:03 -0500, Jeremy H. wrote:
> Could you be more specific about the points that actually matter to
> you?

1. Native support for threading

2. Standardized support for prepared statements in the RDBMS adapter
classes (once I have more Ruby experience I plan to address this one
myself)

3. Unicode support

4. Platforms other than Windows and *nix.  Z/OS would be a good place.
Ruby would be a great competitor for Rexx.

5. Performance boost

>
> I see very little in Rails that makes it less suitable for the typical
> "enterprise" labelled application than either Java or .NET web
> application frameworks. Nearly all enterprise applications are in fact
> depressively simplistic front-ends to poorly designed databases that
> meet the supposed needs of process designers far better than their end
> users, and mostly exist only extend the fiefdoms of has-been
> technology managers and the change management institutions that they
> serve.
>
:o)  Seen some of that.

On the other hand, when handling well over 1,000,000 transactions per
hour, 24x7 in a highly integrated but heterogeneous environment, where
downtime cost is measured in tens of thousands of dollars per minute,
most of the work is _not_ going into the front end.  Pretty is reserved
for the outside world.  Internal apps must be fast, correct, and cleanly
constructed to not hammer other apps.

The front end may be depressingly simple (my opinion of a good web page
is pure white with black text in Times New Roman 12 point font, and no
other adornment).  But the back ends tend to be both very robust and
challenging, and not entirely because of old bad designs.

> We call this politics and accept it as a given, and I am no different
> - really I don't care. The spirit of Rails is so opposed to any sort
> of enterprise development of this description that programming in this
> language may as well not even be considered the same occupation as
> programming in a corporate soup of powerpoints, paperwork, buzzwords
> and vendor partnerships.
>
That is a poor way to promote the platform, and you are making a common
mistake (one that Mr. McGovern did also) of assuming that just because
you use a common programming language you are also using the same design
methods.

He seems to be working under the assumption that all agile development
is unplanned in nature, and you seem to have the opinion that
communication with one's peers is a bad thing if you're programming in
Ruby.  Ironically, what I see is that you are proving one of his points
by restating it from the other perspective.

Enterprises do engage in agile development.  But part of working in an
enterprise environment is the understanding that you are interacting, in
real time, with potentially hundreds other programs that are all
critical to your own paycheck.

Furthermore, since Enron, people go to jail for certain types of
failures.  I have on more than one occasion asked for "get out of jail
free" letters where I was asked to manually correct information that a
faulty program or process had entered in a database table.  Some of that
paperwork is there for good reasons.

Discussing changes or additions to processes that will impact your peers
in other departments is not a political process.  It is a professional
courtesy and a technical necessity.  You be the one who is woken up at
3:00 AM on Sunday because someone made a change that hammered your
program and didn't tell you!

When I was a 1 man IT shop, I could pretty much do what I wanted.  In a
2 man IT shop (at my church), we have seen a need for formal change
control.  In a company with several hundred programmers and technical
people, maintaining those channels of communication is a large part of
why my company is having record years while our competitors are filing
bankruptcy.

As far as buzzwords goes, Rails is the embodiment of the buzzword "MVC".
It has "AJAX" support.  It uses "Adapters" to talk to "RDBMS".  It uses
"helpers", "containers", "blocks", "hashes", "iterators", and so on.

> The battle for the enterprise is not worth winning, why fight it.

Because if you can win there, you can win anywhere.  In the enterprise,
you win by making the best bottom line consistently.  You achieve the
best bottom line through good communication and technical excellence.

Ruby and Rails have a very good foundation, but they need a little more
maturity to enter that market and win decisively.  J2EE has essentially
failed, client/server technologies are largely a fad of the past, and
people are unwilling to go back to CICS screens.  The spot for Ruby and
Rails is open if the platform can provide the technical underpinnings to
make it work.
Jón B. (Guest)
on 2006-03-29 07:12
(Received via mailing list)
Yes... This and other things other people areare saying here are
things I agree with. I personally will not use ruby for enterprise
setup any day soon.

But don't compare bugs and little problems with what McGovern is
saying. He calls Ruby a trainwreck waiting to happen.


> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
David M. (Guest)
on 2006-03-29 07:16
(Received via mailing list)
Anything can be a trainwreck with a sufficiently-ignorant person at the
wheel.

"When I die, I want to go quietly in my sleep, like my grandfather,
not screaming in terror like his passengers"

Dave M.
Tony P. (Guest)
on 2006-03-29 07:20
(Received via mailing list)
I just did it with one of these:

    server_date = `curl -I #{um.htmlurl} 2> /dev/null`
    print server_date.match(/^Date:.*/), "\n"

which appears to work...

Tony
Hammed M. (Guest)
on 2006-03-29 07:22
(Received via mailing list)
Tony,

Try this:

h = HTTPAccess2::Client.new()
res = h.head('http://involution.com')
res.header['Date']

=> ["Wed, 29 Mar 2006 03:21:30 GMT"]

Time.now  => Tue Mar 28 21:21:41 Central Standard Time 2006

Hammed

On 3/28/06, Tony P. <removed_email_address@domain.invalid> wrote:
> However, that seems to be returning Time.now.  Any suggestions?
> -----> Date: Tue, 28 Mar 2006 23:01:47 GMT <------- Date Header ----X
>
> Tony
> http://involution.com
> _______________________________________________
> Rails mailing list
> removed_email_address@domain.invalid
> http://lists.rubyonrails.org/mailman/listinfo/rails
>



--
Chang Sau S. (Guest)
on 2006-03-29 07:24
(Received via mailing list)
In the article James McGovern mentioned only 'Ruby' but never 'Ruby on
Rails' and it was obliquely insulting the way he put the various
train-wreck pictures. Some of the things he mentioned are also obviously
wrong -- either he never really used it before or it's a troll? Like
that Ruby doesn't have private, public or protected or it doesn't have
packages.

At a glance I don't think he is really serious. I mean -- how can I take
him seriously if he keeps refering to consulting firms as 'insulting'
firms and has apparently not even used Ruby before?

Larry W. wrote:
> The idea, btw, that Java programmers/programs are inherently better at
>     about the maturity of the platform for use in large scale
>     > On Mar 28, 2006, at 5:41 PM, David J. wrote:
>     > Ruby lacked support for regular expressions, instance variables,
>     > "The computer allows you to make mistakes
>     Rails mailing list
>
--
Sau S.

http://www.saush.com
http://read.saush.com
http://jaccal.sourceforge.net
David J. (Guest)
on 2006-03-29 07:27
(Received via mailing list)
On Wed, 2006-03-29 at 03:01 +0000, Jon Gretar B. wrote:
> >
>
> But why oh why Java??? The slowest thing available.... People started
> developing in Ruby to get away from things like Java.
>
>

The problem with Java is not the language or the JVM.  Both are pretty
mundane.

The biggest problem with Java is that we have trained a generation of
programmers to build EJB's for everything using the JPetStore example as
a pattern.

The tool is fundamentally good, but we have failed to train programmers
to use the tool properly.  Any tool could fall to this fate.

Java has succeeded in that it has successfully built a cross-platform
virtual machine (that is not tied to the Java language), JIT compilers
that allow running code to perform comparably to native compilers for
the same task, and a huge library of reusable and reliable code that
runs on all of those platforms.

Leveraging the JVM automatically gets ruby into any platform supporting
a JVM:  Z/OS, WAP, AS/400, 6000 series, 9000 series, embedded
applications, etc.  It automatically buys you the ability to reuse the
good things from Java: JDBC, MQ, LDAP, xalan/xerces, unicode, character
set conversions.

Over night, Ruby could go from being a niche market to a serious
contender in the enterprise realm just by running inside of a JVM.
David J. (Guest)
on 2006-03-29 07:38
(Received via mailing list)
On Wed, 2006-03-29 at 11:24 +0800, Chang Sau S. wrote:
> In the article James McGovern mentioned only 'Ruby' but never 'Ruby on
> Rails' and it was obliquely insulting the way he put the various
> train-wreck pictures. Some of the things he mentioned are also
> obviously wrong -- either he never really used it before or it's a
> troll? Like that Ruby doesn't have private, public or protected or it
> doesn't have packages.

But those things that are obviously right are real issues for the
enterprise user, and addressing them will only improve the platform.

>
> At a glance I don't think he is really serious. I mean -- how can I
> take him seriously if he keeps refering to consulting firms as
> 'insulting' firms

Have you ever had to deal with a consulting firm that didn't really
understand your business before?  I believe most enterprise people will
understand the reference.  Typically, this involves either a firm that
has only worked on small systems before (<1000 concurrent users) or has
only worked on projects in the financial sector (banks or stock
markets).

> and has apparently not even used Ruby before?

He didn't do a very thorough analysis.  I agree.  He also confused the
programming language with the programming method.  Bad mistake.

However, he got enough right that agrees with my observations (and those
of others also) that it is worth addressing.
David J. (Guest)
on 2006-03-29 07:41
(Received via mailing list)
And COBOL and J2EE are trainwrecks that have already happened.  The
world didn't end, and there are still more lines of COBOL out there than
all other languages put together (because it takes more lines of code to
do anything in COBOL).

All of McGoverns concrete observations are about platform maturity, not
baseline design.  They can be addressed by hitting the keyboard.
David J. (Guest)
on 2006-03-29 07:48
(Received via mailing list)
On Tue, 2006-03-28 at 21:25 -0500, Larry W. wrote:
> I've been making my living as an engineering manager working on
> commercial enterprise Java aplicatations for almost 10 years now.
> Ruby on Rails is a perfect example of a disruptive innovation - no
> it's not as good as java in some ways - time zone support for one -
> but it's waaaayyy better than java in other more important ways.  This
> guy's on his way to being the COBOL programmer of 2010.
>

My shop still employs more COBOL programmers than any other platform.  I
guess it means he will be employed.  I plan to be retired.   :o)

Thankfully, I am not limited to only one (or even 10) programming
languages.


> The idea, btw, that Java programmers/programs are inherently better at
> architecture, btw, is an urban myth.
>

Java programmers, in my experience, tend not to be good at architecture
unless they are familiar with at least six or seven other platforms.
One only has to look at the EJB/VTO/DAO pattern as it is commonly
implemented to see this.  You quadruple the lines of code, then add
another obscure configuration file, and say it is to make it more
manageable?
Jason P. (Guest)
on 2006-03-29 07:59
(Received via mailing list)
On Mar 28, 2006, at 9:41 PM, David J. wrote:

> And COBOL and J2EE are trainwrecks that have already happened.  The
> world didn't end, and there are still more lines of COBOL out there
> than
> all other languages put together (because it takes more lines of
> code to
> do anything in COBOL).
>
> All of McGoverns concrete observations are about platform maturity,
> not
> baseline design.  They can be addressed by hitting the keyboard.

If that's your contention, then why are you posting to the Rails
mailing list and not the Ruby mailing list?

--
Jason P.
removed_email_address@domain.invalid

"The key to performance is elegance, not
  battalions of special cases."
  - Jon Bentley and Doug McIlroy
Jeremy H. (Guest)
on 2006-03-29 08:01
(Received via mailing list)
> Enterprises do engage in agile development.  But part of working in an
> enterprise environment is the understanding that you are interacting, in
> real time, with potentially hundreds other programs that are all
> critical to your own paycheck.

No one can actually manage hundreds of programs. Instead, we have
application teams each responsible for more or less a dozen
application that consist of a number of programs/interfaces each. We
spend dozens of hours discussing the possible ramfications of any
change to each and cost the business millions in un-implemented
improvements, because we are afraid of both success and failure.


>
> When I was a 1 man IT shop, I could pretty much do what I wanted.  In a
> 2 man IT shop (at my church), we have seen a need for formal change
> control.  In a company with several hundred programmers and technical
> people, maintaining those channels of communication is a large part of
> why my company is having record years while our competitors are filing
> bankruptcy.
>

Interesting. Have you read about Brook's Law? Why does effort expand
non-linearly as team size increases?

My company has more than 20,000 IT employees, about 2500 of which are
or have some resemblance to a programmer/developer. I've worked here
for 8 years and manage a technology team. I'm familiar with our
controls, why we have them and why they contribute to the problem more
than the solution.


> > The battle for the enterprise is not worth winning, why fight it.
>
> Because if you can win there, you can win anywhere.  In the enterprise,
> you win by making the best bottom line consistently.  You achieve the
> best bottom line through good communication and technical excellence.

Maybe in some places. Around here you pretty much need good powerpoint.

> Ruby and Rails have a very good foundation, but they need a little more
> maturity to enter that market and win decisively.  J2EE has essentially
> failed, client/server technologies are largely a fad of the past, and
> people are unwilling to go back to CICS screens.  The spot for Ruby and
> Rails is open if the platform can provide the technical underpinnings to
> make it work.

Interesting. Did client/server fail? Not really. Yeah, we had .dll
hell but in general people liked those applications much better than
anyone ever liked a J2EE app. I have users that still like certain
character-based DOS apps and CICS apps better than anything that has
supplanted them because they are faster and more efficient than waving
a mouse around. Yet J2EE kicked unimaginable butt for years. Why? I'm
sure it has nothing to do with bottom lines, good communication or
technical excellence.

I'm all for communication, and I don't drink the agile kool-aid
either. But I have no respect for the decisions that come out of
corporate bodies, and I wouldn't be swayed by it as a developer
looking for the best framework to solve my business problems; I'd
apply my knowledge of the feature-set to my problems at hand.

--
Jeremy H.
http://www.jeremyhuffman.com
Tony P. (Guest)
on 2006-03-29 08:04
(Received via mailing list)
Indeed, I tried it out, and, indeed, you're correct.  On the positive
side, I know every potential way of comparing HTTP date times now...
Here was my test:

require 'http-access2'require 'date'

h = HTTPAccess2::Client.new()
res = h.head('http://involution.com')
print DateTime.parse(`curl -I http://involution.com 2>
/dev/null`).strftime('%s'),"\n"
print DateTime.parse(res.header['Date'].to_s).strftime('%s'), "\n"
print DateTime.parse(Time.now.to_s).strftime('%s'), "\n"

Output on OS X was:

1143604784
1143604784
1143604787

Thanks, Hammed

Tony
David J. (Guest)
on 2006-03-29 08:57
(Received via mailing list)
On Tue, 2006-03-28 at 21:59 -0600, Jason P. wrote:
> If that's your contention, then why are you posting to the Rails
> mailing list and not the Ruby mailing list?
>
Because someone else started this thread and I thought it looked
interesting.
David J. (Guest)
on 2006-03-29 09:05
(Received via mailing list)
On Tue, 2006-03-28 at 23:00 -0500, Jeremy H. wrote:
> improvements, because we are afraid of both success and failure.
The infamous analysis paralysis syndrome.  I've seen it first hand, and
I sympathize.  Fortunately it has been the exception rather than the
rule.

> non-linearly as team size increases?
>
yes .. that is why individual teams are generally kept to less than six
people.  The rule of thumb is that after six people the cost of
management is more than the cost of the team.

> My company has more than 20,000 IT employees, about 2500 of which are
> or have some resemblance to a programmer/developer. I've worked here
> for 8 years and manage a technology team. I'm familiar with our
> controls, why we have them and why they contribute to the problem more
> than the solution.
>
Our company is similar sized, but we have about 1/5th the number of IT
people, of whom about just under half are programmers and a similar
number are technical support people.  The remainder are management/team
lead types.

>
> > > The battle for the enterprise is not worth winning, why fight it.
> >
> > Because if you can win there, you can win anywhere.  In the enterprise,
> > you win by making the best bottom line consistently.  You achieve the
> > best bottom line through good communication and technical excellence.
>
> Maybe in some places. Around here you pretty much need good powerpoint.

Ugh ... my condolences.

>
> > Ruby and Rails have a very good foundation, but they need a little more
> > maturity to enter that market and win decisively.  J2EE has essentially
> > failed, client/server technologies are largely a fad of the past, and
> > people are unwilling to go back to CICS screens.  The spot for Ruby and
> > Rails is open if the platform can provide the technical underpinnings to
> > make it work.
>
> Interesting. Did client/server fail?

I don't see much C/S work happening any more.  The job market is pretty
slim for C/S apps programmers right now.

> Not really. Yeah, we had .dll
> hell but in general people liked those applications much better than
> anyone ever liked a J2EE app.

Me too, but the cost of deploying our suite of C/S apps to thousands of
machines across the country was prohibitive.  The web environment
sacrifices ease of use for cheaper (but not easier) deployment.  Rails
provides the core for faster development and easier deployment of web
apps (better bottom line) if it could fully meet the technical
requirements.  The formalization of AJAX as a middle ground between C/S
and Browsing, and Rails natural support for that platform, really puts
Ruby and Rails in the right position to become a serious contender.

> I have users that still like certain
> character-based DOS apps and CICS apps better than anything that has
> supplanted them because they are faster and more efficient than waving
> a mouse around.

I understand fully.  You can whip through 10 CICS screens in the time it
takes one web page to render in the browser.

> Yet J2EE kicked unimaginable butt for years. Why? I'm
> sure it has nothing to do with bottom lines, good communication or
> technical excellence.
>
marketing ... but it has failed to deliver on the hype.  It is a good
technology, but it has not reduced the bottom line or improved the IT
experience.  Servlets succeeded, but much of the rest of the J2EE
platform failed.  For example, EJB's failure is exemplified by the
adoption of the competing "hibernate" technology as the core of EJB 3.
The time is right for a competitor to rise up.

> I'm all for communication, and I don't drink the agile kool-aid
> either. But I have no respect for the decisions that come out of
> corporate bodies, and I wouldn't be swayed by it as a developer
> looking for the best framework to solve my business problems; I'd
> apply my knowledge of the feature-set to my problems at hand.

Big ten-four.
Jason P. (Guest)
on 2006-03-29 09:14
(Received via mailing list)
On Mar 28, 2006, at 10:56 PM, David J. wrote:

> On Tue, 2006-03-28 at 21:59 -0600, Jason P. wrote:
>> If that's your contention, then why are you posting to the Rails
>> mailing list and not the Ruby mailing list?
>>
> Because someone else started this thread and I thought it looked
> interesting.

Certainly, but I wonder if ideas wouldn't receive a more thoughtful
review on a list that has folks who are more current on YARV
development, internationalization, etc. than here.

--
Jason P.
removed_email_address@domain.invalid

"The key to performance is elegance, not
  battalions of special cases."
  - Jon Bentley and Doug McIlroy
David J. (Guest)
on 2006-03-29 09:30
(Received via mailing list)
probably ... if this thread is pursued further then maybe it should be
moved.  I think it may have been played out.  I know I am.

See y'all tomorrow.

David J.
Chang Sau S. (Guest)
on 2006-03-29 10:11
(Received via mailing list)
David J. wrote:
> But those things that are obviously right are real issues for the
> enterprise user, and addressing them will only improve the platform.
>
>
Yup, agreed. Rails is only about a year old? Java was about a year old
were still talking excitedly abt the animated Duke. :) Agreed that there
are lots of things to improve on Rails still, but still think it's
current a 'good enough' technology for most small to mid-level
(enterprise or not) web applications. I'm talking for people who has
experience in developing web applications in the first place, not a
total newbie.

> markets).
>
>
Dealt with consulting firms, consulted on a few occasions
(enterprise-level? was dealing with a bank then) as well. Calling names
isn't exactly the best way be taken seriously. But I suppose blogging
changes things nowadays :)

>
--
Sau S.

http://www.saush.com
http://read.saush.com
http://jaccal.sourceforge.net
Ben M. (Guest)
on 2006-03-29 10:15
(Received via mailing list)
What are you talking about? Ruby already runs in a virtual machine:

http://www.rubygarden.org/ruby?VirtualMachineOptions

Also, a virtual machine does not necessarily have the impact on
performance that you think
it does (a poorly designed vm does however):

http://c.ittoolbox.com/documents/academic-articles...
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
http://www.javaworld.com/jw-02-1998/jw-02-jperf.html
http://kontrawize.blogs.com/kontrawize/2006/01/i_c...
http://kano.net/javabench/

And Ruby can only gain from being able to run in more VMs than the
default one, especially
if they have the tremendous penetration that the JVM does.

b
Justin F. (Guest)
on 2006-03-29 14:21
(Received via mailing list)
Ben M. wrote:
> What are you talking about? Ruby already runs in a virtual machine:
>
> http://www.rubygarden.org/ruby?VirtualMachineOptions

Not really. As that page points out, the current Ruby implementation
creates and interprets a parse tree, rather than having a virtual
machine with a defined instruction set.

regards

   Justin
Ugo C. (Guest)
on 2006-03-29 15:40
(Received via mailing list)
Il giorno 29/mar/06, alle ore 05:05, David J. ha scritto:

> Ruby and Rails have a very good foundation, but they need a little
> more
> maturity to enter that market and win decisively.  J2EE has
> essentially
> failed, client/server technologies are largely a fad of the past, and
> people are unwilling to go back to CICS screens.  The spot for Ruby
> and
> Rails is open if the platform can provide the technical
> underpinnings to
> make it work.

David,

I just wanted to congratulate you for your opinions. Spot-on,
equlibrate and hype-free. We need more people like you between the
McGoverns and the iconoclasts of this world. I pretty much agree with
everything you wrote here, no need to add more, really.

	Cheers,

		Ugo


--
Ugo C.
Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Evil or Not?: http://evilornot.info/
Company: http://www.sourcesense.com/
Bry M. (Guest)
on 2006-03-29 17:33
David J. wrote:
> I reviewed most of his arguments, and he is dead on.  These are exactly
> the reasons that I cannot recommend  Ruby as an architecture language
> for my company.  I love Ruby (so far), but it isn't ready for prime-time
> in my day-to-day work environment (large company with over 8,000 users
> on a real-time business critical system).

> With that said, I can recommend Ruby "as-is" for "bread and butter"
> applications and utility scripting, and as a "watch" technology as
> certain features mature.

Eh. At my company we use Ruby to index, process and store electronic
documents in a large database. Near as Monty knows, we have one of the
largest (in terms of record count) MySQL installations. This mission
critical system has an entire stack written in Ruby (except where
certain functions were rewritten in C for speed), including a custom
persistence layer that supports multiple RDBMSs. We've been running this
high throughput system for several years now without a major failure
that wasn't due to hardware or programmer error. When I first came to
ruby I was skeptical myself, but its performance has been outstanding,
and development has been as enjoyable an experience as I've had
programming.

Maybe Ruby isn't ready in terms of APIs and third-party libraries, but
that will come with time. As for the EJB-style n-tier architecture, I'm
not convinced that's an approach that would really benefit Ruby, or
users looking to use Ruby for it.
Jón B. (Guest)
on 2006-03-29 18:29
(Received via mailing list)
But do we want Ruby to be a true enterprise ready application?
I'm not sure we would want that. I would prefer Ruby to be the small
and nice thing it is now rather than becoming the bloated mess Perl
has become. In the same way as I hope Apple never tries to make it
into enterprise markets because these are two masters not easily
served.

Most enterprise software I have tried are great for the enterprise
thinking and method of doing things. But they really are awful at the
home and small business market where the needs are so drastically
different.

Even though many will disagree on comparing software to language in
this way I really think Ruby should NOT try to replace C or Java or
any other languages. Ruby has found it's market and should stick with
it.

On 3/29/06, Bry M. <removed_email_address@domain.invalid> wrote:
>
> programming.
> removed_email_address@domain.invalid
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
Gregory S. (Guest)
on 2006-03-29 19:00
(Received via mailing list)
On Wed, Mar 29, 2006 at 02:25:07PM +0000, Jon Gretar B. wrote:
} But do we want Ruby to be a true enterprise ready application?
} I'm not sure we would want that. I would prefer Ruby to be the small
} and nice thing it is now rather than becoming the bloated mess Perl
} has become. In the same way as I hope Apple never tries to make it
} into enterprise markets because these are two masters not easily
} served.
}
} Most enterprise software I have tried are great for the enterprise
} thinking and method of doing things. But they really are awful at the
} home and small business market where the needs are so drastically
} different.
}
} Even though many will disagree on comparing software to language in
} this way I really think Ruby should NOT try to replace C or Java or
} any other languages. Ruby has found it's market and should stick with
} it.

The problems that keep Ruby from being "ready for the enterprise" affect
more than just enterprise-readiness. Unicode and i18n support is an
issue
if the target audience for your code don't all speak the same language
(e.g. setting up a genealogy website for your family, which has branches
various European countries). Performance, including native threading, is
an
issue for any software that takes too long to do what it does (e.g.
generating thumbnails of all those pictures of your kids on your
dual-processor machine). Rails support for stored procedures is harder
to
argue as a non-enterprise issue, but there are those of us who find it
easier (and more efficient) to express data manipulation in SQL than in
Ruby, even for our own personal projects. Improved support for DB2 and
Oracle absolutely makes sense, since free versions are available for
non-commercial use and some of us *like* them. Development tools are an
issue for everyone.

There is room for improvement in Ruby, and it is worth improving in
general, not just in the name of enterprise-readiness.

--Greg
Larry W. (Guest)
on 2006-03-29 19:18
(Received via mailing list)
Rails doesn't prevent you from using stored procs. I use them on
Postgres
and haven't had any problems.  Expecting it to be able to automatically
map
from a proc to the object layer seems to me to be unreasonable, since
procs
can do anything and everything and not just CRUD.

There are a number of missing ruby features, unicode, i18n, timezone
supt,
etc. that may prevent it's immediate use for certain kinds of enterprise
apps, but the vast majority of enterprise apps are single-language
anyway.
Java's date support was problematic for a long time, as was its
threading.
Ruby will get there, too.

Gregory is right. There's a danger, I think, in trying to improve Ruby
by
making it more Java-like. It needs improvements in both performance and
in
additional functionality, but if you want a Java like language, try
Java.
Ben M. (Guest)
on 2006-03-29 21:11
(Received via mailing list)
Justin F. wrote:
>
Well, it's still generally called a virtual machine (over and over on
that page). And, in
relation to the original poster's point, the interpreted parse tree
approach is generally
less performant than the bytecode approach. At least I've seen some
numbers indicating that.

However, raw speed comparisons don't tell the whole story -- as the Java
world has been
saying for years. I wouldn't go there other than to state that the
anti-VM sentiment is
based on urban legends (and the early JVM performance, which sucked).

b
Michael Schoen (Guest)
on 2006-03-29 22:00
(Received via mailing list)
>> Support for Oracle; while I haven't tried using Oracle with Rails
>> personally, there's enough people having trouble with it to make me
>> suspect that Oracle+Rails might not be a good combination

I'd be interested in hearing any concerns about using Oracle with Rails.
We've been using it for production apps for 6+ months, with no issues.
Giles B. (Guest)
on 2006-03-30 03:01
(Received via mailing list)
On 3/28/06, David J. <removed_email_address@domain.invalid> wrote:
> On Tue, 2006-03-28 at 21:59 -0600, Jason P. wrote:
> > If that's your contention, then why are you posting to the Rails
> > mailing list and not the Ruby mailing list?
> >
> Because someone else started this thread and I thought it looked
> interesting.

you **would** say that! you - you - you JAVA GUY!


--
Giles B.
www.gilesgoatboy.org
Giles B. (Guest)
on 2006-03-30 03:04
(Received via mailing list)
> > The battle for the enterprise is not worth winning, why fight it.
>
> Because if you can win there, you can win anywhere.  In the enterprise,
> you win by making the best bottom line consistently.  You achieve the
> best bottom line through good communication and technical excellence.

Not really. The whole philosophy of Rails is based on the idea that
what's best for some gigantic corporation with eight quadrillion
employees isn't what's best for small businesses. Rails is opinionated
software highly optimized for small business.

That enterprise "thought leader" is a bit of a crackhead, but there
are differences between what extremely large intracorporate
applications require and what most systems need. I'd imagine there are
probably lots of overarchitected enterprise apps that could run on
Rails quite happily, though.

--
Giles B.
www.gilesgoatboy.org
Edward F. (Guest)
on 2006-03-30 03:28
(Received via mailing list)
> The messenger was not slammed because of the message. He was slammed because:
> A) Nobody likes people who proclaim themselves industry leaders when
> ho showed many times that he had marginal programming knowledge
> B) He didn't even seem to have looked at Ruby. His message was full of
> errors and FUD. Even though he tried to hide it later. (ceck out JHH's
> post to see what I am talking about)
>

Yeah--it wasn't so much the message that led me to believe it was
hoax/troll, but some of the (possibly now edited) content.

There were some strange stuff in there that made it smell like
flamebait (and truth be told, all good trolls invoke insecurity via
some level of validity).
David J. (Guest)
on 2006-03-30 05:14
(Received via mailing list)
On Wed, 2006-03-29 at 15:27 -0700, Giles B. wrote:
> On 3/28/06, David J. <removed_email_address@domain.invalid> wrote:
> > On Tue, 2006-03-28 at 21:59 -0600, Jason P. wrote:
> > > If that's your contention, then why are you posting to the Rails
> > > mailing list and not the Ruby mailing list?
> > >
> > Because someone else started this thread and I thought it looked
> > interesting.
>
> you **would** say that! you - you - you JAVA GUY!


:o)   Except when I'm C, or COBOL, or VB, or XSLT, or Pascal, or Object
Pascal (aka Delphi), or Assembly, or NetRexx, or Python, or SQL, or ...
Ian H. (Guest)
on 2006-03-30 05:26
(Received via mailing list)
On 3/29/06, Larry W. <removed_email_address@domain.invalid> wrote:
> Rails doesn't prevent you from using stored procs. I use them on Postgres
> and haven't had any problems.  Expecting it to be able to automatically map
> from a proc to the object layer seems to me to be unreasonable, since procs
> can do anything and everything and not just CRUD.
>

OK, how do you do that?  I keep hearing bits and pieces about how it's
"possible" but no code.

I want to be able to take user input, send it to a postgres function,
and know if it succeeded or failed.  If it failed, I would like to be
able to get at the error message.

I also, in my fantasy dream land, want to take user input, send it to
a set returning function, and use the resulting output.

AFAICT there are no FAQ, Blog entries, tutorials or anything on this.
David J. (Guest)
on 2006-03-30 05:38
(Received via mailing list)
On Wed, 2006-03-29 at 15:21 -0700, Giles B. wrote:
> > > The battle for the enterprise is not worth winning, why fight it.
> >
> > Because if you can win there, you can win anywhere.  In the enterprise,
> > you win by making the best bottom line consistently.  You achieve the
> > best bottom line through good communication and technical excellence.
>
> Not really. The whole philosophy of Rails is based on the idea that
> what's best for some gigantic corporation with eight quadrillion
> employees isn't what's best for small businesses. Rails is opinionated
> software highly optimized for small business.

But, the Ruby and Rails combination is productive and robust enough that
big business is becoming interested in it (hence my own presence on this
list, and that of some others in enterprise computing environments).

>
> That enterprise "thought leader" is a bit of a crackhead, but there
> are differences between what extremely large intracorporate
> applications require and what most systems need.

Even many "bread-and-butter" apps and tools in the enterprise can be
handled by Rails today.  It just can't (yet) handle the heavy hitting
stuff because of a few implementation issues that will be relatively
straightforward (though not necessarily easy) to correct.

> I'd imagine there are
> probably lots of overarchitected enterprise apps that could run on
> Rails quite happily, though.
Overarchitected?  I'm not sure what you mean.  I have seen poorly
architected apps, and apps that solved complex problems, but I have
never seen something that I could truly call overarchitected.  Could you
elaborate?

I agree that many enterprise apps could be built with a fraction of the
lines of code and with better results under rails (than under J2EE), but
there are places where ruby (and rails) just misses the target by a
small margin, in places that you can't easily fake out.  Threading
support is really the core piece that is missing from Ruby that prevents
it from cleaning up in the heavyweight division.

Rails origins with non-compliant backing stores (MySQL) shows in its use
of SQL92 keywords as property names (POSITION is a particular thorn in
the flesh for me at this moment).  People using SQL92 or later compliant
RDBMS' (postgres, firebird, oracle, DB2) cannot use ActiveRecord's
acts_as_list modifier, for example.

These issues are correctable without compromising the viability of Rails
for small systems.  They are not core design issues, they are maturity
issues.
Larry W. (Guest)
on 2006-03-30 06:20
(Received via mailing list)
All the code was generated so it's a bit vague and it's prototype code.
You
would need to clean it up.  Also, I haven't used this code in a while so
no
promises.

I hope you find it helpful.

the short answer is you use the postgresql library
http://wiki.rubyonrails.com/rails/pages/PostgreSQL

then try something like this:

class CountryDao
    def self.get_connection
      DAO.get_connection  # see below
    end

# this returns a single row:
 def self.get(user_id, object_id, get_deleted)
        res = get_connection.exec("select * from get_country(#{user_id},
#{object_id}, #{get_deleted});")
        if res.num_tuples > 0
            country = Country.new()
                populate(country, res, 0)
        else
         raise "not found exception"
        end
        res.clear
        country
    end

# this returns a refcursor
    def self.get_result_set(query_string)
        get_connection.exec("BEGIN;")
         result = get_connection.query(query_string)
         refcursor_name = result[0].to_s
         res = get_connection.query("FETCH ALL IN
\"#{refcursor_name}\";")
         get_connection.exec("COMMIT;")
         res
    end


    def self.populate(object, result_set, row_number)
             object.object_id =  result_set.getvalue(row_number ,0)
            object.updated_by =  result_set.getvalue(row_number ,1)
            object.updated =  result_set.getvalue(row_number ,2)
            object.deleted =  result_set.getvalue(row_number ,3)
            object.parent_id =  result_set.getvalue(row_number ,4)
            object.name =  result_set.getvalue(row_number ,5)
            object.description =  result_set.getvalue(row_number ,6)

            return object
    end
end

The DAO class looks like this:

require "postgres"

class DAO

    @@conn = PGconn.connect("localhost", 5432, "", "", "Test",
"username",
"password")

    def self.get_connection
      @@conn
    end

end
Gert Thiel (Guest)
on 2006-03-30 13:19
(Received via mailing list)
Hello.

> JRuby (Ruby running under a JVM) is actually very interesting to us, but
> it is about 80 bugs away from being ready for active consideration.
> JRuby offers the internationalization, threading, and other support that
> regular Ruby does not yet, because the underlying JVM and Java runtime
> classes support them.

Allow me to emphasis this.

JRuby has the potential to rock Ruby on Rails like RoR rocked Ruby!
                                             <http://jruby.sourceforge.net/>

To be enterprise-ready means _integration_. Consider the impact of
Apache
XML stack including Cocoon, JCR, JDBC, JTA, Hibernate and Unicode
available
to RoR.
                                                    <http://xml.apache.org/>

To be enterprise-ready means _reliable application servers_. Consider
RoR on
the cluster-ready JBoss microkernel.
                         <http://labs.jboss.com/portal/jbossas/architecture>

Only to name a very few :-) Remember that J2EE is not just EJB.
          <http://en.wikipedia.org/wiki/Java_Platform%2C_Ente...
                       <http://de.wikipedia.org/wiki/Bild:J2ee-overview.png>
                                 German:
<http://de.wikipedia.org/wiki/J2EE>

BTW: You could integrate RoR with J2EE using Hessian. This is the better
approach if you need Ruby libraries that depend on native shared
libraries.
                      <http://wiki.caucho.com/Hessian_-_Ruby_implementation>
                               <http://jruby.sourceforge.net/docs/faq.shtml>

I can't wait for the second birth of Ruby on Rails.

Regards,

  Gert Thiel
Michael S. (Guest)
on 2006-03-30 16:51
(Received via mailing list)
On Thursday 30 March 2006 03:35, David J. wrote:
> Rails origins with non-compliant backing stores (MySQL) shows in its
> use of SQL92 keywords as property names (POSITION is a particular
> thorn in the flesh for me at this moment).  People using SQL92 or
> later compliant RDBMS' (postgres, firebird, oracle, DB2) cannot use
> ActiveRecord's acts_as_list modifier, for example.

I probably don't understand your problem, but I have columns
named "position" in several of my tables and PostgreSQL (8.0.x) works
just fine with this.

Michael

--
Michael S.
mailto:removed_email_address@domain.invalid
http://www.schuerig.de/michael/
Michael S. (Guest)
on 2006-03-30 17:06
(Received via mailing list)
On Thursday 30 March 2006 11:18, Gert Thiel wrote:

> JRuby has the potential to rock Ruby on Rails like RoR rocked Ruby!

Somehow I don't see this.

> To be enterprise-ready means _integration_. Consider the impact of
> Apache XML stack including Cocoon, JCR, JDBC, JTA, Hibernate and
> Unicode available to RoR.

And that's so great? If you need all this stuff, why not just use
Java/J2EE, maybe with a healthy dose of Spring thrown in, from the
start? If you don't like Java-the-language, well, then go for Groovy.

> To be enterprise-ready means _reliable application servers_. Consider
> RoR on the cluster-ready JBoss microkernel.

I take it that this would require a complete rewrite of Rails.

I agree wholeheartedly that interoperability is important. I don't agree
on the assumed means to achieve it. Has the SOA ideal/fad died already?
Rails can nicely interoperate on the level of services. There's really
no need to absorb it into Java.

Michael

--
Michael S.
mailto:removed_email_address@domain.invalid
http://www.schuerig.de/michael/
Gregory S. (Guest)
on 2006-03-30 19:21
(Received via mailing list)
On Wed, Mar 29, 2006 at 07:35:21PM -0600, David J. wrote:
} On Wed, 2006-03-29 at 15:21 -0700, Giles B. wrote:
[...]
} > I'd imagine there are probably lots of overarchitected enterprise
apps
} > that could run on Rails quite happily, though.
}
} Overarchitected?  I'm not sure what you mean.  I have seen poorly
} architected apps, and apps that solved complex problems, but I have
never
} seen something that I could truly call overarchitected.  Could you
} elaborate?
[...]

I will give an example of an overarchitected app. This is not a web app,
but rather a .NET thick client. The names of the various companies
involved
are withheld to protect my butt. Basically, the project is in-house,
mission-critical software. It is backed by several large databases, and
performs a variety of data entry, manipulation, cleaning, crunching, and
reporting functions.

The basis of this application is the almighty framework. In this
application, there are persisted objects which are all represented in a
single table with universally relevant information like parent object,
plus
side join tables for specific types. Loading and saving is handled
automagically by the framework. All such objects exist in memory as an
instance object which holds onto an ADO.NET typed dataset.

All screens (and partial screens) must be implemented as subclasses of a
particular framework class, which does framework magic with the
persisted
objects. Screens are actually shown to the user in nested tabs and
stacks
and popups and such based on a database representation of how the pieces
fit together. For each (partial) screen a user will see, there is an
automagically-handled persisted object (AHPO from here on) which
specifies
which class to load from which DLL, to what type of AHPO it is
conceptually
attached, its title, etc. Of course, it may be a container screen for
other
screens, in which case it has no DLL or class itself, just child
screens.
And you can have another variant that just points to a screen but with
slight changes. All this information about screens makes it possible for
many controls, based on their names, to automagically bind to the
appropriate data value.

Constants are held in the database as well. There are these items with a
unique number, a short name, a longer name, an ordering value, and
several
additional fields for extra information. They belong to some primary
group
of items, but they can belong to more than one group. In the additional
groups, the long name (but nothing else) can be overridden. These are
used
for various automagical dropdowns.

When first working with this framework, it seemed like it took care of a
whole lot of stuff for you, and the idea of separating out as much
functionality as data rather than code was appealing. Eventually,
though,
it becomes clear that the app spends so much time on framework magic
that
actual user interaction suffers. The system is painfully slow. It must
be
deployed on terminal services so that the system running the app can be
on
a gigabit link to the database server because so much data has to be
read
by the app to accomplish anything, and so much data gets persisted when
the
user does anything.

This is what it means to be overarchitected. The system is full of
beautiful design ideals, but doesn't actually get the job done well.
Their
may be development and maintenance gains, but they are hidden by the
development costs (new developers require months of ramp-up time, which
can
also lead to staffing problems) and the cost of lost user productivity
as
the users wait for the system to respond.

--Greg
Ben M. (Guest)
on 2006-03-30 20:00
(Received via mailing list)
Michael S. wrote:
> And that's so great? If you need all this stuff, why not just use
> Java/J2EE, maybe with a healthy dose of Spring thrown in, from the
> start? If you don't like Java-the-language, well, then go for Groovy.

It's just more powerful than either straight Java or straight Ruby.
Groovy is just an
attempt to write Ruby-esque code in the JVM. JRuby would likely render
it pointless. But
actually, Java 6 will probably render both JRuby and Groovy pointless:
it will support
running several dynamic languages (PHP, Javacript, Ruby, etc.) within
the JVM and straight
from Java code.

>>To be enterprise-ready means _reliable application servers_. Consider
>>RoR on the cluster-ready JBoss microkernel.
>
>
> I take it that this would require a complete rewrite of Rails.

NO. That would be stupid. The whole goal is to be able to run Ruby code,
unmodified, in
the JVM.

> I agree wholeheartedly that interoperability is important. I don't agree
> on the assumed means to achieve it. Has the SOA ideal/fad died already?
> Rails can nicely interoperate on the level of services. There's really
> no need to absorb it into Java.

The goal is not to "absorb Ruby into Java". The goal is to allow even
closer
interoperation than services allow. There is nothing to fear in this and
everything to be
gained.

b
Michael S. (Guest)
on 2006-03-30 20:58
(Received via mailing list)
On Thursday 30 March 2006 18:00, Ben M. wrote:
> The goal is not to "absorb Ruby into Java". The goal is to allow even
> closer interoperation than services allow. There is nothing to fear
> in this and everything to be gained.

What I'm wondering about is, whether Rails will survive unscathed all
the changes it may have to endure in the name of close interoperation
with Java and enterprise readiness.

From my point of view, enterprise readiness is not the be-all and
end-all of every piece of software. There's life outside the
enterprise. And there's fully legitimate software development going on
outside the enterprise. My impression is that Rails has its focus there
and I'd like it to remain there.

Michael

--
Michael S.
mailto:removed_email_address@domain.invalid
http://www.schuerig.de/michael/
Charles O Nutter (Guest)
on 2006-03-30 22:48
(Received via mailing list)
I just stumbled across this thread, and figured I should inject a few
opinions. I am one of two active developers on JRuby, where my main
charge
has been the redesign of the core interpreter and planning for various
stages of compilation. I also recently got IRB and Rails' generate
script
working, and I'm currently focused on optimizing the interpreter a bit
before we present JRuby at JavaOne. I'll try to address some of the
issues
people have brought up:

1. Java is slow
I had thought this myth was entirely debunked, but as others have
commented
Java is nothing like slow. In certain scenarios there's a bit more
overhead
than on "hand-optimized assembler code" but then you probably aren't
going
to hand optimize a million lines of assembly either. Java is actually,
in
many cases, faster than compiled C code, owing to its ability to
optimize
and re-optimize code based on usage patterns. There's never just one way
to
optimize a code path, and the mixed-mode compilation Java does while
running
allows it to exceed native code frequently. Take a look at any of the
typical language shootouts or performance benchmarks. On equivalent
algorithms, Java is extremely fast...in many, many cases far faster than
the
current Ruby code.

The following benchmark shows Java beating Ruby by an order of magnitude
in
almost every case, though it frequently uses more memory to do it:

http://shootout.alioth.debian.org/debian/benchmark...

Even if the benchmark is flawed, it's hard to argue that an optimized
Ruby
implementation on the JVM would necessarily be slower.

2. Enterprise is a loaded term that isn't important

I agree. Enterprise has become as meaningless as SOA, Middleware, and
their
ilk. However, the concepts behind the word (or the concepts I'd like to
believe are behind the word) are very important.

"Enterprise Java" has come to mean many things to many people. If you
equate
Enterprise with Enterprise Java Beans, then you're selling the platform
short. EJBs may have been initially compelling, but their verbosity and
complexity have doomed them to ridicule. Don't write off the entire
platform, however. The Java Transaction API has made cross-request and
even
cross-server transactions trivial to handle. Enlisting n remote servers
into
a larger transaction is handled transparently. The Java Message Service
has
provided a simple, reliable, cross-platform and cross-server means of
handling asynchronous communications. It really "just works" and
provides
huge benefits for long-running processes and offline transactions. Java
Management Extensions, while not officially part of Enterprise Java,
provide
consistent, uniform remote administration and management capabilities,
along
with managed, monitored services throughout an application cluster. And
while we're on that topic, clustering, failover, and session replication
within typical Enterprise Java clusters "just works" too. I won't even
go
into JDBC, perhaps the most impressive cross-platform and cross-database
SQL
api that exists.

I am by day officially a "J2EE Architect", though my eventual role has
me
mostly escorting other developers through the pain of writing J2EE
applications and trying to find better tools, frameworks, and patterns
to
make that process simpler. I feel all the typical pain of J2EE
developers,
and I agree there are bad areas...but don't throw the baby out with the
bathwater.

3. Bringing Ruby and Rails to Java will somehow corrupt Ruby and Rails

The goal of JRuby is to create a fast Ruby interpreter that looks,
feels,
and acts just like Ruby. We will not require any modifications to Ruby
(and
in fact we run with Ruby's own lib/ruby/1.8 libraries), and we only
reimplement specific features where the Ruby equivalent doesn't consider
Java's capabilities or where Ruby implements those features in C. A
similar
argument goes for Rails: Rails must be able to run without modification
under JRuby, albeit behind a "mock CGI" Servlet that can simulate
running
with fastcgi and friends.

What we do hope to provide is a way to access Java's good features from
within Rails. JDBC is an obvious match for ActiveRecord, and JTA can
provide
transaction support seamlessly. Once inside a J2EE cluster, we can also
enable replication and failover for Rails sessions and requests by
wiring
those subsystems into those provided by the cluster. We can wire JMS
into
available messaging libraries for Ruby, allowing Rails to submit jobs to
any
JMS-aware server (which ultimately could mean any messaging server,
since
most of them support JMS). The list goes on and on.

It is true, and must be accepted, that while Ruby the language is a
marvelous, beautiful thing, Ruby the platform still has some growing up
to
do. Unicode support is partial and inconsistent. Support for
locale-specific
calendars, messages, and behaviors is nowhere near what Java provides.
Integration with other languages and other platforms is sketchy at best.
Ruby simply lacks many features that would help it gain acceptance as
more
than "just another scripting language." I'm certain Ruby will get
everything
it's missing over time, but by putting Ruby and Rails on the JVM we may
be
able to have them now. Who knows, perhaps the APIs that develop out of
Ruby
on the JVM will filter back into the design process for future versions
of
Ruby.

4. My plan for JRuby (though just one view of where we're going)

I will try to lay out briefly the current plan for JRuby.

- We are currently working very hard to get Rails running for a simple
case.
The generate script already works and generates usable code and
configuration. The next step is getting Rails to handle a request. We
currently get pretty far into that process before things bomb out, and
expect to have it working by the end of this month.
- JRuby is, despite Java's speed, quite slow right now. The original
author
just did a simple port of Ruby's C code to what it would look like in
Java,
and as a result many JVM features that could speed Ruby up were crippled
or
impossible to utilize. My work recently has been to completely rewrite
and
rewire the internals of JRuby to enable compilation to Java bytecode,
full
continuations support, tail-call optimization, and multi-VM (running
multiple "Rubies" inside the same JVM). All of these will help improve
performance, and we hope to exceed Ruby 1.8 performance at some point.

I would welcome any questions or comments. Our main goal with JRuby is
to
provide a real Ruby environment that happens to be running on the JVM,
and
to enable Ruby code to integrate with Java code whereever it is useful
to do
so. We would be as happy as you all if Ruby were to supplant Java as the
language-of-choice, and if JRuby helps further that goal...all the
better.
Bill W. (Guest)
on 2006-03-30 23:22
(Received via mailing list)
Charles,

Informative and exciting post.  Thank you for it and for your work on
JRuby.  I look forward to it.

Best regards,
Bill
  ----- Original Message -----
  From: Charles O Nutter
  To: removed_email_address@domain.invalid
  Sent: 2006-03-30 12:46 PM
  Subject: Re: [Rails] Re: Is this an elaborate hoax/troll?


  I just stumbled across this thread, and figured I should inject a few
opinions. I am one of two active developers on JRuby, where my main
charge has been the redesign of the core interpreter and planning for
various stages of compilation. I also recently got IRB and Rails'
generate script working, and I'm currently focused on optimizing the
interpreter a bit before we present JRuby at JavaOne. I'll try to
address some of the issues people have brought up:

  1. Java is slow
  I had thought this myth was entirely debunked, but as others have
commented Java is nothing like slow. In certain scenarios there's a bit
more overhead than on "hand-optimized assembler code" but then you
probably aren't going to hand optimize a million lines of assembly
either. Java is actually, in many cases, faster than compiled C code,
owing to its ability to optimize and re-optimize code based on usage
patterns. There's never just one way to optimize a code path, and the
mixed-mode compilation Java does while running allows it to exceed
native code frequently. Take a look at any of the typical language
shootouts or performance benchmarks. On equivalent algorithms, Java is
extremely fast...in many, many cases far faster than the current Ruby
code.

  The following benchmark shows Java beating Ruby by an order of
magnitude in almost every case, though it frequently uses more memory to
do it:

  http://shootout.alioth.debian.org/debian/benchmark...

  Even if the benchmark is flawed, it's hard to argue that an optimized
Ruby implementation on the JVM would necessarily be slower.

  2. Enterprise is a loaded term that isn't important

  I agree. Enterprise has become as meaningless as SOA, Middleware, and
their ilk. However, the concepts behind the word (or the concepts I'd
like to believe are behind the word) are very important.

  "Enterprise Java" has come to mean many things to many people. If you
equate Enterprise with Enterprise Java Beans, then you're selling the
platform short. EJBs may have been initially compelling, but their
verbosity and complexity have doomed them to ridicule. Don't write off
the entire platform, however. The Java Transaction API has made
cross-request and even cross-server transactions trivial to handle.
Enlisting n remote servers into a larger transaction is handled
transparently. The Java Message Service has provided a simple, reliable,
cross-platform and cross-server means of handling asynchronous
communications. It really "just works" and provides huge benefits for
long-running processes and offline transactions. Java Management
Extensions, while not officially part of Enterprise Java, provide
consistent, uniform remote administration and management capabilities,
along with managed, monitored services throughout an application
cluster. And while we're on that topic, clustering, failover, and
session replication within typical Enterprise Java clusters "just works"
too. I won't even go into JDBC, perhaps the most impressive
cross-platform and cross-database SQL api that exists.

  I am by day officially a "J2EE Architect", though my eventual role has
me mostly escorting other developers through the pain of writing J2EE
applications and trying to find better tools, frameworks, and patterns
to make that process simpler. I feel all the typical pain of J2EE
developers, and I agree there are bad areas...but don't throw the baby
out with the bathwater.

  3. Bringing Ruby and Rails to Java will somehow corrupt Ruby and Rails

  The goal of JRuby is to create a fast Ruby interpreter that looks,
feels, and acts just like Ruby. We will not require any modifications to
Ruby (and in fact we run with Ruby's own lib/ruby/1.8 libraries), and we
only reimplement specific features where the Ruby equivalent doesn't
consider Java's capabilities or where Ruby implements those features in
C. A similar argument goes for Rails: Rails must be able to run without
modification under JRuby, albeit behind a "mock CGI" Servlet that can
simulate running with fastcgi and friends.

  What we do hope to provide is a way to access Java's good features
from within Rails. JDBC is an obvious match for ActiveRecord, and JTA
can provide transaction support seamlessly. Once inside a J2EE cluster,
we can also enable replication and failover for Rails sessions and
requests by wiring those subsystems into those provided by the cluster.
We can wire JMS into available messaging libraries for Ruby, allowing
Rails to submit jobs to any JMS-aware server (which ultimately could
mean any messaging server, since most of them support JMS). The list
goes on and on.

  It is true, and must be accepted, that while Ruby the language is a
marvelous, beautiful thing, Ruby the platform still has some growing up
to do. Unicode support is partial and inconsistent. Support for
locale-specific calendars, messages, and behaviors is nowhere near what
Java provides. Integration with other languages and other platforms is
sketchy at best. Ruby simply lacks many features that would help it gain
acceptance as more than "just another scripting language." I'm certain
Ruby will get everything it's missing over time, but by putting Ruby and
Rails on the JVM we may be able to have them now. Who knows, perhaps the
APIs that develop out of Ruby on the JVM will filter back into the
design process for future versions of Ruby.

  4. My plan for JRuby (though just one view of where we're going)

  I will try to lay out briefly the current plan for JRuby.

  - We are currently working very hard to get Rails running for a simple
case. The generate script already works and generates usable code and
configuration. The next step is getting Rails to handle a request. We
currently get pretty far into that process before things bomb out, and
expect to have it working by the end of this month.
  - JRuby is, despite Java's speed, quite slow right now. The original
author just did a simple port of Ruby's C code to what it would look
like in Java, and as a result many JVM features that could speed Ruby up
were crippled or impossible to utilize. My work recently has been to
completely rewrite and rewire the internals of JRuby to enable
compilation to Java bytecode, full continuations support, tail-call
optimization, and multi-VM (running multiple "Rubies" inside the same
JVM). All of these will help improve performance, and we hope to exceed
Ruby 1.8 performance at some point.

  I would welcome any questions or comments. Our main goal with JRuby is
to provide a real Ruby environment that happens to be running on the
JVM, and to enable Ruby code to integrate with Java code whereever it is
useful to do so. We would be as happy as you all if Ruby were to
supplant Java as the language-of-choice, and if JRuby helps further that
goal...all the better.

  --
  Charles Oliver N. @ headius.blogspot.com
  JRuby Developer @ jruby.sourceforge.net
  Application Architect @ www.ventera.com


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


  _______________________________________________
  Rails mailing list
  removed_email_address@domain.invalid
  http://lists.rubyonrails.org/mailman/listinfo/rails
Giles B. (Guest)
on 2006-03-30 23:40
(Received via mailing list)
fwiw, the Jython effort -- similar to JRuby -- has had a good effect
on the Python community, especially in that it forced Guido von Rossum
to answer some pretty challenging questions about which features of
Python were language features and which were merely features of the
interpreter.

I code Java at work too, although I'd rather be using Rails, but it's
true to some extent that with Java there is a baby in all that
bathwater.

I still think James McGovern's on crack, though.

On 3/30/06, Bill W. <removed_email_address@domain.invalid> wrote:
>
> working, and I'm currently focused on optimizing the interpreter a bit
> optimize a code path, and the mixed-mode compilation Java does while running
> Even if the benchmark is flawed, it's hard to argue that an optimized Ruby
> short. EJBs may have been initially compelling, but their verbosity and
> while we're on that topic, clustering, failover, and session replication
>
>
> marvelous, beautiful thing, Ruby the platform still has some growing up to
> 4. My plan for JRuby (though just one view of where we're going)
> and as a result many JVM features that could speed Ruby up were crippled or
> language-of-choice, and if JRuby helps further that goal...all the better.
>
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>


--
Giles B.
www.gilesgoatboy.org
Stephen B. (Guest)
on 2006-03-30 23:53
(Received via mailing list)
I have a builder template that renders a Java webstart jnlp file.
Right now I am creating the the jnlp file links like this:

   link_to 'Run', :action => 'jnlp', :id => activity

Which creates links like this:

   http://host.com/controller/jnlp/1

The action looks like this:

   def jnlp
     @headers["Content-Type"] = "application/x-java-jnlp-file"
     @headers["Cache-Control"] = "public"
     @activity = Activity.find(params[:id])
     render :layout => false
   end

Which implicitly calls the Builder view: jnlp.rxml

By setting the Content-Type in the http headers most browsers
correctly interpret the file "1" as a jnlp file and if Java is
installed start the webstart application. However FireFox on MacOS
seems to require that the file actually be served with the ".jnlp"
filename suffix.

So I'd like to instead create links like this:

   http://host.com/controller/jnlp/1.jnlp

The general question is: how can I concatenate a static filename
suffix to a link?

Thanks!
Justin F. (Guest)
on 2006-03-30 23:56
(Received via mailing list)
Charles O Nutter wrote:
> commented Java is nothing like slow. In certain scenarios there's a bit
> The following benchmark shows Java beating Ruby by an order of magnitude
> I agree. Enterprise has become as meaningless as SOA, Middleware, and
> transparently. The Java Message Service has provided a simple, reliable,
>
> feels, and acts just like Ruby. We will not require any modifications to
> can also enable replication and failover for Rails sessions and requests
> sketchy at best. Ruby simply lacks many features that would help it gain
> - We are currently working very hard to get Rails running for a simple
> optimization, and multi-VM (running multiple "Rubies" inside the same
> JVM). All of these will help improve performance, and we hope to exceed
> Ruby 1.8 performance at some point.
>
> I would welcome any questions or comments. Our main goal with JRuby is
> to provide a real Ruby environment that happens to be running on the
> JVM, and to enable Ruby code to integrate with Java code whereever it is
> useful to do so. We would be as happy as you all if Ruby were to
> supplant Java as the language-of-choice, and if JRuby helps further that
> goal...all the better.

Beautifully put. (My day job is a bit like yours.)

Regarding your last point, I expect that JRuby will always benefit from
giving users the ability to drop down into Java, just as CRuby benefits
from allowing users to drop down into C.

thanks for your excellent work

   Justin
Charles O Nutter (Guest)
on 2006-03-31 00:05
(Received via mailing list)
I agree with the McGovern thing, btw. At least, I think I do...it was
hard
to understand what he was trying to say with so many spelling, grammar,
and
logic mistakes.

I blogged a few responses, if anyone's interested in reading a few more:

http://headius.blogspot.com/2006/03/enterprise-sou...
Rob S. (Guest)
on 2006-03-31 01:59
(Received via mailing list)
On 3/30/06, Charles O Nutter <removed_email_address@domain.invalid> wrote:
> I just stumbled across this thread, and figured I should inject a few
[snip]
>
> --
> Charles Oliver N. @ headius.blogspot.com
> JRuby Developer @ jruby.sourceforge.net
> Application Architect @ www.ventera.com


Thanks for this great post, Charles.  Thanks especially for dispelling
the "java is slow" myth that just will not die, and was getting thrown
around a bit earlier.

- Rob
--
http://www.robsanheim.com/
http://www.ajaxian.com/
Jón B. (Guest)
on 2006-03-31 02:50
(Received via mailing list)
>
> Thanks for this great post, Charles.  Thanks especially for dispelling
> the "java is slow" myth that just will not die, and was getting thrown
> around a bit earlier.

I don't know about the speed in web service application. But most
people get the "java is slow" thing from java desktop applications.
Which are utterly useless and famous for being unresponsive and I have
never seen a good java desktop application.

However comparing a compiled java application with an uncompiled ruby
application as was pointed out in a chart earlier is strange. It's
strange to say that the solution would be to run ruby in java instead
of just making a ruby compiler.

I'm just afraid that hereafter there will be 2 version of ruby. One
real and one in java.


--
Charles O Nutter (Guest)
on 2006-03-31 03:08
(Received via mailing list)
I understand that perspective, but our goal is to run Ruby apps as well
as
Ruby does, without modification. In other words, we want to run whatever
the
C implementation can, as much as possible. We're not about to try
forking
the language or "embracing and extending" it, Microsoft-style.

As for the compiler question...the current work being done on a Ruby
compiler does not, I'm sorry to say, compile Ruby down to native code.
It
compiles it into bytecode, just like Java, and the new Ruby VM then
executes
that bytecode. It promises considerable performance improvements in some
areas, but since it will be layer on top of the existing implementation
it
will only provide limited improvements in others. It's excellent work,
but
it's important that when Rubyists refer to the new "compiler" they
understand that it is a bytecode compiler.

What, then, is the harm in writing a compiler to turn Ruby into Java
bytecodes? The Java VM is well-established and has shown its potential.
It
performs extremely well, considering object allocation, garbage
collection,
and native threads are all provided out-of-the-box. It is also very
stable,
widely-deployed, and supported on many platforms. I think Ruby on the
JVM is
a sure win, both both the Java and Ruby worlds.

Want more justification? There are at least three projects going right
now
to make Ruby for the .NET CLR...I'd certainly hate to see Microsoft
corner
the market on VM-based Ruby, how bout you?
Roberto S. (Guest)
on 2006-03-31 03:14
(Received via mailing list)
>
> I don't know about the speed in web service application. But most
> people get the "java is slow" thing from java desktop applications.
> Which are utterly useless and famous for being unresponsive and I have
> never seen a good java desktop application.


I consider eclipse as a good java desktop application, nevertheless,
starting a JVM is expensive in terms of memory consumption and  process
cycles.

However comparing a compiled java application with an uncompiled ruby
> application as was pointed out in a chart earlier is strange. It's
> strange to say that the solution would be to run ruby in java instead
> of just making a ruby compiler.


Well, for the Ruby compiler, there is YARV which is supposed to compile
ruby
2.0.0

I'm just afraid that hereafter there will be 2 version of ruby. One
> real and one in java.


The java ruby version probably will just be used for special cases (one
interesting example:  together with red5 <http://www.osflash.org/red5>
Flash
streaming media server)
 --
Roberto S. - http://rsaccon.com
Rob S. (Guest)
on 2006-03-31 04:34
(Received via mailing list)
On 3/30/06, Jon Gretar B. <removed_email_address@domain.invalid> wrote:
> >
> > Thanks for this great post, Charles.  Thanks especially for dispelling
> > the "java is slow" myth that just will not die, and was getting thrown
> > around a bit earlier.
>
> I don't know about the speed in web service application. But most
> people get the "java is slow" thing from java desktop applications.
> Which are utterly useless and famous for being unresponsive and I have
> never seen a good java desktop application.
>

This used to be the case, but Swing and SWT have come a long way.
Take a look at SmartCVS, Eclipse, Azureus, etc.  They may use a lot of
resources and be hard to develop, but they aren't necessarily slow. :)

Anyways, back to Ruby...
- rob
--
http://www.robsanheim.com/
http://www.ajaxian.com/
Jón B. (Guest)
on 2006-03-31 05:10
(Received via mailing list)
On 3/31/06, Rob S. <removed_email_address@domain.invalid> wrote:

>
> This used to be the case, but Swing and SWT have come a long way.
> Take a look at SmartCVS, Eclipse, Azureus, etc.  They may use a lot of
> resources and be hard to develop, but they aren't necessarily slow. :)
>
Actually... I hate to use both Eclipse and Azureus. Those are not slow
in the processing part. But simple things like resizing the window or
dragging seperators is intolerable. It's like having the monitor
working on 5 frames a second. And that is just wasting valuable time
and intolerable in an IDE.

And they don't take a lot of resources.... The take A LOT of
resources. Having Azureus running made my laptop unusable since it
only has 512mb.


--
David J. (Guest)
on 2006-03-31 07:02
(Received via mailing list)
To me, that sounds to me more like failure to understand the concept of
architecture than over-architecting.  Architecture should be about
making the programmer's life easier by making the the processes cleaner
and more obvious.  This framework you describe is forcing programming by
side effect, which is always a bad idea.

An architecture is a wonderful servant, but a terrible master.

I hate programming by side effect.  It leads to misuse of the platform
and odd behaviors when people unwittingly trigger event loops.  I spent
5 years straightening out one of those messes.

I understand your pain - I have seen similar situations.  I am fortunate
to be senior enough to get away with saying "that won't work here
because ..." and having the leeway to do things right.

A lot of times, the degree of dynamism you describe is actually a result
of a failure to understand the problem space fully.  That does not mean
spending a bazillion hours poring over some nimnul's powerpoint
presentations.  It means recognizing that complex solutions generally
mean that you don't understand the problem yet, and striving for a
simpler solution that encompasses the entire problem space.

In general, it really is easier to solve the entire problem than to
solve just bits and pieces.  Special conditions (even if they are
embodied in framework side effects) are generally a sign that something
is not understood fully yet.  This is true whether it is J2EE,
Rails, .not (sorry - .net), or even lowly COBOL.
Gregory S. (Guest)
on 2006-03-31 16:29
(Received via mailing list)
On Thu, Mar 30, 2006 at 10:47:19PM +0000, Jon Gretar B. wrote:
[...]
} I don't know about the speed in web service application. But most
} people get the "java is slow" thing from java desktop applications.
} Which are utterly useless and famous for being unresponsive and I have
} never seen a good java desktop application.
[...]

I used a good Java desktop application some years ago. It was the DB2
administration application, and I was pretty pleased with it. I also
wrote
a very simple one that worked nicely. That said, I've used numerous Java
applications that completely failed to impress me with their
responsiveness, including Azureus and Eclipse.

} Jon Gretar B.
--Greg
Gregory S. (Guest)
on 2006-03-31 17:55
(Received via mailing list)
On Thu, Mar 30, 2006 at 09:01:55PM -0600, David J. wrote:
} To me, that sounds to me more like failure to understand the concept
of
} architecture than over-architecting.  Architecture should be about
making
} the programmer's life easier by making the the processes cleaner and
more
} obvious.  This framework you describe is forcing programming by side
} effect, which is always a bad idea.

I don't know that it's *always* a bad idea, but too much of it certainly
gets frustrating.

} An architecture is a wonderful servant, but a terrible master.
[...]

...and I think that is an excellent definition of overarchitecting.
Overarchitecture means that developers spend more time satisfying the
framework's demands than the system requirements.

} A lot of times, the degree of dynamism you describe is actually a
result
} of a failure to understand the problem space fully.  That does not
mean
} spending a bazillion hours poring over some nimnul's powerpoint
} presentations.  It means recognizing that complex solutions generally
} mean that you don't understand the problem yet, and striving for a
} simpler solution that encompasses the entire problem space.

Oh, I completely left out the management issues that led to this. The
project began (years before I got involved) with large chunks of the
system
being pushed into development before requirements had been written, and
the
framework was developed concurrently with them. It is only within the
last
year that the framework has stabilized and the developers have stood
their
ground on not starting to code without solid requirements.

} In general, it really is easier to solve the entire problem than to
} solve just bits and pieces.  Special conditions (even if they are
} embodied in framework side effects) are generally a sign that
something
} is not understood fully yet.  This is true whether it is J2EE,
} Rails, .not (sorry - .net), or even lowly COBOL.

It would be lovely if a high-level list of desired features for the
system
were available to developers. If such a thing exists, it certainly isn't
available to us nor to the architect who built the framework. Without
knowing what is planned, it's hard to be abstract in the right places
and
concrete in the others.

I experienced a similar issue in my first real job. I was tasked with
building a new simulation and visualization frontend (in C++) for an AI
engine. I was not told what future use the frontend might be put to,
only
that the existing one was too hardcoded. I wound up writing a
magnificently
abstract MVC system full of clean interfaces that was loosely coupled
and
automatically registered interface implementations at load time and
instantiated objects based on a simple XML file format. It was a thing
of
beauty. It was also too complicated for the owner of the project to
understand (granted, he hadn't learned how to use any feature of C++
that
wasn't supported by g++ circa 1990), yet too restrictive to make it easy
to
split the UI and the simulation into separate threads easily.

If they'd just talk to us, we could do what they need. But they never
do.

--Greg

} On Thu, 2006-03-30 at 10:17 -0500, Gregory S. wrote:
} > On Wed, Mar 29, 2006 at 07:35:21PM -0600, David J. wrote:
} > } On Wed, 2006-03-29 at 15:21 -0700, Giles B. wrote:
} > [...]
} > } > I'd imagine there are probably lots of overarchitected
enterprise apps
} > } > that could run on Rails quite happily, though.
} > }
} > } Overarchitected?  I'm not sure what you mean.  I have seen poorly
} > } architected apps, and apps that solved complex problems, but I
have never
} > } seen something that I could truly call overarchitected.  Could you
} > } elaborate?
} > [...]
} >
} > I will give an example of an overarchitected app. This is not a web
app,
} > but rather a .NET thick client. The names of the various companies
involved
} > are withheld to protect my butt. Basically, the project is in-house,
} > mission-critical software. It is backed by several large databases,
and
} > performs a variety of data entry, manipulation, cleaning, crunching,
and
} > reporting functions.
} >
} > The basis of this application is the almighty framework. In this
} > application, there are persisted objects which are all represented
in a
} > single table with universally relevant information like parent
object, plus
} > side join tables for specific types. Loading and saving is handled
} > automagically by the framework. All such objects exist in memory as
an
} > instance object which holds onto an ADO.NET typed dataset.
} >
} > All screens (and partial screens) must be implemented as subclasses
of a
} > particular framework class, which does framework magic with the
persisted
} > objects. Screens are actually shown to the user in nested tabs and
stacks
} > and popups and such based on a database representation of how the
pieces
} > fit together. For each (partial) screen a user will see, there is an
} > automagically-handled persisted object (AHPO from here on) which
specifies
} > which class to load from which DLL, to what type of AHPO it is
conceptually
} > attached, its title, etc. Of course, it may be a container screen
for other
} > screens, in which case it has no DLL or class itself, just child
screens.
} > And you can have another variant that just points to a screen but
with
} > slight changes. All this information about screens makes it possible
for
} > many controls, based on their names, to automagically bind to the
} > appropriate data value.
} >
} > Constants are held in the database as well. There are these items
with a
} > unique number, a short name, a longer name, an ordering value, and
several
} > additional fields for extra information. They belong to some primary
group
} > of items, but they can belong to more than one group. In the
additional
} > groups, the long name (but nothing else) can be overridden. These
are used
} > for various automagical dropdowns.
} >
} > When first working with this framework, it seemed like it took care
of a
} > whole lot of stuff for you, and the idea of separating out as much
} > functionality as data rather than code was appealing. Eventually,
though,
} > it becomes clear that the app spends so much time on framework magic
that
} > actual user interaction suffers. The system is painfully slow. It
must be
} > deployed on terminal services so that the system running the app can
be on
} > a gigabit link to the database server because so much data has to be
read
} > by the app to accomplish anything, and so much data gets persisted
when the
} > user does anything.
} >
} > This is what it means to be overarchitected. The system is full of
} > beautiful design ideals, but doesn't actually get the job done well.
Their
} > may be development and maintenance gains, but they are hidden by the
} > development costs (new developers require months of ramp-up time,
which can
} > also lead to staffing problems) and the cost of lost user
productivity as
} > the users wait for the system to respond.
} >
} > --Greg
} >
} > _______________________________________________
} > Rails mailing list
} > removed_email_address@domain.invalid
} > http://lists.rubyonrails.org/mailman/listinfo/rails
}
}
Stephen B. (Guest)
on 2006-03-31 20:31
(Received via mailing list)
I found an answer (Piers C. helped).

Most of you probably already know this but just in case someone is
reading or searching the list archive and would like to know:

The routes in config/routes.rb are TWO-WAY, mapping incoming url
requests AND used as the template to generate urls by the app. Of
course now looking back it is obvious that it has to work that way.

Adding this to the routes.rb map:

   map.jnlp 'page/jnlp/:id/activity.jnlp', :controller => 'page',
:action => 'jnlp'

Not only handles parsing this incoming url:

   http://localhost:3000/page/jnlp/1/activity.jnlp

But the map also is used when interpreting this code in a
PageController view to produce the same url:

   link_to 'Run', :action => 'jnlp', :id => activity

What I'd like to do now is figure out how to combine the :id number
and the static text 'activity.jnlp' so that the url can end in:

     /activity1.jnlp

This doesn't work, it is not parsed correctly:

   map.jnlp 'page/jnlp/activity' + :id + '.jnlp', :controller =>
'page', :action => 'jnlp'

And this doesn't work:

   map.jnlp "page/jnlp/:id/activity#{:id}.jnlp", :controller =>
'page', :action => 'jnlp'

It produces:

   http://localhost:3000/page/jnlp/2/activityid.jnlp

I find it interesting reflecting on my process trying to figure this
out. I tried to follow the url_for code in the rails source but I
knew I was missing something. One part was getting my head around all
the meta-programming used in Ruby and Rails and the other was the
fact that as implemented in Rails, routes affect both halves of the
url process.
David J. (Guest)
on 2006-04-01 06:39
(Received via mailing list)
On Fri, 2006-03-31 at 08:54 -0500, Gregory S. wrote:

> } An architecture is a wonderful servant, but a terrible master.
> [...]
>
> ...and I think that is an excellent definition of overarchitecting.
> Overarchitecture means that developers spend more time satisfying the
> framework's demands than the system requirements.
>

I can accept that, with reservations.  To me, that still sounds like a
failure to understand architecture at all, with a resulting failure to
architect.  But I can agree to disagree.

> framework was developed concurrently with them. It is only within the last
> year that the framework has stabilized and the developers have stood their
> ground on not starting to code without solid requirements.
>
Your organization is starting to mature.  But, you have to be cautious
of the other extreme that leads to capital-M paper Methodologies and
endless meetings (sometime with evil Power Point presentations).
Instead, get your programmers out doing the work of the people whose
jobs they are automating for two weeks, then tell them the problem, and
then let them loose to solve it.  It's a novel approach, but it can
work.

> concrete in the others.
> wasn't supported by g++ circa 1990), yet too restrictive to make it easy to
> split the UI and the simulation into separate threads easily.
>
> If they'd just talk to us, we could do what they need. But they never do.
>
Most of the time, I have found that the end-users don't really know what
they want until they see it.  It is our role as a support industry to
understand their businesses that we are programming for better than the
users do.  The turning point for me was when I was the entire IT
department (third hat), writing applications in support of my own work
(first and second hats).

If the programs didn't work, the senior estimator (me) went to have a
hear to heart with the IT manager (me) and we made things work.  It
didn't matter that the user (me) didn't tell the programmer (me) up
front what he wanted.  What mattered was that in transacting business we
had discovered a weakness in the tools we had made that was costing us
money, and we fixed the tool to meet our needs.

Apart from multiple personality issues, that experience changed how I
view and construct software.  I became much better at anticipating
business requirements in general, and much more understanding that the
business requirements are often fluid.

I began building my programs to offer options and guidelines instead of
rigid rules, and in the process discovered that I was writing less code
that was both simpler and more effective at meeting the business needs.

I wish you good luck in untangling your product.  Been there, done that.
There is a light at the end of the tunnel, and it might not be a train.

David J.
This topic is locked and can not be replied to.