Check fred’s (him again !) post and presentation presentation on how to introduce RubyOnRails in your company :

http://fredbrunel.com/journal/2006/03/how-to-introduce-ruby-on-rails-in-your-company/

Another post by his Fredness on mistrakes to avoid while using RoR :

http://fredbrunel.com/journal/2007/04/5-mistakes-you-should-know-when-using-ruby-on-rails-in-your-company/

But I acknowledge Ruby isn’t bad either.

Don’t fight it — RoR is easier and bringing more products to market quicker that compiled languages ever did. A lot of them are rubbish but it will get cleaned up. At least it doesn’t make product managers slaves to one high horse .Net coder whose job is in jeopardy or will be in the future.

Welcome to the SaaSy world — anything flies as long as it works on the browser and nobody will care how it works on the server or mainframes or my mothers electric type writer.

The user is becoming king and this will be the time of product designers rather than coders, doesn’t matter how much you correct Jeremy………

Get one of the few RoR books and re-write your resume, if you haven’t already.

Good luck pal

“Description:

The ‘rails’ command creates a new Rails application with a default directory structure and configuration at the path you specify.

Example:

rails ~/Code/Ruby/weblog

This generates a skeletal Rails installation in ~/Code/Ruby/weblog. See the README in the newly created application to get going.”

As Julein said, Ruby on Rails is a bunch of Ruby scripts and other tools to make kick-ass web applications. I think the closest comparison is Django, which is for Python.

I can do better than a simple .exe-file to install a Rails app – with RubyGems, f.e. if you want Typo, a blogging engine, just type. “gem install typo”. (Okay, you have to type “typo install /some/path” after that, but hey, it’s packaged)

On the 2 ‘mistakes’ you point out:

1) server & client side: I obviously perfectly understand the difference between the two, but I acknowledge I didn’t make myself clear in the above post.

2) Kari also pointed out the fact that I didn’t know the difference between Ruby and Rails. And that’s right, I could elaborate more than saying that Rails is the program you install on the server to interpret Ruby code and make it readable. So many thanks for the clarification.

3) Hosting: of course you can always find a way through, but I pointed out hosting as a constraint to a fast democratization of RoR; in other words, market adoption might be slowed by customers feeling ‘trapped’ with hosting companies not supporting Ruby as of today.

4) Scaling: interesting stuff, I don’t know these and I’ll have a glance at it tonight or tomorrow.

Thanks for saying what you needed to say, you’re welcome anytime.

Btw, Kari, Julien, these are the type of challenging comments I enjoy. I’ll think I’ll start writing more about technologies I don’t understand well yet to get to learn more from my readers

Nice to see you get more and more interested in Ruby on Rails.

I feel I need to correct some stuff in what you’ve written.

I’ll begin with the HUGE one : “Ruby works on all browsers to my knowledge, unlike javascript & Ajax or Flash (need for plug-ins). ” You’re mixing server-side scripting and client-side (browser-side) scripting. On server side, your application will generate files on the fly sent through HTTP (mainly HTML, CSS, JS, JPG, GIF and SWF files). These files will be interpreted by your browser, but their content will not be due to the language your using but to the application you’ve programmed. If you don’t know how to make a valid cross browser CSS, your webpage will be fucked up in IE or Firefox. It’s just not dependant on your server-side language (Ruby, PHP, Java, or anything else), but on what you’re doing as developper. It’s the same problem with ruby, php, java, c, etc…

The second mistake is about what is ruby and what is rails. Ruby is an interpreted language, Rails is a Framework (like Struts for Java or Symfony for PHP). “A framework is a defined support structure in which another software project can be organized and developed. A framework may include support programs, code libraries, a scripting language, or other software to help develop and glue together the different components of a software project.” (wikipedia). Rails, by example, is made of classes and methods (active record, active mailer, action view, etc..), of tools (rake, webrick…), etc… to help the programmer to build a structured, simple, organized application.

About hosting : when you’re serious about hosting, take a dedicated or virtual server, and install Rails. If you’re on the edge and a testing developper, try Amazon EC2. If you just wanna play, try Dreamhost . But hosting is really a non issue when your serious about it (except if you’re waiting for Free to install Ruby on Rails on personal pages, on think that OVH is a good web hosting company.)

About scaling : Using Mongrel, Mongrel_cluster and Capistrano, it’s quite a non-issue : load-balancing is integrated, you just have to add servers and deploy.

I think I’ve said what I needed to say.

See you !

To answer your points one by one. I was indeed sold Ruby on Rails by many people over weeks recently. And I checked it out by myself developing basic stuff in Ruby all night long. Thank you for pointing the difference between Ruby and Ruby on Rails, I hadn’t understood it myself. Thank you also for RubyGems and the fact that MVC frameworks exist in other programming languages.

However, here are my answers to the points you mention that I find rather unjustified:

On my sentence “Ruby indeed is interpreted on the server itself by a program named Rails”: Ruby’s interpretor named Rails is located on the server. So I don’t see why this sentence is wrong.

Many packages in Java and C# have been developed to manipulate .xls files – these aren’t yet fully ready with RoR.

On the packaging thing: can you point out one app that would result fully installed on a server after running a single .exe file?

Ruby works on all browsers to my knowledge, unlike javascript & Ajax or Flash (need for plug-ins). I mentioned Java & php to point out that few servers supported Ruby on Rails (a point with which you seem to agree).

Ruby is a scripting language, similar to Python and Perl, somewhat popular in Japan (where it originates from) and recently gaining more momentum thanks to the web framework called Ruby on Rails (RoR). It doesn’t make any sense to compare RoR against Java.

Excel / Excel-file manipulation is entirely possible in Ruby. Packaging Ruby applications is entirely possible through RubyGems. In fact, the recommended way to install Rails is through RubyGems.

“Ruby indeed is interpreted on the server itself by a program named Rails” is completely wrong and I’ve no idea how to make that sentence right. Ruby is indeed an interpreted language and the interpreter is available in every modern unix-like distribution. The interpreter is invoked insurprisingly usually by calling “ruby”. Rails is just a bunch of ruby scripts, to say it simple.

The reason for small adoption in web hosting is probably due to poor best practices in implementing Ruby hosting. It can also be really heavy on the server and poorly programmed scripts can bring a shared host to its knees. The current implementation of Apache’s mod_ruby is also out-dated and inefficient (thus the world of pain with fastcgi/fcgi/…).

Ruby is like PHP and Java, it is relatively cross-platform and like PHP and Java, the coder is free to make web pages that look like shit in any browser. Rails doesn’t control it in any way. I’ve no idea where you have picked this up, but it is completely false. Rails or Ruby does not magically create cross-browser valid code.

Ruby on Rails is web MVC framework, so that pattern is there, but the developer is free to do crappy code and mix models, controllers and views into spaghetti. This is nothing new, there are MVC frameworks for every programming language. The shortness of Ruby code has nothing to do with this. Some ruby code might be shorter than equivalent in other languages, but this is mainly due to its experssion-like nature.

It is right that Ruby and Ruby on Rails are not that hard to learn, but the problem is that there are only couple of books on the market about them. And even they are rather introductory. Documentation is the weak point of Ruby on Rails right now and has been from the beginning. Also rapid development means that almost every book on the market now on RoR is fatally out-dated thanks to the newest version.

I must admit that Ruby is one of the few languages in which I can still understand my own code after couple of weeks.

Overall, someone has certainly sold Ruby (on Rails) to you, too bad he/she has resorted to so much hype that you actually sound quite silly making all those statements.