Zen and the Art of Programming

Antonio Cangiano April 13th, 2008

This is the third episode of This Week in Ruby, please consider subscribing to my feed in order not to miss any weekly installments.

Phusion Passenger

This week there were a few announcements that will change the history of Ruby. The first of them was the release of Phusion Passenger. For those who spent the last three weeks in a cave, Passenger is the name of mod_rails for Apache and, at the moment, it’s the most talked about piece of software in the Rails community. Let’s put this in perspective to better understand how important it is. A few years ago the recommended way of deploying Rails applications was the employment of Apache or Lighty with Fastcgi. Eventually the community realized that it was less than ideal, and a disaster for those who were using Typo or other Rails applications on most shared hosting plans. Most people then favored the option of using a cluster of mongrel processes, proxy balanced by Apache, Lighty, NGINX, etcetera.

There are other available variants for this configuration, and even some alternatives, but overall most people will agree that the concept of a proxy balancer plus a Ruby web server has been the recommended solution for a while now. It definitely works, it’s stable and scalable, and will probably continue to satisfy many users. There are, however, three disadvantages of this configuration: 1) The setup is not complex, but it’s definitely more complicated for newbies, when compared to what PHP developers are used to. It’s not an “upload and run” solution; 2) In order to work, it requires a decent amount of RAM, and root access to the machine doesn’t hurt either; 3) Most shared hosting companies are unwilling to offer it to their customers. That’s where Passenger comes to the rescue. It’s as easy as it gets (pretty much zero configuration), the company claims a lower memory footprint when used with their soon to be released version of Ruby (called Ruby enterprise edition), and finally it’s ideal for shared hosting because it’s just an Apache module like the ubiquitous mod_php.

As such, Passenger can be that vital missing piece for the wide adoption of Rails on the web. Try it out and if you decide to use it for your projects, don’t forget to feed the two brilliant minds who came up with it by donating here.

GitHub

Amongst other important announcements, is the launch of GitHub, where the Rails community seems to gather now. Think of it as the Facebook of Rails hackers. Aside from Rails, Merb and Capistrano, further projects are continually moving there. Some are even leaving Rubyforge despite their recent addition of a Git option. Both the ORM Sequel and the Ruby VM, Rubinius got on GitHub, even if the latter is only copied over by post-commit hooks.

Ruby Web Frameworks

As we approach the release of Merb 1.0, you may find the official wiki a useful resource and want to consider contributing to expanding it. And if you are interested in Merb thanks to its being leaner and faster than Rails, you may want to read Matt Aimonetti’s informal benchmark, that claims about 70% improvement over Rails for a dummy application.

Sinatra 0.2.0 was released, as a much improved version of the ultra-lean web application framework for Ruby. Very interestingly, an article was published that covers its usage for creating simple Facebook applications. A recommended reading for those who don’t need Rails’ overhead for simple apps.

This week RubyInside covered a new RESTful framework similar to Rails, called Mack. The amount of web frameworks for Ruby is constantly growing and this is due to the ease of creating DSLs in Ruby and the fact that Rack, made the integration with web servers dead easy. Do we really need all these web frameworks? Probably not, but natural selection is a powerful tool and this is interesting stuff that’s worth a test drive anyways.

Rails 2.1 will soon be released, if you are curious about the improved support for Time Zones, don’t miss this well explained overview by Geoff Buesing. The new features are just plain awesome and will make the trouble of upgrading worth it.

Ruby

A few other announcements were made this week in Rubyland. The most important, was the release of the 2.0 version of RDoc, which significantly improves ri performances (hallelujah).

Peter Cooper, who never sleeps, made the announcement of a Ruby community for link sharing, called RubyFlow. It could be a good replacement for ruby.reddit.com, given the clear anti-ruby bias that can be experienced on Reddit.

Jay Fields’ has a nice article entitled Extend modules instead of defining methods on a metaclass which is a good reading about a technique that is often ignored.

The first of 8 books on Ruby coming out soon was published this week. In fact, FXRuby: Create Lean and Mean GUIs with Ruby was finally published. I started reading the first few chapters and it’s very straightforward. If you are into desktop apps, consider getting it. In my opinion it’s a quick read.

Two articles worth mentioning are Ruport: Business Reporting for Ruby by Gregory Brown and Michael Milner, and a brief overview of 19 Ruby template engines. Yes, there are that many!

Finally, please note that the registration for the fifth batch of the popular free online Ruby course by Satish Talim is now open. This course will start on the 3rd of May so sign up now if you are interested.

• Ruby , Ruby on Rails , This Week in Ruby
• Comments(7)

Antonio Cangiano April 7th, 2008

The first edition of This Week in Ruby received a warm welcome from the community. A week later, here we are with a second installment of the series. I’ll attempt to repeat these posts approximately every week, so feel free to follow along by subscribing to my feed.

The Ruby community is a tremendously active one. In only seven days, there have been so many noteworthy items popping up, that it would take me hours just to mention them all. I’ll try to pretend that you, the reader, have been on a week-long vacation in a remote place without internet access, and on your return you asked me, “Hey, Antonio what happened in Ruby and Rails land while I was away?”

Some fun on April Fools’ Day

We kicked off the week on a lighthearted note, by fully embracing the endless opportunities offered by April Fools’ Day. Most of the spoofs and jokes were aimed at making fun of Ruby on Rails, one way or another. Testimony to the self-irony that we, as a community, certainly have. I personally announced the soon-to-arrive release of a fictitious (of course) framework called Ruby on Crack. Which was supposedly much faster and productive than Rails. At the heart of the joke were the fake endorsements, chocked full of double-meanings (with apologies to Matz, David Heinemeier Hansson, Dave Thomas, Ezra Zygmuntowicz, Obie Fernandez, Zed Shaw, Tim O’Reilly, Guido van Rossum and Paul Graham). I found the SQL on Rails April Fools’ gag very funny and extremely elaborate. Their screencast is comedic genius and their site a spoof in every minute detail. In my book, on that day, they took the cake. The joke itself was from two years ago (as pointed out by a commenter below) but it resurfaced again this year. The hilarious trend continued with Cobol on Cogs and for the ASP.NET and PHP nostalgic, with Acts as ASP.NET and RHAP (Ruby Ain’t Hypertext Preprocessor). Avdi Grimm even found the final solution to the whole Monkey-patching diatribe: Ninja-Patching, “When you really want to catch a coder by surprise, a monkey doesn’t cut it. What you need is a Ninja.”.

mod_rails

Last week I mentioned Passenger (aka mod_rails). This week Hongli Lai published some interesting benchmarks that compared it against Mongrel and Thin for three Rails applications (Typo, Petstore and El Dorado). While still synthetic benchmarks, the results where very encouraging and showed how Passenger was on average faster than Mongrel and roughly on par with Thin. Even just the perspective of having performances that are somewhat comparable with those of Mongrel, would be great news, given that it’d highly simplify the deployment process of Rails applications with Apache. Ninh Bui has announced that the official release date for the project is expected sometime this week and that meanwhile they are working with companies like Twitter and Dreamhost to ensure that the module is fully tested. Speed is only one of the project’s aims in fact, with a lot of focus put on stability and robustness, too. They also caught the attention of Engine Yard who is interested in discussing a possible partnership and contributions to the Rubinius project.

Git

By now you should be aware that the Rails community is fully embracing Git, and github.com is only part of the reason. Michael Bleigh has even created a small library called ruby-github to simplify access to the GitHub API. David has announced that Rails is moving to Git and the ticket tracking system is being switched over to Lighthouse. As David pointed out, this means that both the tracking system and version control are to be run by Rails applications, which is a good bonus if you subscribe to the philosophy of “eating your own dog food”. For those who are still git-challenged, Kurt Schrader has a collection of helpful links to get you started. And if you need a simple issue tracker for git, version 0.1.2 of Ditz has just been released, too.

