<duracell8> 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).
<duracell8> 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.
<duracell8> 8. Rails does not work with compound keys. Consider before
using Rails
There is a plugin that provides composite key support now.
<duracell8> 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.
<duracell8> 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.
<duracell8> 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.
<duracell8> 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
