Rails 2.2 RC2: Last stop before final

Rails 2.2 has been baking for long enough now. This is the last taste before the goodies are served. So please install and check it out. See if you can find any regressions or bugs in any of the new stuff, so we can have it all delicious by the time we ring the dinner bell (ok, ok, I’ll put down the food metaphor now).

This release also conciedes with the fact that we’ve branches 2-2-stable, which means that master is now actually targeting Rails 2.3/3.0. There’s also a tag available for this RC as v2.2.1.

If you missed RC1, have a look at the Rails 2.2 release notes to see the major additions. You can see what’s new since RC1 in these two This Week in Edge Rails.

To install, you must first have RubyGems 1.3.1:
gem update --system.

Then you can:
gem install rails -s http://gems.rubyonrails.org

Enjoy!

Ruby Best Practices: The Book and Interview with Gregory Brown

Back in March, Ruby developer Gregory Brown raised the idea of receiving donations so he could work on open source Ruby projects full-time. It went well, and out of this project came Prawn, a pure Ruby PDF generation library. Not one to rest on his laurels, Gregory's now working on a book for O'Reilly called Ruby Best Practices, billed as "for programmers who want to use Ruby the way Rubyists do." The book will cover how to design "beautiful" APIs and DSLs, along with lots of other general topics that will make your code more expressive and make you a better Ruby developer into the bargain.

The book is not due for final release until August 2009, but thanks to O'Reilly's "Rough Cuts" program, the first three chapters (Driving Code Through Tests, Designing Beautiful APIs, and Text Processing and File Management) are already available. Online-only access is $17.99 and you'll get the latest version as it becomes available. Print-only and Print + Online bundles are also available.

Gregory gave me a copy of the first three chapters to look over, and they're well crafted. This definitely isn't a reference book, a "cook book" or any sort of book you merely "dip" into. It's designed to be read by the chapter. The first chapter, Driving Code Through Tests, for example, takes you on a journey through the world of testing in Rubyland from motivation through to best practices - it's a full introduction to a single topic.

The Interview

I decided to ask Gregory a few questions to get more background on the book, as well as an update on his Ruby Mendicant project:

What was the inspiration for writing Ruby Best Practices?

Right now, it's entirely possible for one to learn enough Ruby to get by without ever understanding why people love the language. I think one reason is that our books have disproportionately emphasized on solving particular problems, via some recipe or pattern. We've also got a ton of introductions to the language, some better than others, but these books don't dive into code that looks or feels real. Our reference books are great (at least IMO), but they're only telling you what sharp tools are in the shed, not how to use them.

Ruby Best Practices is a book about why Rubyists tend to write Ruby the way they do. So this book looks at a lot of real code, most of it from open source projects, and tries to make it approachable to any reader who's got a reference book handy, so long as their willing to engage their brain a bit. I'm hoping that people will have fun learning a bit more about the 'why' behind a lot of the design decisions we face when writing code.

Does the rapid pace of change in the Ruby community makes writing a book like this more difficult?

I think change is generally good, and that folks who wish to live on the edge must be willing to pay the price. There's nothing wrong with using older versions of software if you're not ready to make the jump to the new hotness of the week.

However, I want this book to be current when it prints, and I also want to help encourage people to move forward, so I've been writing against Ruby 1.9.1 only. Because the only place 1.8 is mentioned is in my chapter on how to write backwards-compatible code, I don't have the pain that most people do with updating their notes constantly about changes in 1.9 vs 1.8. I just need to make sure my code keeps running properly on 1.9.1 until the time the book is released. There are hiccups from time to time, but I've definitely been in less pain than anyone who's trying to write a reference book right now.

What sort of developer should be buying this book right now?

I think that any developer who has worked through some introductory Ruby material and has a reference book handy can learn something from RBP. I've got a couple internal reviewers who are in exactly that position, so they help keep that target audience in range.

However, in terms of the Rough Cuts release, what I need most is folks who are fairly strong in idiomatic Ruby to pick up a copy and help correct me where I am wrong. I put together a great team of internal reviewers who check every chapter before it becomes public, but more eyes will surely help shape the book before it hits the shelves.