Conferences

Confreaks has now published the remaining videos from MountainWest RubyConf 2008. They’re very interesting and highly recommended. All of them.

In case you missed the Ruby Fools conference, held on April 1st and 2nd in Copenhagen, you can read an interesting personal account by 41Concepts. The conference also took place on April 3rd and 4th in Oslo.

Speaking of conferences, Sam Ruby will be presenting on Ruby 1.9 at this year’s OSCON. In a recent short post, he mentioned his plans for his talk and really nailed one of the problems that will hinder Ruby 1.9’s adoption, in his own words:

My tentative conclusion at this point based on observations of efforts to get products like Rails working on Ruby 1.9: the biggest obstacle to Ruby 1.9’s adoption is the sheer number of mostly working but essentially unmaintained gems that virtually everybody in the Ruby community depends on. — Sam Ruby

Rails

Amazon has an article on Using SimpleDB and Rails in No Time with ActiveResource. Another interesting article which surfaced this week was a post called simple pages for easily creating “boiler-plate” pages in Rails.

Three interesting plugins where released. You can read about them in Introducing Action Messager: Dead simple IM notifications for your app!, Better Partials Plugin for Rails and A Rails 2.0 Message Forum Plugin.

The Rails Jedi posted about two Mac OS X applications for accessing Rails docs in the most efficient way possible. Nookkit.app and RailsBrain are real timesavers, and I highly recommend them to Mac users.

SapphireSteel has announced the Public Beta of their Visual Rails Workbench. With the release of Ruby in Steel 1.2 Beta 3, they have in fact included their drag-and-drop visual environment for Rails. I didn’t have a chance to try it out, but if you are on Windows you may want to give it a shot, starting with reading their online articles.

The ink for printing Ruby and Rails books never runs dry, as I pointed out in my post 7 soon to be released Ruby and Rails books. It turns out that in the months of April and May alone, there will be 8 new Ruby/Rails titles. Check them out, especially if you are looking for updated material relating to Rails 2 or, in the case of the pickaxe 3, to Ruby 1.9.

The guys from Rails Envy, published episode 25 of their Rails podcast. If you are not familiar with their fun podcast, I recommend that you listen to a few episodes by subscribing to it through iTunes.

Ruby

There were countless interesting Ruby articles in the last week, but I’d like to point out the following:

• Writing C extensions in RubyGems using newgem generators (plus a free TextMate bundle) by Dr Nic
• Solving the method collision problem of monkey-patching
• Rack: HTTP request handling made easy
• Sustainable Development in Ruby (part 1 and part 2)
• Gemify 0.2.4 and the future
• Writing a compiler in Ruby bottom up (Part 1, 2 and now 3)
• Data Visualization with Ruby and RMagick - Where Are Those Bikes?
• Peach: Parallel Each (for Ruby with threads)

Ruby VMs

In Rubinius for the Layman, Part 1: Rubies All the Way Down, Mathieu Martin has a nice, gentle introduction to Rubinius with some reveling benchmarks too. For those interested in learning more about the current status of Rubinius, InfoQ has a short article with a few pointers.

More remarkably, in the land of alternative Ruby VMs, Jruby 1.1 has finally been released, after months of hard work. The authors are already thinking about what lies ahead for the project. If the subject interests you, feel free to grab a few slides from various presentations on the topic.

• Books , Mac , Ruby , Ruby on Rails , This Week in Ruby
• Comments(7)

Antonio Cangiano April 2nd, 2008

With the amount of good Ruby and Rails books already on the market, you’d think 2008 would be a shy year when it comes to publishing new titles, but nothing could be further from the truth. The following books are all to be released this month or in May, and there are many more coming out this summer.

Do we really need another 7 titles on the market within 2 months time? Interestingly, the answer is yes, for two main reasons. First, most of them serve a specific purpose, rather than being generic introductions. Second, we have a hole in the Ruby and Rails book market. Ruby 1.9, despite being a development release, has been out for a while. More importantly, Rails 2 differs enough from Rails 1.2 (covered by most books out there) to require new tutorials for those who approach Rails for the first time and perhaps even for those who wish to upgrade.

I think that the Pragmatic Programmers made a mistake in deciding not to upgrade their Agile Web Development with Rails, 2nd Edition because they left newcomers in a difficult spot. Developers who are experienced with Rails, will just get Obie’s The Rails Way and be fully covered, but those who are new and would like to get started with Rails don’t have many choices. They can get the Pragmatic Programmers’ Rails title mentioned above, but it’s a bit obsolete now and that means extra effort on their part to follow along, installing an old version of the framework, and then figuring out some way to move to the new features that were introduced by Rails 2.0 (soon to be Rails 2.1). As a matter of fact, when people ask me for a good Rails 2.0 introductory book for programmers, I can’t really name one. So far I’ve suggested getting Dave Thomas’ book or RailsSpace: Building a Social Networking Website with Ruby on Rails, and then moving to The Rails Way when they are ready to take it to the next level. But it’s not an ideal scenario at all.

Alright, to the titles then:

	Title: Programming Ruby: The Pragmatic Programmers’ Guide (Third Edition) Available: May 15, 2008 Notes: Currently in beta, it’s going to be the first book that fully covers Ruby 1.9 and its core and standard libraries.
	Title: Simply Rails 2.0 Available: May 15, 2008 Notes: It’s the second edition of an already “gentle” introduction to Rails called Build Your Own Ruby on Rails Web Applications. It covers Rails 2, and if well written, it may be that missing guide for newcomers to Rails and beginner programmers, that I was talking about.
	Title: Practical REST on Rails 2 Projects Available: May 5, 2008 Notes: It’s marketed as a practical intermediate/advanced title for creating RESTful applications. The topic and target audience make it interesting for many web developers.
	Title: Agile Testing with Ruby and Rails Available: May 19, 2008 Notes: It’s supposed to extensively cover TDD and BDD with Ruby and with Rails 2.0.
	Title: Advanced Rails Recipes: 84 New Ways to Build Stunning Rails Apps Available: May 15, 2008 Notes: Currently in beta, it’s a Rails 2.0 cookbook by one of the most prominent developers in the community (Mike Clark).
	Title: Deploying Rails Applications: A Step-by-Step Guide Available: May 15, 2008 Notes: Currently in beta, it’s the book that should alleviate the pain of Rails deployment for many. Ezra is one of the biggest experts in the field, so I have great expectations for this title.
	Title: FXRuby: Create Lean and Mean GUIs with Ruby Available: May April 15, 2008 Notes: Currently in beta, it covers cross-platform development with FXRuby, the Ruby wrapper for the FOX toolkit. The author, Lyle Johnson, is also the author of the gem.

I can’t speak firsthand for any of these books, having not had the opportunity to read them yet, but knowing some of the talent behind them I certainly have high hopes.

• Books , Ruby , Ruby on Rails
• Comments(14)

Antonio Cangiano April 1st, 2008

After several months of keeping it under wraps, I’m happy to officially announce my own web framework to the world. It’s called Ruby on Crack and will be released by RailsConf 2008. The name of the framework was chosen because I wanted to push the idea of a complete break from the existing Ruby frameworks, a clear cut, if you will.

Rails is great, don’t get me wrong, but it’s very opinionated. If you need to get things done in a different way, coding in Rails can become a burden. More reasonable from this viewpoint is Merb, but it’s still somewhat too close to Rails. Ruby on Crack is very different. A programmer using Crack no longer has strong opinions or is constrained within the rules defined by the framework. The only guiding principle is FUD (Fast Useful Development), but you get to decide your own specific style of web development. The framework is very modular and each component is connected to another one through a unified API called PIPE.

