Zen and the Art of Programming

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 19th, 2008

Lately I’ve been thinking about the length of my blog posts. I humbly assume that they’re somewhat interesting to my readers, given the numerical growth of my audience, but almost each of the articles is a long essay or analysis that takes up a fair deal of time for both me and you. I believe that this prolixity is often entirely worth it, just as I don’t mind investing time in reading essays by Paul Graham or Steve Yegge. However, I’ve been wondering if I’ve set this expectation of writing something in-depth or not writing at all, for myself. The downside is that busy readers may have to skip quite a few of my articles, and I end up posting less frequently and necessarily limiting the number of subjects I can touch on.

With Twitter’s boom, an entire field of people with short attention spans, and very busy lifestyles being common, it is clear to me that people tend to prefer information in small, easy to swallow pills whenever possible. That’s why nano-publishers, who technically don’t add much to the discussion, tend to be so popular. 3,000 word articles are nice, and sometimes required, but perhaps I’ve been missing out by not allowing myself to post short considerations, incipits of discussions or content that can be quickly read, even if it’s never going to become a classic must-read computer science paper.

The inspiration for this came to me when analyzing my feeds. Out of hundreds of feeds, the only blog I constantly end up reading post-by-post is the one by Seth Godin. The ironic thing is that if you ask me what I think about it, I would tell you that what he says appears to me as common sense. I agree with him most of the time, he thinks out of the box and provides inspiration in the form of good suggestions, but his blog is not a Purple Cow. Yet, a lover of long essays like myself, follows his blog because the format that he’s adopted is simply effortless to read. He proposes small bites of thought and usually nothing more, but they are good bites, and that’s often enough. I’m busy yes, but I can spare those few seconds that it takes me to read Seth’s posts.

I wonder if I should adopt a more “relaxed” style for this blog, in which short thoughts about programming get published alongside longer ones. This post contains 417 words, in case you are curious.

• General
• Comments(5)