I definitely want the book to have the kind of authority that comes from extensive peer review instead of having people trust it based on name recognition. If people provide feedback through Rough Cuts, I think it'll be easier to accomplish that goal.

How is the Ruby Mendicant project going?

The Ruby Mendicant project officially ended on September 30th, two weeks after the scheduled end-date. However, I'm still actively working on Prawn and will continue to move things forward over the coming months. I came up a little short of the hours I initially pledged, but accomplished most of the goals I had in mind. We're getting closer and closer to providing a replacement for PDF::Writer, and many users have already made the jump.

I gave a talk on Ruby Mendicant / Prawn at RubyConf, and it's probably the best summary I've done so far, which people could check out once Confreaks gets the video online. I also plan to write a post-mortem about the whole experience but haven't found time just yet. I'll link it on that talk page once it's available.

Myth #3: Rails forces you to use Prototype

There are lots of great JavaScript libraries out there. Prototype is one of the best and it ships along Rails as the default choice for adding Ajax to your application.

Does that mean you have to use Prototype if you prefer something else? Absolutely not! Does it mean that it's hard to use something else than Prototype? No way!

It's incredibly easy to use another JavaScript library with Rails. Let's say that you wanted to use jQuery. All you would have to do is add the jQuery libraries to public/javascripts and include something like this to the <head> in your layout to include the core and ui parts:

<%= javascript_include_tag "jquery", "jquery-ui" %>

Then say you have a form like the following that you want to Ajax:

<% form_for(Comment.new) do |form| %>

  <%= form.text_area :body %>

  <%= form.submit %>

<% end %>

By virtue of the conventions, this form will have an id of new_comment, which you can decorate with an event in, say, application.js with jQuery like this:

$(document).ready(function() {

  $("#new_comment").submit(function() {

    $.post($(this).attr('action') + '.js', 

      $(this).serializeArray(), null, 'script');

 

    return false;

  });

});

This will make the form submit to /comments.js via Ajax, which you can then catch in the PostsController with a simple format alongside the HTML response:

def create

  @comment = Post.create(params[:comment])

 

  respond_to do |format|

    format.html { redirect_to(@comment) }

    format.js

  end

end

The empty format.js simply tells the controller that there's a template ready to be rendered when a JavaScript request is incoming. This template would live in comments/create.js.erb and could look something like:

$('#comments').append(

  '<%= escape_javascript(render(:partial => @comment)) %>');

$('#new_comment textarea').val("");

$('#<%= dom_id(@comment) %>').effect("highlight");

This will append the newly created @comment model to a dom element with the id of comments by rendering the comments/comment partial. Then it clears the form and finally highlights the new comment as identified by dom id "comment_X".

That's pretty much it. You're now using Rails to create an Ajax application with jQuery and you even get to tell all the cool kids that your application is unobtrusive. That'll impress them for sure :).

Rails loves all Ajax, not just the Prototype kind
This is all to say that the base infrastructure of Rails is just as happy to return JavaScript made from any other package than Prototype. It's all just a mime type anyway.

Now if you don't want to put on the unobtrusive bandana and instead would like a little more help to define your JavaScript inline, like with remote_form_for and friends, you can have a look at something like jRails, which mimics the Prototype helpers for jQuery. There's apparently a similar project underway for MooTools too.

So by all means use the JavaScript library that suits your style, but please stop crying that Rails happens to include a default choice. That's what Rails is. A collection of default choices. You accept the ones where you don't care about the answer or simply just agree, you swap out the ones where you differ.

Update: Ryan Bates has created a screencast that shows you how to do the steps I outlined above and more.

See the Rails Myths index for more myths about Rails.

Myth #3: Rails forces you to use Prototype

There are lots of great JavaScript libraries out there. Prototype is one of the best and it ships along Rails as the default choice for adding Ajax to your application. Does that mean you have to use Prototype if you prefer something else? Absolutely not! Does it mean that it's hard to use something else than Prototype? No way!

