Ruby/Rails facts?

Rails
1

I found these facts while in #ruby-lang irc?

1. Limited Pool of developers who know Ruby. Get
developers
to nominate if Ruby will be their secondary language.
2. The serving of Ruby Apps from Apache using FastCGI is
broken the world over. It causes periodic process and database
connection
blowouts. Move to a Mongrel Pack.
3. Limited IDE support for Ruby. IntelliJ Plugin? Eclipse
Plugin?
4. Page Caching approach is inconsistent between Press
Room
and SEO. The Ruby world has standardised on memcached for this.
5. Database layer caching is not done causing high
database
usage. Introduce this using memcached
6. No Oracle prepared statement use in Rails. Consider
before
using Rails, or use Rails with MySQL.
7. True unicode support. Consider before using Ruby.
8. Rails does not work with compound keys. Consider
before
using Rails
9. Ruby is 15 times slower than C. Evaluate performance
requirements before using Ruby
duracell8: No flooding.
10. Rails unlike J2EE is not a specification, it is an
open
source project.
rue: true, tis a basardized .each{}
11. The lack of single sign on has caused each Ruby
application to have its own authentication service and database. These
also
do not work with digipass security.
12. Separate physical database for Ruby apps
those are the thoughts of one of my coworkers
what do you guys think of that? i’m new to ruby and was
curious
sorry

–
Don’t live to geek; geek to live.
http://anildigital.blogspot.com

2

On 9/5/06, Anil W. [email protected] wrote:

I found these facts while in #ruby-lang irc?

1. Limited Pool of developers who know Ruby. Get developers
to nominate if Ruby will be their secondary language.

Agreed… and good luck with those developers. I find among my peer
developers ( Perl, PHP, ASP , CF ) that Ruby is an aquired taste you
have to seek out on your own. Some people just don’t wanna hear about
yet another 15 minute weblog screencast.

2. The serving of Ruby Apps from Apache using FastCGI is
broken the world over. It causes periodic process and database connection
blowouts. Move to a Mongrel Pack.

Or Lighttpd.

3. Limited IDE support for Ruby. IntelliJ Plugin? Eclipse
Plugin?

RailsEditor + vim.
http://rubyforge.org/projects/rails-editor/
http://vim.org/

9. Ruby is 15 times slower than C. Evaluate performance
requirements before using Ruby

Hardware is cheap, development time is not.

10. Rails unlike J2EE is not a specification, it is an open
source project.

http://destiney.com/entry/image/3/medium/books.jpg

w3.org has all the specifications you need for developing web pages.
Rails helpers methods seem to be compliant with standards.

11. The lack of single sign on has caused each Ruby
application to have its own authentication service and database.

http://wiki.rubyonrails.org/rails/pages/HowtoUseMultipleDatabases

These also
do not work with digipass security.

Is this not what developers do? Make things “work with” other things?

12. Separate physical database for Ruby apps

ActiveRecord can easily connect to legacy databases for imports or
syncing.

http://wiki.rubyonrails.org/rails/pages/HowToUseActiveRecordOutsideRails

–
Greg D.
http://destiney.com/

3

1. Limited Pool of developers who know Ruby. Get developers
to nominate if Ruby will be their secondary language.

Give a good developer a copy of the pickaxe book and force them to
read it. Chances are they will never want to write anything but Ruby
after that (Or they might turn into raving lunatics annoying everybody
with constant reminders of how good Ruby is - at least that’s what
happened to me).

3. Limited IDE support for Ruby. IntelliJ Plugin? Eclipse
Plugin?

RadRails isn’t half bad. Intellij also announced forthcoming Ruby
support, which I have high hopes for.

What you will find though is that there is mouch less code and so much
more intelligence in the framework design that you don’t really need
an IDE. When I first heard this argument, I was sceptical, but I am
convinced now. I write Ruby code in whatever is handy, even Notepad if
necessary.

8. Rails does not work with compound keys. Consider before
using Rails

There is a plugin that provides composite key support now.

9. Ruby is 15 times slower than C. Evaluate performance
requirements before using Ruby

