Zen and the Art of Programming

Antonio Cangiano April 28th, 2008

This is the 5th episode of This Week in Ruby, please consider subscribing to my feed so as to not miss any weekly installments.

Rails

For some, the greatest Rails news this week was the announcement of a third edition of the Agile Web Development with Rails book. It’s currently in beta and will be finished by October, much to the anticipation of many, I’m sure.

Another interesting development, this time based on actual code, was announced through a post by Ezra Zygmuntowicz, entitled Hey Rails, nice Rack!. Basically, he’s working on “porting Merb’s rack machinery to rails” and it’ll eventually be merged with Rails’ core.

Three Rails related articles caught my eye in particular over the last few days. The first is 5 little-known Rails methods. I’d like to think that most Rails developers already take advantage of them, but if you don’t, it’s a good idea to learn about them now. The second is Building a Social Network Site in Rails, which is not a step-by-step guide, but rather a list of useful resources for building such a site. And finally, I liked Database agnostic != database ignorant in which the author provides a very basic intro to SQL joins and indexes. A much needed piece in the Rails community.

Ruby

The big news in this realm is that GitHub has began serving RubyGems. You can follow the instructions here, and read a nice interview with Chris Wanstrath, too.

JRuby 1.1.1 was released and I’m constantly more impressed by the speed of development of that project. Speaking of which, Charlie Nutter has published an excellent overview and status update of the various alternative Ruby implementations - and don’t miss the video of John Lam’s presentation on IronRuby’s status and DLR.

RubyLearning published a guide to Yahoo! Web Services in Ruby. And by the way, the same site is looking for ways to promote their free Ruby eBook.

Three interesting Ruby articles I want to point out are A Look at Ruby Debuggers by InfoQ, a tutorial about building Mac apps with RubyCocoa and XCode and a screencast on video transcoding and uploading to Amazon S3. Nice stuff.

In the alternative web frameworks arena, Mack 0.4.7 was released as further proof of the development speed of this project. This week Feather was also announced and it’s an open source, lightweight blog engine written in Merb.

Until next week…

• Merb , Ruby , Ruby on Rails , This Week in Ruby
• Comments(6)

Antonio Cangiano April 24th, 2008

The Pragmatic Programmers have announced the beta release of Agile Web Development with Rails, Third Edition. The final version of the book, updated to Rails 2, is scheduled to be released for October 2008. Even if the style of the tutorial is not everyone’s cup of tea, this is good news and they surely picked a great author in my fellow IBM colleague Sam Ruby.

Quoting myself from three weeks ago:

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

I’m happy to see that they’re working on it.

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

Antonio Cangiano April 21st, 2008

This is the 4th episode of This Week in Ruby, please consider subscribing to my feed so as to not miss any weekly installments.

Ruby

As you’ve probably heard by now, this week Ruby 1.8.7-preview1 was released and it’s a major upgrade because it includes several backports from Ruby 1.9. It should help many in this transitionary period without substantially breaking the existing code. On the subject of migrating to Ruby 1.9, I recommend Bruce Williams’ beautiful slides from Scotland on Rails. I’d suggest reading the interview he gave for RubyLearning, in which he dispenses some good advice to Ruby newcomers. Those who’d like something more advanced, may find this clever presentation about metaprogramming very interesting, too.

The funny guys from RailsEnvy came up with an idea for promoting Ruby/Rails people: the Ruby Hero Awards. On the website you can nominate any person from the Ruby community and a panel of community leaders will pick 6 winners and announce them at RailsConf.

With the release of App Engine, Google has surely proven their interest for Python once again. But this month they gave some love to Ruby as well, by releasing a guide for using Ruby with the Google Data APIs.

There were three announcements that may spark your curiosity:

• Ruby-Processing got an upgrade and now has the ability to export Mac applications;
• forkoff was released, and it’s “brain-dead simple parallel processing for Ruby”;
• Nick DeMonner released Stone, a plug&play Ruby solution to data persistence.

Other interesting articles were Converting Groovy to Ruby by Charlie Nutter, Symbols are not pretty strings and the second part of Rubinius for the Layman.

Rails

As mentioned last week, Rails’ repository has moved to GitHub while this week the tracker moved to Lighthouse. With these changes in place you may want to read about the best practices for contributing to Rails with Git and freezing Rails with Git.

The first tutorials for mod_rails have started to pop up, in particular there was this guide for setting up Passenger on SliceHost with Ubuntu 7.10 and the more discursive Why mod_rails is great for light-duty Rails apps.

The website Open Source Rails collects open source projects that are implemented in Rails. It’s surprising how many of them are practically unknown to the community.

This week two must-read, hands-on posts were published: Import Gmail Contacts using Ruby on Rails and Paperclip: Attaching Files in Rails. Both cover tasks that are extremely common and useful for many web developers.

On the more philosophical side, I published an article called Is the Enterprise world Rails ready? in which I discuss Rails’ origins and their consequences on Rails’ applicability within the corporate world. One a somewhat related note, you can read JRuby - Or how I manage to write Ruby in a strict corporate environment and Why I think Ruby on Rails is an ideal web development environment by Andy Jeffries.

Merb