It's incredibly easy to use another JavaScript library with Rails. Let's say that you wanted to use jQuery. All you would have to do is add the jQuery libraries to public/javascripts and include something like this to the <head> in your layout to include the core and ui parts:

<%= javascript_include_tag "jquery", "jquery-ui" %>

Then say you have a form like the following that you want to Ajax:

<% form_for(Comment.new) do |p| %>

  <%= p.text_area :body %>

  <%= p.submit %>

<% end %>

By virtue of the conventions, this form will have an id of new_comment, which you can decorate with an event in, say, application.js with jQuery like this:

$(document).ready(function() {

  $("#new_comment").submit(function() {

    $.post($(this).attr('action') + '.js', 

      $(this).serializeArray(), null, 'script');


    return false;

  });

});

This will make the form submit to /comments.js via Ajax, which you can then catch in the PostsController with a simple format alongside HTML and XML responses:

def create

  @comment = Post.create(params[:comment])


  respond_to do |format|

    format.html { redirect_to(@comment) }

    format.xml  { render :xml => @comment, :status => :created, :location => @comment }

    format.js

  end

end

The empty format.js simply tells the controller that there's a template ready to be rendered when a JavaScript request is incoming. This template would live in comments/create.js.erb and could look something like:

$('#comments').append('<%= escape_javascript(render(:partial => @comment)) %>');

$('#new_comment textarea').val("");

$('#<%= dom_id(@comment) %>').effect("highlight");

This will append the newly created @comment model to a dom element with the id of comments by rendering the comments/comment partial. Then it clears the form and finally highlights the new comment as identified by dom id "comment_X".

That's pretty much it. You're now using Rails to create an Ajax application with jQuery and you even get to tell all the cool kids that your application is unobtrusive. That'll impress them for sure :).

This is all to say that the base infrastructure of Rails is just as happy to return JavaScript made from any other package than Prototype. It's all just a mime type anyway.

Now if you don't want to put on the unobtrusive bandanna and instead would like a little more help to define your JavaScript inline, like with remote_form_for and friends, you can have a look at something like jRails, which mimics the Prototype helpers for jQuery. There's apparently a similar project underway for MooTools too.

So by all means use the JavaScript library that suits your style, but please stop crying that Rails happens to include a default choice. That's what Rails is. A collection of default choices. You accept the ones where you don't care about the answer or simply just agree, you swap out the ones where you differ.

This Week in Edge Rails

The important news in edge Rails this week is the imminent release of Rails 2.2.1 – otherwise known as Rails 2.2 RC2. Getting ready for this release did lead to some significant changes in the Rails codebase.

First, it’s very likely that you’ll need to upgrade rubygems to run RC2: the required version of rubygems is now 1.3.1, which was just released yesterday. This dependency is part of the continued work to make vendored gems useful and stable. You may find that updating rubygems is less than smooth, depending on your current version; check out this article if you have any trouble. commit

The Rails routing engine has seen some serious work over the past week as well. For starters, Jeremy Kemper committed several fixes to the core routing engine that cut down on object creation and RegExp creation, trimming memory use. commit commit There are also new :only and :except options for map.resources, which can help cut down memory use if you have a lot of resource routes – see these articles for details (though there have been some tweaks in the way nested limited routes work after those were written). commit commit commit

The new ActiveRecord connection pooling code has seen some tuning as well, making it more efficient in development model and avoiding some issues with the Oracle adapter. commit

Polymorphic URLs now behave more intuitively if one of their parameters is nil. For example, a call to polymorphic_path([@project, @filter, @issue]) with a nil filter now returns project_issue_url instead of a NoMethodError. commit

The request forgery protection feature in Rails has been tightened up so that it only applies to HTML-formatted content requests. There is substantial discussion on the Lighthouse ticket that led to this change, but the bottom line is that the old implementation had some bugs, notably making destroy actions inaccessible via XML. Other types of requests are protected by other means – for instance, the same origin policy on AJAX requests substitutes for request forgery protection there. commit

Double Shot #332

Been having great fun coming up to speed with shoulda the last few days. I think it’s finally starting to make sense to me, though surely there are best practices I’m still missing.