I had concerns about that as well. But in practice I have found that
it does not really matter. For all but the smallest projects, you will
save more money on the development time than you spend on extra
hardware.

My personal impression is that Rails apps outperform badly written
Java apps, and there are many of those.

There is also a Ruby VM in the works, which will increase performance.

10. Rails unlike J2EE is not a specification, it is an open
source project.

Yes. And see how that helped make J2EE so highly productive.

Rails is a pretty tightly controlled project led by brilliantly smart
people, which is good. Rails features come from real life projects -
unlike J2EE specifications, which are written by vendors and
scientists with very little concern for real-world business problems.
Yes, things like two-phase commit and ditributed systems are -
technically - solved, but I believe the number of projects actually
requiring these features is vanishingly small. For all the rest, it
adds significant overhead - both in terms of development effort and
runtime performance.

11. The lack of single sign on has caused each Ruby
application to have its own authentication service and database. These also
do not work with digipass security.

I would suggest that it will still be cheaper to write the
functionality to integrate with SSO systems as part of a project
rather than pay for the corresponding Java-based out-of-the-box
solution.

12. Separate physical database for Ruby apps

Nothing in Rails requires you to have a stand-alone database per
application. In the interest of good design an application should
always have its own database. Integration approaches that use a shared
database are fraught with danger and will most likely cause
maintenance nightmares.

In summary, I was sceptical of the cited productivity gains when
using Rails - 10x improvements sound far too good to be true. My
experience, however, has confirmed those figures.

Cheers,
Max

4

On 9/5/06, Anil W. [email protected] wrote:

and SEO. The Ruby world has standardised on memcached for this.
10. Rails unlike J2EE is not a specification, it is an open
source project.
rue: true, tis a basardized .each{}
11. The lack of single sign on has caused each Ruby
application to have its own authentication service and database. These also
do not work with digipass security.
12. Separate physical database for Ruby apps
those are the thoughts of one of my coworkers
what do you guys think of that? i’m new to ruby and was curious
sorry

Uh. Are there questions heres? Have you tried google or the wiki or
blogs or any other resources before posting this list of tired, old
questions?

Isn’t anyone just tired of these discussions yet? =) The same 10 or
15 points, the same counter arguements, etc, …ad nauseum. Can’t we
move this to a “common language fights” page on the wiki or something?

  • rob

–

5

Isn’t anyone just tired of these discussions yet? =) The same 10 or
15 points, the same counter arguements, etc, …ad nauseum. Can’t we
move this to a “common language fights” page on the wiki or something?
Amen to that. Or just have a page that has 3 answers

“Who really cares about X?”
“X is not true”
“Add X yourself - it’ll be fun”

Rails stood up to the big boys in the beginning and for some reason, a
lot of developers got their backs up. Unfortunately it’s more and more
obvious that those with strong opinions against ruby/rails have never
really used it in a reasonable capacity. That’s why we get a re-hash of
the same old arguments - I know I had a few of these worries in the
beginning.

If these developers actually tried using rails properly, I’m sure they’d
realise what the top rails guys have been saying all this time:

  1. Rails may question your traditional approaches and makes no apologies
    for it

  2. Rails is a family effort - we are all answerable for it’s features or
    lack thereof

and lastly:

  1. Rails isn’t for everyone

yawn

Steve

6

Summary:

Complaints 1-15: Ruby is not Java, Rails is not J2EE.

So what? Use what works for you.

7

Rob S. schrieb:

Plugin?
requirements before using Ruby
sorry

  • rob

I fully agrree: every day such a discussion… “why rails” , “Is rails
secure”, “difference between…” etc etc…and the list gets busy.

I have the impression, the initiators of those threads are do that just
for keep YOU busy…I formyself normaly catch them all together and hit
the trashcanicon…

And yes, they even dont have the balls to come themselfs with such a
list, no, the name a coworker as the listowner…those guys make also
sure they get the pornvideo packaged as gift, when THEY need something
new :wink:

I am tired 2

cheers

matthi

8

matthibcn escribió:

broken the world over. It causes periodic process and database connection
8. Rails does not work with compound keys. Consider before
12. Separate physical database for Ruby apps
Isn’t anyone just tired of these discussions yet? =) The same 10 or
I have the impression, the initiators of those threads are do that just
cheers

