Getting curious about Ruby on Rails

Ruby web architectureRuby on Rails has been a buzz word for a while amongst code hacker circles. Right.

However I recently noticed (eg finalist at the Technology of the Year 2007 contest by developer.com Gamelan) that the hype was getting more and more professional.

Ruby on Rails is a database-driven web application development framework cherished by many independent programmers, computer science nerds and IT professionals hacking code at night from home. It seems, at least to me, that Ruby on Rails is now starting to be considered as a serious option within IT service companies and software publishers.

On Ruby’s shortcomings first:

- few web hosting companies support Ruby. Ruby indeed is interpreted on the server itself by a program named Rails, and unlike .Net or Apache (php, Java), it’s Rails isn’t really a standard yet.

- Unlike Java or .Net, Ruby isn’t supported by any major technology company. Ruby’s genuine independence may damper market adoption (no push) and cause crucial features (see next point) to be available at a delay.

- Crucial features like packaging (to my knowledge, not yet possible to build a setup file to automatize program installation) or Excel files manupulation aren’t yet available to the developer community. Catalogue extensions are under the responsiblity of..nobody. Independent passionate people take care of new developments, and since Ruby on Rails is still young, one may consider this technology to be as of today immature.

On Ruby’s advantages then:

- From a user view point, and unlike Flash or javascript and therefore Ajax, there’s no issue about Ruby applications form to differ from one browser to another – thanks to Rails interpreting the code in Ruby. In other words, Ruby web developments are compatible with all browsers and the app will always display.

- A steep learning curve: Indeed, Ruby is simple to learn and use (a couple tutorials will do).

- Productivity: the bulk of developers taking to Ruby quickly start to evangelize the language. This is a fact. . helps optimizes development of web applications with back-end databases through a crystal-clear code structure pattern: controllers, the model and HMI are well separated in the development environment. An app hacked in Ruby is very likely to be much (roughly between 15% and 30%, but it all depends on the talent of the developer behind it) shorter than the same app devised in php or Java (in my opinion the .Net framework in general and Visual Studio in particular really enhances productivity as well).

- Ruby code is highly readable, even for non geeks.

My call on Ruby on Rails: as more and more IT service companies use it, especially in the US where Ruby devs have been mushrooming, and thanks to an operational set of interfaces with all major databases (Oracle, DB2, SQL Server, MySQL, etc.), I believe Ruby will become a mainstream language for Web 2.0 and SaaS web applications requiring permanent access to relational databases pretty soon. When? I’d say within one year, the time for trainings to spread out and business clients to become less picky with yet immature development frameworks.

Related posts:

  1. The life of a software developer, episode 3/4: how to be flexible?
  2. Another resolution: spend 2+ hrs/week learning C# development
  3. Peter's Principle applied to software start ups
  4. My agenda @ TechEd 2007 EMEA
  5. "453: Deployment Error" when running a web service program on Netbeans: here's the patch

12 Responses to “Getting curious about Ruby on Rails”

  1. kari says:

    Sorry to say Jeremy, but you’ve gotten couple of things wrong here. You’re mixing up Ruby and Ruby on Rails in a major way.

    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.

  2. Jeremy Fain says:

    Hey Kari,

    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).

  3. Julien Marie says:

    Hi Jeremy,

    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 !

  4. Jeremy Fain says:

    Hey Julien,

    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 :)

  5. kari says:

    Okay, I hope Julien answered most of your questions. So, the (Ruby) code on the server is interpreted on the server by a program named Ruby. Yes, there is rails (or rails.exe if you’re on Windows? At least on unix it’s just a ruby script) but running “rails –help” you get this:

    “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)

  6. [...] in the comments after I hacked my first “Hello Fucking World” on Ruby on Rails showing I didn’t quite get it. I’m here to be challenged and learn by doing things. I don’t blog to be judged or [...]

  7. persuaders says:

    Kari —

    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

  8. Jeremy Fain says:

    Hey Persuaders, it seems we both agree on the advantages of Ruby. However, I don’t understand your attack agains the .Net platform: using Visual Studio was actually the most convincing programming experience I even went through.

    But I acknowledge Ruby isn’t bad either.

  9. kari says:

    Jeremy, then you’re probably interested in the many efforts to make a Ruby IDE in Visual Studio =)

  10. kari says:

    …or in Ruby.NET

  11. Jeremy Fain says:

    I am indeed. Microsoft believes a lot in Ruby’s potential. And one of the best ways to realize one’s Ruby potential is to use Visual Studio.

  12. ceciiil says:

    We have used Ruby On Rails for a project and it has been a good experience.

    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/

Leave a Reply

Staypressed theme by Themocracy