According to my preliminary tests, using Crack makes you 5 to 10 times more productive than using Rails. Not only that, but speed wise, you’re running much faster with Crack. Ruby on Crack ships with two extremely fast web servers, as opposed to WEBrick with Rails, called Purebred and Fat. Purebred handles requests by spawning new threads, while Fat uses an event based approach. From what I’ve seen so far, they easily outperform any other existing webservers, to the point that I was able to serve a sample app at a rate of 10,000 requests per second on commodity hardware.

Part of the speed boost that Crack can give you, is due the highly efficient, thread-safe and powerful ORM called Freebase. Even Datamapper is really slow compared to Freebase. On average, Freebase smokes ActiveRecord (it’s 4 to 5 times faster) and it can take advantage of advanced database features which are not supported in ActiveRecord, Datamapper, Og or Sequel.

I don’t want to reveal too much right now, but Ruby on Crack is truly a revolutionary approach to web development and makes you value the true power and colorful nature of Ruby. All of this will be explained in detail in future posts, and the code will be released into the wild for all to enjoy within the next couple of months. It took a lot of effort to get my team to work on Crack, but the results are rather satisfying. Don’t just take my word for it though, here are a few testimonials from prominent figures in the community who’ve had a chance to use the closed beta of Ruby on Crack:

“Those who use Crack can really appreciate the beauty of Ruby.” — Matz

“Fuck You” — DHH

“Incredible framework. I plan to publish a book about it ASAP, and I’m sure that it’ll be the first in a long series of books that I’ll write while using Crack.” — Dave Thomas

“Crack is what we really needed at Engine Yard.” — Ezra Zygmuntowicz

“Wow, what an eye opener. Crack made web programming fun again.” — Obie Fernandez

“You ass#$!@ m0#@#!@&%$” — Zed Shaw

“Once you have tried Crack for the first time, you realize how addictive it is. I simply can’t go back to Rails anymore.” — April Pesce

“Web 3.0 will belong to those on Crack.” — Tim O’Reilly

“If there is something that the Ruby community got right it’s Crack. I wish Python programmers were on Crack too!” — Guido van Rossum

“This is truly innovative and a godsend for startups. Give us about 6 years and we’ll have Arc on Crack too.”- Paul Graham

• General , Python , Ruby , Ruby on Rails
• Comments(38)

Antonio Cangiano March 31st, 2008

One of the main advantages of Ruby’s growing community, is the speed at which exciting news pops up. This post briefly covers must-read highlights for new developments in the Ruby and Rails communities throughout the past week. I’ll attempt to repeat a “This Week in Ruby” post approximately every week, so feel free to follow along by subscribing to my feed.

Rails 2

Craig Webster published the first part of an easy to follow tutorial entitled Getting Started with Rails 2.0. The nice thing is that it also covers version control through Git, which is becoming extremely common in the Ruby/Rails community. Speaking of trends, a study by Gartner predicts that the Ruby language will reach 4 million programmers within the next 5 years. Numbers that would definitely position Ruby as a mainstream programming language. Incidentally, Obie Fernandez published an interesting survey of major corporations and large companies which are embracing Ruby on Rails. A very impressive list that is destined to grow quickly as Ruby’s implementation and ecosystem improve.

The official Rails blog has a post about a few changes in the core Rails team which brings the number of hackers down to 6, and establishes a Core alumni group of “retired” Rails core programmers. The small team seems to be busy, as Rails 2.1 is about to be released with some new exciting features, such as migrations based on UTC timestamp, named_scope, gems as plugins and much more as outlined by this caboo.se post.

On the deployment side, there are a few exciting happenings. Apple has published the third part of their tutorial, titled Deploying Rails Applications on Mac OS X Leopard. HighScalability.com has an article about an incredible service offered by Heroku that offers one-click, hassle free, cloud computing based Rails deployment. Their service is still in beta, and takes advantage of Amazon web services, but from what I’ve seen so far their secure and scalable deployment is as easy as it gets and it’s going to be a welcomed addition to the deployment options available to Rails programmers. Even more interestingly, a Dutch company called Phusion put up a demo about their Passenger project. Phusion Passenger, aka mod_rails, is a module for Apache that will bring ease of deployment, stability and performance to Rails. The company claims that according to their tests, mod_rails should be slightly faster than using Apache+Mongrel, it handles Rails processes automatically by spawning them depending on the effective traffic, and they are working with the largest hosts in order to ensure real world performance and stability when under heavy loads.

James Golick continues his series of “Plugins I’ve Known and Loved”, this time covering Ultrasphinx, a plugin for the uber-fast search daemon Sphinx.

Nicolas Sanguinetti wrote a script, that attempts to speed up the process of setting up an empty Rails project. I don’t find the procedure particularly boring so I don’t plan to use it, but it might be useful to some people.

Ruby

Peter Cooper, of Ruby Inside, has an article about two re-implemenations of the Ruby language. They are both named Sapphire, adding further to the confusion. The first one is a real fork, which was apparently born from the author’s dissatisfaction with the current management of the MRI, and the desire to have better support for Windows along, of course, with extra features like Aspect Oriented Programming, Unicode, etc, etc… The second one appears to be a new language, a stripped down and “stricter” version of Ruby that is supposed to be more Smalltalk-like and would be running, at least in the beginning, on the .NET platform. They are both worth mentioning, but currently I honestly fail to get excited about them. Ruby has an implementation problem, not a design one, in my opinion. However, we’ll see what they are able to deliver. In my book, a good implementation of a Ruby like language would be far from being frowned upon.

Remaining in the field of new implementations, InfoQ has an article about a neat new addition called HotRuby which is able to execute opcodes generated by the Ruby 1.9 VM (aka YARV). HotRuby is an incomplete and tiny (40 KB) implementation, faster than Ruby 1.9, that runs on JavaScript and Flash.

For those interested in Ruby and compilers, Vidar Hokstad has published the first two parts of a tutorial called “Writing a compiler in Ruby bottom up” (part 1 and part 2). Even if you are not into compilers, it’s a rather interesting read.

Sun reaffirmed their commitment to Ruby this week, by announcing the Ruby Development Center on the Sun Developer Network. I like Sun’s serious efforts and fast paced development of both JRuby and NetBeans (whose 6.1 beta is now out).

A new project hit the frontpage of programming.reddit.com: StrokeDB. Odd name, I know, but if you are interested in CouchDB, you may also take an in-depth look at StrokeDB. It’s a project that sounds rather promising if properly implemented. In their own words: “StrokeDB is an embeddable distributed document database written in Ruby. It is schema-free, it scales infinitely, it even tracks revisions and perfectly integrates with Ruby applications.”. The developers had a talk at EURUKO 2008, the European Ruby conference that took place this past weekend. Videos from the conference are not up yet, but meanwhile you can equally enjoy the videos and slides from MountainWest RubyConf 2008 on ConFreaks, which has published a talk by Evan Phoenix and Ezra Zygmuntowicz, respectively about Rubinius and Merb.

Finally, last week I spotted a bug that made Ruby 1.9 (built from trunk) significantly slower than Ruby 1.8. After a bit of investigation I was able to single out that the problem concerned Mac OS X only. With some testing by Chris Shea, the exact culprit revision was isolated and the core team has already worked on a fix. It was a very prompt and impressive response by Matz and his team.

RubyGems