This 12 points are ridiculous, analyzing one by one they take no sense.
The whole analisis smells of fear, and Java fears Rails. Why? who knows?
the same fear of old lion to a young lion, perhaps.

  1. Compared to PHP or Java, we are a little community, but Ruby is like
    a virus, once you touch it you never go back to neither PHP nor Java. We
    will be more an more soon.
  2. FastCGI is not the better solution, but works. Mongrel is the the
    near future, I recognize it.
  3. What about RadRails (I use it and I am happy)? What about TextMate?
    the Rails IDEs are growing up day by day like no other plataform in the
    programming history.
  4. Page caching inconsistency? well, I don’t have performance problems
    because that so far, I only have performance improvements.
  5. Perhaps this is the cost of the awesome ActiveRecord implementation
    in Rails, I do not know.
  6. Really? and what about this:
    Peak Obsession
  7. Today, Unicode is the Aquilles heel of many languages (PHP is one of
    them)
  8. Look at this wonder:
    class Fool < ActiveRecord::Base
    has_many :doubts
    belongs_to :jteam
    end
  9. C? who make web applications in C? It is 2006, the 21th century, what
    are you talking about?
  10. JSEE is a specification of Java and Rails is a specification of
    Ruby, what is the problem? Does open source cause you nightmares?
  11. Paypal?..
    http://www.jeremyhubert.com/2006/7/7/using-paypal-website-payments-pro-with-ruby-on-rails.
  12. I actually have 3 separate physical databases: a production on
    Internet, a test in memory and development in my computer.
9

Marcos wrote:

This 12 points are ridiculous, analyzing one by one they take no sense.
The whole analisis smells of fear, and Java fears Rails. Why? who knows?
the same fear of old lion to a young lion, perhaps.

Huh? SOME of them make sense – it’s good to have ammunition to counter
them…

Joe

10

Rob S. wrote:

On 9/6/06, Joe R. [email protected] wrote:

Joe
Yes, and there is A TON of ammuniation and discussion on all those
points available via the archives or google. No need to rehash the
same old threads.

Free speech, and it takes next to no effort to ignore threads you’re not
interested in. Besides, some of the points I hadn’t seen before.

Joe

11

Joe R. escribió:

Joe

Well Joe, you are right, I have exceeded myself with this reply.

But, the sentence “it’s good to have ammunition” may be applied to the
attacker too, not only to the defender. Because de amunition of this 12
points is not present in both sides.

I admit that I have soiled the list slightly, so I request an excuse to
everybody (if this is written thus).

My next contribution will be much more constructive (and less
impulsive), I promise it.

M.

12

On 9/6/06, Joe R. [email protected] wrote:

Joe
Yes, and there is A TON of ammuniation and discussion on all those
points available via the archives or google. No need to rehash the
same old threads.

13

On 9/6/06, Joe R. [email protected] wrote:

Joe

You’re right, and I plan on ignoring this one in the future. From
looking at the list, I can tell you I’ve seen every one of those
points discussed over and over in different places, whether it be
here, rails-core, ruby-talk, or on blogs. Which point haven’t you
seen discussed before? If a technical lead was actually doing their
due diligence, they would have already found the past discussions from
both sides on all those points, evaluated it, and made a decision.
Instead we have yet another yet another j2ee vs rails “question”
looking for “easy answers” when there are none.

But hey, have fun with it…

14

Rob S. wrote:

On 9/6/06, Joe R. [email protected] wrote:

Joe

You’re right, and I plan on ignoring this one in the future. From
looking at the list, I can tell you I’ve seen every one of those
points discussed over and over in different places, whether it be
here, rails-core, ruby-talk, or on blogs. Which point haven’t you
seen discussed before? If a technical lead was actually doing their
due diligence, they would have already found the past discussions from
both sides on all those points, evaluated it, and made a decision.
Instead we have yet another yet another j2ee vs rails “question”
looking for “easy answers” when there are none.

But hey, have fun with it…

Since you’re a complete expert on this, write up a detailed report and
put it on the wiki or somewhere…

Joe