On Tue, November 20, 2012 10:28, m.roth at 5-cent.us wrote:
>
> Here, they use Ruby, the enterprise version - is that what you mean by
> RBENV or RVM? The next release of ruby? from RH? will be the 1.93 or
> some such, and include all the stuff in the enterprise version.
RNENV and RVM are Ruby language installers that create a custom
programming environment by user. REE is simply a modified Ruby VM
based on 1.8.7 which was produced by the same people who provide the
Passenger gem. Support of REE is / will be discontinued as MRI (Matz
Ruby Interpreter) version 1.9.3 addresses most of the issues with v
1.8 that REE attempted to correct.
> Development tools on a production box are a very, VERY bad idea. I
> assume you can build the ruby app on your development box, and then
> move it as a package to test, then prod.
I am not sure that I can agree with this. All of our application
servers are sealed. There are no local users other than
administrators and application pseudo-users so the presence or absence
of development tools is mostly moot. Anyone who penetrates a sealed
server already knows enough that the absence of development tools is a
negligible inconvenience. On the other hand, many RubyGems must be
custom built on their target hosts. This is particularly true for DB
adapters. To keep these gems up-to-date requires build tools.
I suppose that I could direct that all build tools be removed after a
gem update and reinstalled as required but the illusionary security
benefit is simply not worth the very real labour cost.
>
> I've also seen an article or two about ruby not scaling up well.
> From my experience here, the apps seem to be *very* fragile, and
First, there are a lot of fragile COBOL applications that have been
running in large corporations for decades. I know, I worked on some
of them. On one system, run by a now defunct telecommunications giant,
the corporate accounting staff had to calculate foreign currency
adjustments off line and explicitly ADD the resulting figures to the
production cost system as component items. This was necessary because
the existing system did not handle foreign currencies and NO ONE was
going to take the responsibility for breaking the entire cost
accounting application just to add that feature. Just consider how
fragile that is.
The reason that there are a lot of fragile Ruby (and a plethora of any
other languages that you care to name) Apps is mostly due to the
sudden popularity of the language generated by the creation of a
'cool' new framework (in this case Ruby on Rails). The result is
attraction of swarms of people from other languages who throw up (in
both senses of the term) hastily built, generally untested, toy
applications that simply are not designed to handle growth; or simply
not designed at all. That is likely the case with most of these
supposed 'fragile' apps. Apps which no-one seems able to name however.
If one comes to Ruby from Python or PHP or MVB or dot.net or Java or
C++ or C and just starts coding then one likely will end up with a
Python, PHP, VB, dot.net, Java, C++ or C application. It will be
written in Ruby but it will not be a Ruby app. The problem is
succinctly put by the observation that one can write Fortran in any
language. Of course, if you come from Smalltalk, then the case is
somewhat altered. But, I digress.
> it reminds me of python 10-12 years ago, where updating it one or
> two subreleases broke everything that had been working, including
> system tools.
I cannot speak to what happened with Python a dozen years ago but it
seems to me irrelevant to what is happening with Ruby today.
>
> ObStmt: No, I don't like ruby.
I would never have guessed.
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3