Eric Hodel has announced the release of RubyGems 1.1.0. Aside from bugfixes and a couple of minor features, the most welcomed improvement is a significant speed boost that makes the tool faster. If you’d like to hear Eric talk about Rubygems and his involvement with the Ruby community, this week InfoQ published an interview with him (the interview itself is from RubyConf 2007 though).

This is my first episode of “This Week in Ruby” so feel free to provide feedback if you found it useful or if you have suggestions for improving it. Thank you for reading!

• Ruby , Ruby on Rails , This Week in Ruby
• Comments(12)

Antonio Cangiano March 25th, 2008

Jay Fields has a nice post about the goodness of Enumerable#inject in Ruby. Like anyone who enjoys functional programming, I appreciate the concept behind inject and its possible usage. Your language may implement it with a method called inject, a function fold or reduce, but the concept is the same. I think that there is nothing inherently evil about using Enumerable#inject in your code, however one must be very careful and question whether there are simpler alternatives available. Abuse of creative usage of inject or cleverness is often paid for in terms of the readability of the code and can’t be discouraged enough. Another good reason not use inject is when performance counts and we are dealing with large datasets. In Ruby 1.8 in fact, inject is much slower than an equivalent solution implemented with the each iterator or other available methods. People will tell you that this doesn’t matter, but in the real world, having a method take twice as long because you opted for inject rather than each, is not always justifiable or acceptable.

For example, the following snippet benchmarks four different methods for summing the first n natural numbers. It benchmarks them for n = 10, 10², 10³, 10⁴, 10⁵, 10⁶, 10⁷ and 10⁸. Please note that the problem at hand can be solved arithmetically, like Gauss did when he was 10, but it will serve us well to test differences in the raw speed of the compared methods provided by Ruby.

The sum_with_while is admittedly ugly, and entirely not idiomatic. No Rubyist would write the method in that way. It’s there though, in order to have a non-iterator, loop-based solution which doesn’t rely on methods from the Enumerable class. It will give us some perspective. Also, the choice of reopening the Integer class, rather than writing methods that accept n as an argument, is entirely arbitrary and doesn’t affect the benchmark in any way.

require 'benchmark'
include Benchmark

class Integer
  def sum_with_inject
    (1..self).inject(0) { |sum, i| sum + i }
  end

  def sum_with_each
    sum = 0
    (1..self).each { |i| sum += i }
    sum
  end

  def sum_with_times
    sum = 0
    (self+1).times { |i| sum += i }
    sum
  end

  def sum_with_while
    sum, i = 0, 1
    while i <= self
      sum += i
      i += 1
    end
    sum
  end
end

(1..8).each do |p|
  n = 10**p
  puts "=== 10^#{p} ==="
  benchmark do |x|
    x.report("inject: ") { n.sum_with_inject }
    x.report("each:   ") { n.sum_with_each }
    x.report("times:  ") { n.sum_with_times }
    x.report("while:  ") { n.sum_with_while }
  end
end

These are the results on my MacBook Pro Core 2 Duo 2.2GHz with ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin9.2.0]:

    === 10^1 ===
    inject:   0.000000   0.000000   0.000000 (  0.000071)
    each:     0.000000   0.000000   0.000000 (  0.000020)
    times:    0.000000   0.000000   0.000000 (  0.000018)
    while:    0.000000   0.000000   0.000000 (  0.000022)
    === 10^2 ===
    inject:   0.000000   0.000000   0.000000 (  0.000084)
    each:     0.000000   0.000000   0.000000 (  0.000043)
    times:    0.000000   0.000000   0.000000 (  0.000041)
    while:    0.000000   0.000000   0.000000 (  0.000058)
    === 10^3 ===
    inject:   0.000000   0.000000   0.000000 (  0.000677)
    each:     0.000000   0.000000   0.000000 (  0.000335)
    times:    0.000000   0.000000   0.000000 (  0.000338)
    while:    0.000000   0.000000   0.000000 (  0.000492)
    === 10^4 ===
    inject:   0.010000   0.000000   0.010000 (  0.008473)
    each:     0.010000   0.000000   0.010000 (  0.003258)
    times:    0.000000   0.000000   0.000000 (  0.003142)
    while:    0.000000   0.000000   0.000000 (  0.004887)
    === 10^5 ===
    inject:   0.120000   0.000000   0.120000 (  0.115180)
    each:     0.060000   0.000000   0.060000 (  0.071298)
    times:    0.070000   0.000000   0.070000 (  0.063845)
    while:    0.080000   0.000000   0.080000 (  0.079443)
    === 10^6 ===
    inject:   1.410000   0.010000   1.420000 (  1.414042)
    each:     0.870000   0.000000   0.870000 (  0.882625)
    times:    0.870000   0.000000   0.870000 (  0.875730)
    while:    1.030000   0.000000   1.030000 (  1.039151)
    === 10^7 ===
    inject:  14.320000   0.030000  14.350000 ( 14.351873)
    each:     9.050000   0.030000   9.080000 (  9.086909)
    times:    9.120000   0.020000   9.140000 (  9.137516)
    while:   10.610000   0.020000  10.630000 ( 10.654512)
    === 10^8 ===
    inject: 144.070000   0.310000 144.380000 (144.517040)
    each:    90.380000   0.360000  90.740000 ( 90.898424)
    times:   89.960000   0.280000  90.240000 ( 90.476917)
    while:  106.760000   0.380000 107.140000 (107.741355)

These results are not surprising. The ugly sum_with_while method is just slightly faster than the sum_with_inject one, while sum_with_each and sum_with_times are significantly faster than sum_with_inject. For n sufficiently large, each is (linearly) about 1.5 times faster than inject. Again, nothing new, if you have done some number crunching with Ruby, you already know a few tricks and the fact that inject is notoriously slow.

Just out of curiosity, I decided to see how things have improved with Ruby 1.9. Here comes the surprise: ruby 1.9.0 (2008-03-21 revision 15825) [i686-darwin9.2.0] yields the following results.

    === 10^1 ===
    inject:   0.000000   0.000000   0.000000 (  0.000045)
    each:     0.000000   0.000000   0.000000 (  0.000038)
    times:    0.000000   0.000000   0.000000 (  0.000040)
    while:    0.000000   0.000000   0.000000 (  0.000016)
    === 10^2 ===
    inject:   0.000000   0.000000   0.000000 (  0.000311)
    each:     0.000000   0.000000   0.000000 (  0.000293)
    times:    0.000000   0.000000   0.000000 (  0.000292)
    while:    0.000000   0.000000   0.000000 (  0.000014)
    === 10^3 ===
    inject:   0.000000   0.000000   0.000000 (  0.003008)
    each:     0.000000   0.000000   0.000000 (  0.002914)
    times:    0.000000   0.000000   0.000000 (  0.002891)
    while:    0.000000   0.000000   0.000000 (  0.000079)
    === 10^4 ===
    inject:   0.020000   0.010000   0.030000 (  0.029825)
    each:     0.020000   0.010000   0.030000 (  0.028448)
    times:    0.020000   0.010000   0.030000 (  0.028573)
    while:    0.000000   0.000000   0.000000 (  0.000717)
    === 10^5 ===
    inject:   0.230000   0.090000   0.320000 (  0.315088)
    each:     0.210000   0.100000   0.310000 (  0.306036)
    times:    0.210000   0.090000   0.300000 (  0.304437)
    while:    0.030000   0.000000   0.030000 (  0.021261)
    === 10^6 ===
    inject:   2.410000   0.920000   3.330000 (  3.332743)
    each:     2.320000   0.930000   3.250000 (  3.259242)
    times:    2.320000   0.920000   3.240000 (  3.233116)
    while:    0.320000   0.000000   0.320000 (  0.328699)
    === 10^7 ===
    inject:  24.190000   9.150000  33.340000 ( 33.387602)
    each:    23.350000   9.180000  32.530000 ( 32.795653)
    times:   23.220000   9.100000  32.320000 ( 32.394359)
    while:    3.360000   0.020000   3.380000 (  3.377791)
    === 10^8 ===
    inject: 243.020000  91.920000 334.940000 (335.498686)
    each:   234.440000  92.490000 326.930000 (332.153885)
    times:  234.680000  93.470000 328.150000 (355.418129)
    while:   33.840000   0.160000  34.000000 ( 34.151623)