This week the third part of the Merb and DataMapper Book was published (part 1, 2 and 3). Merb is growing very fast and I think it’s fair to say that it has become THE alternative framework to Rails within the community. New features keep popping up and some of them are indeed very clever ones. For example, this week Ezra published a post about deferred requests with Merb, Ebb and Thin. Briefly put, when you adopt an event-based web server like Ebb or Thin, as opposed to plain vanilla Mongrel, any long request will be a blocker. Now Merb offers the possibility to specify that a certain set of actions, like uploading a file, should be handled by spawning a new thread rather than being served by the main event loop. Very clever and excellent stuff.

• Merb , Ruby , Ruby on Rails , This Week in Ruby
• Comments(5)

Antonio Cangiano April 20th, 2008

When searching the web for the words “Rails” and “Enterprise” you’ll find countless discussions about whether Rails is Enterprise ready. Some argue that it is, especially thanks to the extendibility offered by its plugin support, while others claim that realistically it’s not. “Is Rails Enterprise ready?” is the wrong question, I’d rather ask if the Enterprise world is Rails ready. Let me clarify this point.

David Heinemeier Hansson gave a brilliant talk at Startup School, in which he didn’t speak about Rails. He spoke about business models, 37signals’ way of charging for subscriptions to web apps, the odds of a startup becoming the next Facebook and so on. He rarely mentioned Rails, but that presentation can tell you more about Rails and the Enterprise, than most of the essays that you’ll read on the topic.

Companies like 37signals love their way of doing business. They solve problems by creating valuable services for the long tail of small business owners, and of course charge them for doing so. They are all about productivity and having fun in the development process. That’s the kind of environment in which Rails was born. It came out of the necessity to increase productivity, while offering an enjoyable experience to the web programmer, and Ruby, as a language, was the perfect choice for that.

Ruby on Rails was created so as to be an almost perfect match for what David and 37signals needed. They weren’t facing the issue of legacy databases, so they were able to choose simple conventions that made sense for them. They had a server to host their applications, so the whole shared hosting issue that many people complained about was not a problem for them. Rails’ cost of scalability was not troubling for 37signals, because they had paying customers. More scalability issues for companies like 37signals, mean more money rolling in from paying customers; so just throwing hardware at it can be done without frowning. It means that business is good. Given the choice of picking development speed over application speed, in these types of contexts development gains are often a much bigger payoff.

Rails is opinionated because it was tailored for the needs of 37signals and their products. If your web application and business model is somewhat similar to that of David’s company, then Rails is hard to beat and there is little to complain about. Rails will evolve and continue to improve, but most of its focus will remain on 37signals and the needs of similar companies. David prefers to work on real world web applications and introduce the most useful lessons back into the framework, not having them be designed by a committee. That’s why there isn’t a Rails, Inc. and why new Rails features are not arbitrarily introduced to satisfy any possible usage of the framework by the thousands of companies who employ Rails.

Aside from its origins, Rails became a sensation in the web development world. It had a deep impact, just think about how it made the MVC paradigm an accepted and almost expected reality in other web frameworks that come out later. So with everyone jumping on the bandwagon, people started to consider Rails for use in environments that it wasn’t really created for. Namely the so-called Enterprise world.

This is why the question “Is Rails Enterprise ready?” is the wrong one to ask. It questions whether Rails has evolved yet to the point of being able to support developers within the Enterprise. Rails has no expectation of being a good match for the current Enterprise world. It doesn’t now and won’t in the future. There is however an expectation that the Enterprise world will become more Agile and embrace simplicity over complexity. In other words, let’s ask if the current Enterprise is ready for Rails. The answer I’m afraid is not a sound “yes”. Rails can be used in the Enterprise world, and a good part of my job is promoting its adoption exactly in this kind of environment, but there is little point in complaining aloud about the fact that Rails doesn’t have great support for certain features out of the box.

When Dave Thomas made his famous keynote at RailsConf, in which he pointed out important issues that concern the most “enterprisey” customers, David did not embrace the idea at all. The reason is simple, in his eyes, it’s the Enterprise world that needs to change, not Rails.

As a matter of fact, Rails can be successfully used for complex scenarios, and it’s probably still much more productive than using an overkill like J2EE, in most cases. But it’s not natural, it forces you to take advantage of (maintained or not) plugins, and the whole ecosystem around Rails is not very supportive of the needs that you may have.

What happens to those developers who “saw the light” and would like to introduce Rails into an environment where it’s still someone else, or a different team, who defines and handles the database? Plugins help, integration with Java through JRuby is a viable alternative too, but overall the experience can be rather frustrating. The Enterprise, especially when dealing with existing data, can be very slow to adapt. And we all know that fighting against bureaucracy within your large company is anything but enjoyable.

It seems to me that most of the Enterprise is not Rails-ready, just like it’s still hardly Agile-ready. The current compromise is meeting at a middle-ground. Developers add enterprisey features into Rails through plugins, or adopt JRuby on Rails, while at the same time trying to simplify as much as possible in order not to go “against” Rails.

But is there a better way? In the Ruby world, I see two viable possibilities but neither is easy or quick. The strongest one is a Ruby framework that takes into account the needs of the Enterprise, from scratch, while still remaining easy to use like Rails. It would be the equivalent of what motivated the creation of Rails, in a different, substantially more complex environment. The second option is a fork of Rails, specifically targeted towards the Enterprise/Corporate sector, with a rewrite and expansion of a few key components in order to make it a superset of Rails.

Whoever creates either of these frameworks well, will be worth their weight in gold.

• DB2 , Ruby , Ruby on Rails
• Comments(13)

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)