Look carefully, the good news is that while has been sped up by a factor of 3. You may notice that the execution time of the methods which employ inject, each and times are essentially the same in Ruby 1.9. This could be considered good news too, if we didn’t take a look at the previous output. All three methods in Ruby 1.9 are 2 to 3 times slower than in Ruby 1.8. each and times were both faster than while and are now 10 times slower! Forget about inject for a second, which after all can be avoided; but idiomatic Ruby code uses each iterators all over the place. Am I missing something, or Houston, do we have a problem? This loss of performance, if confirmed, should be considered as a bug.

To expose the extent of this regression, let’s see how JRuby 1.1RC3 (with the -J-server option enabled) performs:

    ==== 10^1 ===
    inject:   0.150000   0.000000   0.150000 (  0.150000)
    each:     0.001000   0.000000   0.001000 (  0.001000)
    times:    0.001000   0.000000   0.001000 (  0.001000)
    while:    0.000000   0.000000   0.000000 (  0.000000)
    ==== 10^2 ===
    inject:   0.001000   0.000000   0.001000 (  0.002000)
    each:     0.001000   0.000000   0.001000 (  0.001000)
    times:    0.001000   0.000000   0.001000 (  0.001000)
    while:    0.000000   0.000000   0.000000 (  0.001000)
    ==== 10^3 ===
    inject:   0.011000   0.000000   0.011000 (  0.011000)
    each:     0.017000   0.000000   0.017000 (  0.018000)
    times:    0.012000   0.000000   0.012000 (  0.012000)
    while:    0.004000   0.000000   0.004000 (  0.003000)
    ==== 10^4 ===
    inject:   0.092000   0.000000   0.092000 (  0.091000)
    each:     0.020000   0.000000   0.020000 (  0.020000)
    times:    0.018000   0.000000   0.018000 (  0.018000)
    while:    0.008000   0.000000   0.008000 (  0.008000)
    ==== 10^5 ===
    inject:   0.059000   0.000000   0.059000 (  0.058000)
    each:     0.030000   0.000000   0.030000 (  0.030000)
    times:    0.031000   0.000000   0.031000 (  0.031000)
    while:    0.024000   0.000000   0.024000 (  0.024000)
    ==== 10^6 ===
    inject:   0.377000   0.000000   0.377000 (  0.377000)
    each:     0.269000   0.000000   0.269000 (  0.268000)
    times:    0.251000   0.000000   0.251000 (  0.251000)
    while:    0.153000   0.000000   0.153000 (  0.154000)
    ==== 10^7 ===
    inject:   3.411000   0.000000   3.411000 (  3.411000)
    each:     2.558000   0.000000   2.558000 (  2.558000)
    times:    2.492000   0.000000   2.492000 (  2.493000)
    while:    1.386000   0.000000   1.386000 (  1.385000)
    ==== 10^8 ===
    inject:  33.743000   0.000000  33.743000 ( 33.743000)
    each:    25.408000   0.000000  25.408000 ( 25.408000)
    times:   25.127000   0.000000  25.127000 ( 25.128000)
    while:   13.834000   0.000000  13.834000 ( 13.835000)

sum_with_while (the quickest one of the lot) in JRuby is 2.5 times faster than Ruby 1.9, or almost 8 times faster than Ruby 1.8. inject, each and times are 10 to 13 times faster in JRuby than 1.9.

Believe it or not, even Rubinius is faster than Ruby 1.9 (excluding while):

    === 10^1 ===
    inject:   0.000222   0.000000   0.000222 (  0.000230)
    each:     0.000152   0.000000   0.000152 (  0.000154)
    times:    0.000140   0.000000   0.000140 (  0.000141)
    while:    0.000148   0.000000   0.000148 (  0.000149)
    === 10^2 ===
    inject:   0.000390   0.000000   0.000390 (  0.000394)
    each:     0.000232   0.000000   0.000232 (  0.000239)
    times:    0.000164   0.000000   0.000164 (  0.000165)
    while:    0.000153   0.000000   0.000153 (  0.000165)
    === 10^3 ===
    inject:   0.001210   0.000000   0.001210 (  0.001208)
    each:     0.000827   0.000000   0.000827 (  0.000828)
    times:    0.000396   0.000000   0.000396 (  0.000388)
    while:    0.000223   0.000000   0.000223 (  0.000224)
    === 10^4 ===
    inject:   0.015619   0.000000   0.015619 (  0.015602)
    each:     0.006985   0.000000   0.006985 (  0.006980)
    times:    0.002393   0.000000   0.002393 (  0.002397)
    while:    0.001104   0.000000   0.001104 (  0.001105)
    === 10^5 ===
    inject:   0.212239   0.000000   0.212239 (  0.212221)
    each:     0.155911   0.000000   0.155911 (  0.155898)
    times:    0.114280   0.000000   0.114280 (  0.114267)
    while:    0.081416   0.000000   0.081416 (  0.081400)
    === 10^6 ===
    inject:   2.339344   0.000000   2.339344 (  2.339332)
    each:     1.880382   0.000000   1.880382 (  1.880340)
    times:    1.441064   0.000000   1.441064 (  1.441048)
    while:    1.277817   0.000000   1.277817 (  1.277779)
    === 10^7 ===
    inject:  23.969469   0.000000  23.969469 ( 23.969452)
    each:    20.468222   0.000000  20.468222 ( 20.468203)
    times:   16.952604   0.000000  16.952604 ( 16.952586)
    while:   14.341948   0.000000  14.341948 ( 14.341921)
    === 10^8 ===
    inject: 285.504220   0.000000 285.504220 (285.504203)
    each:   233.995257   0.000000 233.995257 (233.995240)
    times:  200.869457   0.000000 200.869457 (200.869444)
    while:  196.518120   0.000000 196.518120 (196.518106)

Is this issue with Ruby 1.9 being addressed?

Update:

Upon further investigation, the issue has been confirmed on Mac OS X, but it doesn’t exist on Linux. From within a virtual machine running Ubuntu on my Mac, I got the following results:

    === 10^1 ===
    inject:   0.000000   0.000000   0.000000 (  0.000017)
    each:     0.000000   0.000000   0.000000 (  0.000009)
    times:    0.000000   0.000000   0.000000 (  0.000009)
    while:    0.000000   0.000000   0.000000 (  0.000007)
    === 10^2 ===
    inject:   0.000000   0.000000   0.000000 (  0.000025)
    each:     0.000000   0.000000   0.000000 (  0.000031)
    times:    0.000000   0.000000   0.000000 (  0.000024)
    while:    0.000000   0.000000   0.000000 (  0.000013)
    === 10^3 ===
    inject:   0.000000   0.000000   0.000000 (  0.000253)
    each:     0.000000   0.000000   0.000000 (  0.000131)
    times:    0.000000   0.000000   0.000000 (  0.000144)
    while:    0.000000   0.000000   0.000000 (  0.000001)
    === 10^4 ===
    inject:   0.000000   0.000000   0.000000 (  0.000000)
    each:     0.000000   0.000000   0.000000 (  0.000000)
    times:    0.000000   0.000000   0.000000 (  0.000000)
    while:    0.000000   0.000000   0.000000 (  0.000000)
    === 10^5 ===
    inject:   0.040000   0.000000   0.040000 (  0.028453)
    each:     0.020000   0.000000   0.020000 (  0.027007)
    times:    0.030000   0.000000   0.030000 (  0.025450)
    while:    0.010000   0.000000   0.010000 (  0.015040)
    === 10^6 ===
    inject:   0.360000   0.000000   0.360000 (  0.358824)
    each:     0.340000   0.000000   0.340000 (  0.333370)
    times:    0.370000   0.000000   0.370000 (  0.378156)
    while:    0.240000   0.000000   0.240000 (  0.243033)
    === 10^7 ===
    inject:   4.040000   0.000000   4.040000 (  4.046872)
    each:     4.120000   0.010000   4.130000 (  4.160456)
    times:    3.530000   0.000000   3.530000 (  3.544973)
    while:    2.610000   0.000000   2.610000 (  2.613019)
    === 10^8 ===
    inject:  44.870000   0.040000  44.910000 ( 45.146779)
    each:    37.590000   0.020000  37.610000 ( 37.803406)
    times:   36.550000   0.010000  36.560000 ( 36.618813)
    while:   26.690000   0.010000  26.700000 ( 26.747007)

Conclusion: the inject, each and times methods are much slower in Ruby 1.9 on Mac. As you can see from the comments, this seems to be caused by the fact that the function sigsetjmp() was introduced during revision 15124 and it happens to be much slower on Mac OS X than it is on Linux.

• Ruby , Ruby on Rails
• Comments(21)

Antonio Cangiano March 20th, 2008

Django seems to have reached its tipping point, that critical mass which will enable its momentum to skyrocket. Getting here took a while though; partially because of a lack of hype and partially due to Rails’ very prominent presence in the market. Now this well deserving framework has finally begun to be widely adopted and considered as a valid alternative to Rails, for agile web development. Why do I care about what other people are going to use? I care because I’m deeply passionate about technology that works and that keeps things as simple as possible - as such forms of innovation always should. Independently from their adoption, promotion, and the differences in their approaches, both Django and Rails have at their core, a lot of substance and can greatly simplify and improve the way a web developer’s creative process flows.

Stating that Django has reached its tipping point is a bold claim, but I can present some evidence to back it up. I will use Rails and Ruby as a comparison for Django and Python - but don’t construe this as a race between the two frameworks. Rails is still the most popular and will probably continue to be for a long time. I’m only comparing the numbers to get an idea of where Django stands right now.

Visiting irc.freenode.net, I’ve noticed that the Python (#python) channel is often more populated than the Ruby one (#ruby-lang), and the same goes for Django (#django) and Ruby on Rails (#rubyonrails). For example, right now I see 517 members for Python and 354 for Ruby, 382 for Django and 298 for Rails. Django and Python consistently have more hackers in their chats than Rails and Ruby. This doesn’t say too much, given that the average developer doesn’t hang out on irc, but it’s still somewhat indicative of Django’s growing community.

Moving to newsgroups/Google Groups, things start to change a little. As I write this, there are 12,457 subscribers for comp.lang.python and only 6,935 for comp.lang.ruby (with 1,857 members in ruby-talk-google). “Django users” has 8,178 members versus the 13,355 of “Ruby on Rails: Talk”. So far this month, the Django group has had 1,244 messages versus the 2,890 of the Rails one. By looking at these numbers, without any pretense of being too scientific in our comparative methods, we get the impression that the Rails community is almost twice as big as the Django one, which sounds about right. On the other hand we also get that the Python community is larger than the Ruby one (confirmed also by the irc results above). In looking at these numbers, Rails also has the advantage of being the most used Ruby framework by far. In Python-land, Turbogears (3,303 members), Pylons (1,333 members) and good old Zope split the pie too, even though Django remains the most popular choice. Guido van Rossum’s blessing for Django was just the icing on the cake.

By observing the TIOBE Index, we see that Python is in 7th position versus the 10th position where we find Ruby. Perhaps more interestingly, Python has had a +0.70 delta since last March, while Ruby a -0.11%. Again, this is certainly not an exact science, my friends. TIOBE accuracy is often disputed for good reason, but I think it’s still an indicative factor.

Speaking of less than entirely reliable things, Alexa (django vs rails), Compete, and Google Trends (yes, rails is a very generic term) all confirm the anecdotal evidence that Rails is still far more popular. That said, the values start to be at least somewhat comparable.

In my opinion the strongest indicators of Django’s increasing popularity come from the publishing world. You’ll see many books in print for a given topic, only if their publishers believe that there is a large enough market for them. In 2007 the following two books were published: Professional Python Frameworks: Web 2.0 Programming with Django and Turbogears and The Definitive Guide to Django: Web Development Done Right (available for free online). 2008 has only just started and already there’s been one Django title published (Sams Teach Yourself Django in 24 Hours), with two further titles lined up: Practical Django Projects and Python Web Development with Django (which I’m currently reviewing for Pearson, as it’s in the process of being written - and I must say, I think it’s going to be a very good one).

5 books on Django announced to date and more lined up to be released this year, I’m sure. There are now many books in print that cover Rails (my recommendations here), but the sudden spur of Django books reminds me of Rails a couple of years ago and will surely help widen Django’s popularity. Watch closely because things will move fast in Django-land.

• Books , Django , Python , Ruby , Ruby on Rails
• Comments(32)

Antonio Cangiano March 16th, 2008

Keen observers amongst my readers may have noticed that I’ve subtly renamed my blog. It used to be “Zen and the Art of Ruby Programming” and now it just reads “Zen and the Art of Programming”. Perhaps you also noticed that my Ruby logo has been replaced with a cuter one created for the Snakes and Rubies conference, which was held about two years ago at DePaul University (by the way, I don’t know who the creator of that great logo is, but really hope he/she doesn’t mind me using it. If anyone knows who designed it, please let me know so that I can fully give the right person credit for it).

For several months now I’ve been pondering this decision before finally taking the name change plunge. Don’t worry, I’m not going all good ol’ Zed on you. I like Ruby as much as I ever did, I think that in the past four years we have come a long way and I see a bright future for Ruby. My decision has little to do with Ruby or Rails. No Ruby, it’s not you, it’s me.

There are a few reasons beyond my decision:

1. I noticed that, consciously or not, having the word Ruby in the title conditioned me. As Walt Whitman put it, “I am large, I contain multitudes” and I don’t like to limit myself to simply talking about Ruby and Rails. I use and experiment with various programming languages and, especially on a blog located at firstnamelastname.com, I want to feel free to talk about any language that I please - even if chances are that this blog will always be mostly about Ruby.
2. The current title paints a more accurate picture of what this site is all about to my readers. This blog is not only about Ruby, nor is it exclusively about programming languages, so I prefer not to advertise it as such. I’ve seen quite a few comments along the lines of, “oh yeah, Zen and the Art of Ruby Programming”, whenever I blogged about Django, DB2 or anything else that wasn’t strictly Ruby related. Not that I care too much about this type of comment, but if I’m (supposed) to have a title at all, it should at least be somewhat factual.
3. A strongly Ruby-centric blog title may give new readers the false impression that the author of the posts is a highly biased advocate of Ruby. Those who follow my writing, know I value critical thinking and always try to be reasonable in my arguments. I have no qualms with admitting Ruby’s faults, if the occasion warrants doing so. I don’t have a hidden agenda, strive for intellectual honesty, and would prefer to have my opinions valued on the basis of their merits, rather than on a label that’s been given to my blog - or to me. There will always be mindless critics, but I’ve seen far too many harsh comments based on the fact that people jumped to assumptions because they’re sick of “Rails hype blogs”, rather taking the time to actually read what I had to say. I never set out to make everyone happy, but what I just mentioned is definitely a point that I took into consideration when leaning towards the final blog name decision.
4. I will confess that lately I’ve been more into Python and Django, so chances are that I’ll start giving them some serious coverage here.

What’s in a name? A lot, I think. While there may be a slight loss of “branding” and some negative effects when it comes to SEO, I don’t really mind, and it’s a risk that I’m willing to take. I want to explore the possibility of “Zen and the Art of Programming”, even if proves to be a mistake.

• Django , General , Python , Ruby , Ruby on Rails
• Comments(5)

Antonio Cangiano March 4th, 2008

Rails has been a blessing and a curse for the Ruby community. It brought sudden popularity to the language with all the consequences, good and bad, that usually result from exponential growth. On one hand, it gave many developers the chance to appreciate the design of the Ruby language based on its own merit. On the other hand though, it’s been a cash cow that’s changed the community forever by attracting all kinds of attention. Rails has become the poster child for Ruby, blurring the distinction between the Ruby, and Rails, communities. A large number of web programmers got to experience the “ease of use” and beauty of Ruby development, but it also clearly exposed Ruby’s implementation shortcomings. Rails enabled Ruby to go from a relatively unknown programming language to a mainstream one within the frame of just a couple of years. Languages are made to be used, so overall, most would agree that the advantages for Ruby, brought forth by Rails’ success, far outweigh the negative aspects. In the words of Matz, Ruby’s creator:

Rails is the killer app for Ruby.
— Yukihiro Matsumoto

Whatever your take on the subject is, in this article I argue that Ruby on Rails is actually the best thing that ever happened to Python. Rails is a successful Ruby framework, so some may think that it would convince people to switch from Python to Ruby. In other words, naively, one could think of Rails as a Python exterminator, at least as far as web development goes (which is a big deal nowadays). This couldn’t be further from the truth. This year is going to be a great one in terms of the adoption of Python, and I think that Rails has had a positive influence in this regard.

Independently from Rails and Ruby, over the past few years Python has had a good deal of penetration within the market. It wasn’t Java, of course, but as far as dynamic languages go, Python was well represented in many companies and achieved a fairly adopted niche even within the enterprise world. What Rails did was to promote and popularize the usage of MVC web frameworks written in dynamic languages. What could have been considered an unusual choice in the pre-Rails era, is now viewed by most as the right way of developing web applications. The marketing abilities of the Rails community benefited the Python one, in the sense that they made the usage of dynamic languages for serious web projects a very acceptable and even well warranted choice.

Rails got the message out that MVC web frameworks and “scripting” languages could be very productive and much nicer to work with. Django and other web frameworks are indirectly taking advantage of this. A couple of years ago people were asking me whether it was better to adopt Rails or stick with Java for a given project. Nowadays, most emails and requests that I receive are about whether it makes sense to adopt Rails and Ruby or if it would be more sound to use Django and Python.

Initially, even Sun hired Ruby hackers to work on JRuby and have only recently announced that two pythonstas will work on Jython full-time. Yes, they are late to the party and should have done this years ago, but I think that Rails’ popularity and hype led them to consider Ruby first before eventually realizing that they should have done the same thing for Python. Rails has been, at least in part, a catalyst for Python’s success.

Don’t let this confuse you though. Python (and Django) are able to benefit from all the interest geared towards dynamic languages, only because they are technically excellent and make a strong case on their own. Their communities are much less about marketing and more about substance, in my opinion. I understand those who go from Ruby to Python, but there are far fewer motivations in favor of a switch from Python to Ruby. The reason for this is that, in a way, Python is currently an answer to Ruby’s MRI shortcomings. When I speak about Ruby’s shortcomings I always refer to the implementation and not to the design of the language, which is a well balanced and coherent mix of paradigms and features.

Things will change with Rubinius (and perhaps JRuby), but as it stands right now, Ruby’s implementation has critical limitations that affect the development of non-toy projects and its adoption within the enterprise world. Speed, I/O processing, threads, garbage collection and troubling deployment when compared to other languages, are serious issues. It doesn’t mean that you can’t use it, just that the limitations that are in place will make your life more difficult on certain projects.

In a way, Python is the only acceptable implementation of Ruby for certain values of Ruby. The two languages have different approaches and quite a few distinctions which make them both unique. Overall though there are plenty of similarities that make developing in one or the other a somewhat comparable mental process and coding experience. Sure, Python doesn’t promote the functional paradigm as much, and it’s less implicit/magical than Ruby (read import this). This could be a good thing when it comes to large and enterprise projects, but the two are all not that different from each other. They’re Capelli d’angelo and Spaghettini, as my fellow countryman Alex Martelli eloquently put it.

As much as I may like Ruby more as far as language design goes, not only does Python boast a very solid implementation, it has several advantages over Ruby that go beyond the interpreter. I’ve found that Python has an incredible amount of rock solid, high quality libraries that perform very well. Not all of them of course, but most are well coded, maintained and documented. In Rubyland we can’t claim the same levels of good reusable code. I use both and I see a big difference. Lingering for a moment on the subject of documentation, Python has a wealth of tutorials, guides and even entire books available for free online. Learning Python from these, without spending a cent, is a walk in the park. Ruby on the other hand has good books in print, but a long way to go as far as free documentation goes. And this is true for both Ruby and Rails.

The community attitude is much different too. The Python and Django communities generally keep a low profile, following the “shut up and show them the code” mantra. They do have some marketing issues but can’t be blamed for hyping their technology, like at least in part, Rails has done. For example, Django is a very mature framework that’s several years old, and yet it still hasn’t been tagged as a 1.0 version. If Twisted Matrix was implemented in Ruby it would be advertised as the second coming of Christ. Jokes aside, I feel that the Python community has a very good attitude which is in no way altered by the Django one, because it happens to share the same traits. There are no exclusive private clubs or the feeling of experiencing a technological “gold rush”, even though the community is in no way smaller. This may seem like a minor point, but for many the maturity, pragmatism and attitude of the community is a big selling point for Python/Django.

I’ll refrain from indulging in a full length comparison of Rails and Django. But I must briefly mention that Django takes the cake when it comes to creating applications that do web publishing (for obvious background reasons). Despite attempts to put Photoshop online, I feel that most of the web is still about publishing and interacting with published data. This makes Django a good choice in most cases. Of course, should you develop a web application that intends to replace a desktop app, Rails will most likely have the edge there.

So what does this mean for me personally? I’ll use them both, as I’m a firm believer in using the right tool for the right job. I’ll give you an example. Stacktrace.it is a small revolution in the Italian IT publishing world. A few months ago I contacted about 30 people from amongst the best Italian hackers and IT professionals and I proposed that together we create a site in which we’d promote and influence software development and IT in general in Italy (even if I live in Canada myself). The site has been going very well and has attracted a group of highly technical people who follow and contribute regularly with high quality articles. The code was based on Luambo, an open source blog engine yet to be officially packaged and promoted to the world. What was remarkable about it was that most of the new features that were requested in our private mailing list ended up in the code in less than five minutes. An unbelievable level of productivity. Even our designer, who was not familiar with the language or the framework, was easily able to work on the project. Guess what? Despite loving Ruby and Rails, when it came to deciding on the framework and language to be used for that project, I strongly pushed for the adoption of Django and Python, and not Ruby on Rails. It was simply the right tool.

• Books , Django , Python , Ruby , Ruby on Rails
• Comments(38)

Antonio Cangiano February 29th, 2008

James Governor wrote an interesting post entitled “On douchebags, DB2 and Rails: DHH not pragmatic enough?”. It’s partially in response to Jeff Atwood’s article “Douchebaggery” which, in turn is a reply to an old post by David Heinemeier Hansson. So please excuse me if I limit the entertainment value of this post by not calling anyone names.

Amongst a few sensible comments, James also argues that David may not be nearly opinionated and pragmatic enough after all:

What’s bothering me though is that perhaps Hansson isn’t opinionated enough. You see Rails targets MySQL. MySQL is the Rails database. Forget all the configuration crap and just use MySQL. There is no need to consider other database platforms. LAMP may or may not be a literal but MySQL is utterly embedded in the Rails way. In Rails database is not a design decision, its a given.

As most of you will already know, Rails was extracted from a real web application called Basecamp. This approach is thought to be the first sign (scientists believe there are 37 of them :-P) that we are dealing with a pragmatic framework. Its features and design choices weren’t defined a priori by David, but they were implemented to satisfy particular needs (and opinions) which Hansson and his team had, while developing database driven web applications.

When analyzed under a proverbial microscope, one sees that Rails didn’t actually invent anything new. Neither the MVC paradigm nor the Active record pattern were especially innovative. They’d been well known for years in the Computer Science world and even adopted (to a certain extent) within the enterprise realm. Yet, Rails was a revolutionary piece of software. What Rails did was to tie all the loose ends together into a neat, tidy package. On top of that achievement, it clearly favored simplicity, pragmatism and developer productivity over anything else. Forget about repetition and countless XML configuration files, it was opinionated software that made web development, or at least most of it, rather trivial. Less choices for the developer (the Paradox of Choice comes to mind) turned out to be a significant gain in terms of “ease of use”, which in turn bolstered Rails’ adoption.

Rails wasn’t supposed to be the answer to all web development needs everywhere - just to most of them. This means that the making of such a DSL involved a lot of assumptions. In turn, there are people who don’t use Rails due to these assumptions, and projects where adopting Rails wouldn’t probably be the smartest choice either. But Rails worked for David and 37Signals, and in doing so, it also happens to work very well for thousands of other developers around the world with similar development needs, who’re facing analogous challenges. David did his best to create a usable and enjoyable web framework, and succeeded spectacularly in responding to the needs of most web developers.

For this, Rails constantly gets accused of being far too opinionated. How many times have we seen comments about the lack of prepared statement support, that there’s no connection pool, no thread safety, no unicode, about deployment issues and so on. James’ comments are interesting because they’re entirely unusual. He’s arguing that Rails is not opinionated enough, and that in itself, is an opinion worth replying to (and not simply because he explicitly called upon my views on the subject at hand within his post):

Why in the Getting Started section of the book, do the authors even mention DB2 as a potential target database, even if its just an aside (Rails does allow exceptions it just doesn’t like them)? I mean if a DB2 bigot came to ask Hansson for a job at 37Signals he would be shit out luck wouldn’t he? You can imagine the laughs- “this guy wants to back end Rails apps with DB2 - what a ***tard.”

I know Anthony would disagree with me, and arguably Rails abstracts the database decision, so Rails is not tightly coupled to MySQL. But that’s not the point - we’re not talking about JDBC here.

I’m pretty sure that David doesn’t care about shared hosting, prepared statements, support for stored procedures, JRuby, DB2 or the “enterprise world”. It’s not his way of creating and going about web development, plus he really doesn’t have any need of these for his own purposes. Therefore don’t expect support for these points from him. However, that said, David is also being fairly reasonable with those who think differently than he does.

David’s message is: if you need these type of features, then please by all means, go ahead and implement them yourself. Rails’ core team has enabled the development community to extend Rails to fit a different kind of bill. While the policy in terms of accepting patches may be strict and not particularly welcoming of every single contribution, the plugin architecture coupled with Ruby’s flexibility and extensibility, allows the injection of substantial features which in turn significantly affect Rails. There are limits of course, and some people even preferred to create a similar framework from scratch, because they found it easier and neater to do so than to completely restructure and refactor Rails’ core.

David clearly favors opinionated conceptual integrity and the act of defining a set of sensible conventions over abstraction/modularity/extensibility, which would be regarded highly by those who require enterprise features or view web development in a markedly different way. He did not intentionally set out to block these things either though, and that’s worth remembering. He proposed his take on things, but he certainly did not impose it on anyone else. Doing so simply would not make sense (and might have required more work on his part in some cases).

Take ActiveRecord for example: it’s not a perfect abstraction, given that its Ruby implementation makes several MySQL centric assumptions in regards to SQL generation, which makes development of alternative adapters for other databases less than trivial (particularly for so called enterprise databases). But it’s still essentially a database agnostic pattern that would be almost harder not to implement as such. David’s implementation poses a few challenges here and there, but we’re still very much within the realm of possibility.

David might only use Rails with MySQL, and he may only slightly care about the subset of features which are common to all databases (including SQLite, the current default database) and nothing more, but at the same time he clearly realizes that we are not all Davids. He’s not willing to warp his creation in order to make everyone happy. That’s not David’s style. However, if other databases or options are available to Rails developers, why not mention them as a testament of the interest surrounding Rails?

The fact that DB2 is a viable (free of charge) option for Rails developers doesn’t affect the Rails core team in a perceivable way, and it still offers the possibility of using Rails to a whole new segment of programmers. Which bring us to the next point:

Anthony says “an increasing number of Rails developers adopting DB2 as their database of choice”. I would like to know more about this “increasing number” from Anthony [...]

While perhaps not the most vocal bunch in the blogosphere, there are many developers and companies interested in DB2 on Rails. In my experience, I’d say that there are three main likely/common scenarios (of DB2 on Rails users):

1. Companies who have already widely adopted DB2 in their infrastructure and are now considering Rails for some of their projects. The developers involved are usually very excited about DB2 on Rails, because it means that they have a rare chance to use Ruby/Rails rather than Java/J2EE or similar technologies, with a data server that they already have a good understanding of. While some web developers choose the framework first and consider the database at a latter stage, most companies don’t work that way.
2. Developers who have DB2 skills and are looking for a good framework for developing web applications. They have no reason to use any other database but DB2.
3. Companies or developers who understand the technological advantage offered by DB2’s features (e.g. utmost speed, pureXML, compression, replication, high availability, affordable 24/7 support, etc…) and therefore choose it for their Rails based projects.

Rails doesn’t exploit advanced database features, and as a result, it doesn’t provide any further compelling reasons to adopt other databases aside from MySQL. It takes a discerning developer to realize that DB2 has much more to offer and that there are concrete benefits to adopting it - even when developing with Rails.

It’s also true that working with an independent adapter in Rails will generally be less “comfy” than using SQLite/MySQL/PostgreSQL. For example, certain tasks are not implemented for DB2 by the Rails team, and as such won’t be available. But it’s a small price to pay. In order to change this, I decided to start a project in my spare time (not an IBM project), called DB2 Extended. From the RubyForge description: “db2_extended is a Rails plugin that extends support and enhances the user experience for developers who adopt DB2 as their backend for Rails applications”. This project is currently empty, but I hope to perform the first svn commits over the weekend. I’ll start with simple things that close the gap (like making rake db:create work for DB2) and incrementally, I’d love to throw in DB2 specific functionalities and enhancements as well. Being a personal, open source project, I will more than happily accept patches and contributes from the DB2 on Rails community. Hopefully in a short period, we’ll have a plugin that makes web development with Rails and DB2 even more fun and productive.

As usual, these opinions are only mine and don’t necessarily represent my employer’s (IBM) positions, strategies or opinions.

• DB2 , General , Ruby , Ruby on Rails
• Comments(10)