Ruby Inside's sister site, Rails Inside, was launched alongside Rails 2.1 in June, and would, you'd think, be the ideal place for a post like this, but no. Rails is very significant to the Ruby world as a whole, so you'll still get the biggest of the biggest Rails announcements here on Ruby Inside! If you want more regular Rails-only news, however, go and subscribe to Rails Inside (RSS feed or e-mail subscription).

As is typical for a big release, we've pooled together a ton of excellent resources, links, and what not, to help you get fully into the Rails 2.2 mindset. So if you've got Rails 2.2 running already or if you're just investigating what it could do for you, read on and investigate some of these resources.

General Documentation and Guides

Rails 2.2 Release Notes - A very solid set of release notes for 2.2 with basic coverage of the new features (with short code examples and links) as well as a list of deprecated features. They were compiled by Ruby / Rails Inside's very own Mike Gunderloy!

Upgrading RubyGems to 1.3.x - Depending on your setup, Rails 2.2 may demand that you upgrade to RubyGems 1.3.x. This is not as easy as it might usually be, however. Mike Gunderloy gives some tips in case you get stuck.

Rails Security Guide - Steer clear of security issues in your Rails 2.2 applications by reading the Ruby on Rails Security Guide. Who said Rails has poor documentation? This is incredible!

Rails 2.2 Screencast - Gregg Pollack and Jason Seifer of Rails Envy put together a very solid Rails 2.2 screencast. It costs $9, but it covers a lot of ground over 44 minutes - learn about etags, connection pooling, new enumerable methods, new test helpers, and more.

Rails 2.2 - What's New - In association with EnvyCasts, Carlos Brando and Carl Youngblood present Rails 2.2 - What's New, a 118 page PDF covering all of the changes and additions to Rails 2.2. It's available in a package deal with the screencast (above) too.

InfoQ's Glance - InfoQ's Mirko Stocker takes a quick glance at some of Rails 2.2's new features.

New Features

Thread Safety - Rails 2.2 is now "thread safe." In October, Pratik Naik wrote a summary of why this is a big deal as well as some gotchas (basically, don't use class variables, use mutexes, etc.) Charles Nutter has also written What Thread-safe Rails Means which answers several pertinent questions.

Internationalization - The Rails Internationalization effort has its own homepage at http://rails-i18n.org/ which features lots of links to how-tos, tips, documentation, and demos. They also have a Google group / mailing list where you can get help, make suggestions, etc.

Basic Language Internationalization - It's a little old, but Simple Localization in Rails 2.2 gives a very quick, code-driven example of how basic internationalization works in Rails 2.2 (some of the set up is easier now, but it mostly applies).

Localization / Internationalization Demo App - Clemens Kofler has put together a demo app that shows off some of Rails 2.2's internationalization and localization features. If being knee deep in code is the best way for you to learn, jump in!

Gem Dependencies - You can now specify any RubyGem dependencies your Rails app has in environment.rb. This makes it possible to install all of the dependencies for an app with one Rake task!

Layouts for ActionMailer - As of Rails 2.2, you can now use layouts in your ActionMailer views.

Connection Pooling - The connection pooling in Rails 2.2 allows Rails to distribute database requests across a pool of database connections. This can cause less lockups. In collaboration with a non-blocking MySQL driver, serious performance increases could result in certain situations.

Specify Join Table Conditions with Hashes - Do you need to run a find (or similar) query across a join? Now you can just specify the conditions for the joined tables in a hash, much like local tables conditions!

Limited Resource Routes - You can now limit map.resources to creating certain methods. For example, you might not want destroy or index methods - you can now specify these with :only and :except.

Memoization - Stop rolling your own memoization in Rails apps. Clemens Kofler demonstrates Rails 2.2's newly rolled-in memoization features. It's just a single method! If you have a view that calls on a calculated attribute often, this will give you some serious performance gains.

Custom Length Tokenizer for Validations - You can now specify a tokenizer of your own construction for validates_length_of validations.

Array#second through Array#tenth - If you're a bad programmer, you can now demonstrate it to the world by using the new Array#second, Array#third, Array#fourth, and so forth, methods. I've put it in my calendar to look for open source Rails apps using Array#seventh in six months time and to call them out on Rails Inside ;-)

Note: This list only takes into account some of the new features in Rails 2.2. There are a lot more! Read the release notes and the Rails 2.2 - What's New PDF to get the full picture.

Miscellaneous

restful-authentication-i18n - Want an authentication plugin for Rails 2.2 that supports internationalization? Take a look at result-authentication-i18n!

Barebones Apps - Check out Rails Inside's 7 Barebones Rails Apps to Kick Start Your Development Process.

Deploying on JBoss - You can now easily deploy a Rails app to a JBoss server. With Rails 2.2's significantly improved JRuby support, this makes rolling out Rails apps in the enterprise a breeze!

Installing Rails on Ubuntu Hardy Heron - Simon St Laurent has put together two Rails useful installation videos. One for servers, and one for the desktop.

REST for Rails 2 - Are you still in Rails 1.x land or not using REST at all? Would you like to? Geoffrey Grosenbach has put together a screencast showing you how it should be done. (Disclaimer: Peepcode is a sponsor of Ruby Inside.)

A Better Rails Logo - The Rails Logo (as used at the head of this post) was created by Kevin Milden and is distrubuted under the BY-ND Creative Commons Licence. This makes it a lot cooler than the "official" Rails logo which is trademarked and, well, you can't use without getting approval from the top.

Got more? Leave a comment below. On posts like this, the comments get a lot of clicking love from readers eager to learn more - so feel free to promote your own Rails 2.2 related stuff :-)

John's own examples are powerful demonstrations of how it works, so check them out. The first is parsing the XML returned from Twitter. The statues and associated users in that XML can be processed (with the relationship maintained) with the following code:

class User
  include HappyMapper

  element :id, Integer
  element :name, String
  element :screen_name, String
  element :location, String
  element :description, String
  element :profile_image_url, String
  element :url, String
  element :protected, Boolean
  element :followers_count, Integer
end

class Status
  include HappyMapper

  element :id, Integer
  element :text, String
  element :created_at, Time
  element :source, String
  element :truncated, Boolean
  element :in_reply_to_status_id, Integer
  element :in_reply_to_user_id, Integer
  element :favorited, Boolean
  has_one :user, User
end

statuses = Status.parse(xml_string)
statuses.each do |status|
  puts status.user.name, status.user.screen_name, status.text, status.source, ''
end

Added: Or.. how about a similar library that doesn't require naming the elements to work (but then lacks typecasting)? Check out xml-object by Jordi Bunster.

Cucumber is designed to allow you to execute feature documentation written in plain text (often known as "stories"). I've been experimenting with it as a replacement for integration tests in Rails. With Cucumber, you can write tests that look like this:

Scenario: See all vendors
    Given I am logged in as a user in the administrator role
    And There are 3 vendors
    When I go to the manage vendors page
    Then I should see the first 3 vendor names

With Cucumber, that it an executable specification that you can discuss with the customer and then use to verify the correct behavior of tests. Behind the scenes, you make it work by writing "steps," which are regex matchers that execute Ruby code. Here's one of the steps for that scenario:

Given /there are (\d+) vendors/i do |n|
  Vendor.transaction do
    Vendor.destroy_all
    n.to_i.times do |n|
      Factory.create(:vendor, :business_name => "Vendor #{n}")
    end
  end
end

Ideally, you'll do this all in true BDD fashion: write the Cucumber features first, watch them fail, implement code to make them pass (with lower-level tests written with RSpec or Test::Unit), and repeat.

Cucumber is under rapid development, but it's already a useful part of my testing toolbox. In addition to integrating with RSpec and Rails, it works with Merb, Sinatra, and the Webrat web-testing framework (as well as, of course, pure Ruby projects). It also has translations into 20 languages and the ability to run FIT-style tabular tests. If you're looking for a higher level of abstraction in your tests, it's definitely worth checking out.

Supported by: ActionGear is a menu-bar app for task management on your Mac. It's lightweight, quick, and helps you get stuff done. Try it out for free.

Not all of us could be at RubyConf08, however, so Gregg has taken the whole Ruby scalability topic and put together a solid 40 minute screencast called Scaling Ruby (note: it is NOT a recording of the talk - but a separate, professional production). It costs $9 (cheaper than RubyConf, of course) but it's a very solid primer on Ruby scaling issues. Almost every topic is illustrated through Gregg's unique diagrams, and he goes into depth on topics as diverse as event-based applications, threads, Rinda, process messaging, and even "dropping in to C" to write high performance sections of code.

I've been very impressed with the quality of the EnvyCasts I've seen so far, and this is no exception. Lots of practical knowledge delivered in a memorable way. $9 will still seem too rich to many - especially those who think all forms of documentation and instruction should be free (as in speech and beer) - but if it takes Gregg and Jason's fine commercial attempts to encourage others to produce higher quality, free documentation, I'm all for it! They also have screencasts covering Rails 2.2 (see the Rails Inside review) and ActiveRecord.

(Disclaimer: I've received free, promotional copies of the EnvyCasts for review. I have no other relationship - financial or otherwise - with the Rails Envy guys, other than being one of the first to promote them back in the day - doesn't time fly!)

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.

Straight from the horse's mouth:

Roxy is a basic proxy library that lets you quickly create proxies between your ruby objects. Its syntax is loosely based on Association Extensions in ActiveRecord as that is a well-known use of proxies.

Still not convinced to jump straight over to Ryan's blog post? Code example coming up in 3..2..1..:

class Person
  include Roxy::Moxie    

  attr_accessor :first, :last, :parents 

  proxy :parents do
    def divorced?
      proxy_target.size > 1 and proxy_target.collect { |parent| parent.last }.uniq.size > 1
    end
  end
end

# Can then invoke your proxy methods directly on parents
person.parents.divorced?

Supported by: ActionGear is a menu-bar app for task management on your Mac. It's lightweight, quick, and helps you get stuff done. Try it out for free.

If you're using git, the right answer is often the subtree merge strategy - but remembering the necessary commands can be a nuisance, especially if you rarely use them. There are several projects out there designed to make this easier for you: Tim Dysinger published some rake tasks to handle subtrees, and Braid is a more full-featured tool to manage both git- and svn-based vendor branches. 37signals have also released cached_externals which provides a somewhat different solution to the problem using symbolic links and separated checkouts.

After trying all of those approaches, though, I've settled on Pat Maddox's giternal tool for my own work. With giternal, you add a YAML file with details on your project's dependencies, similar to this:

delayed_job:
  repo: git://github.com/tobi/delayed_job.git
  path: vendor/plugins
paperclip:
  repo: git://github.com/thoughtbot/paperclip.git
  path: vendor/plugins

After that, there are just three commands to remember: giternal update to update all of your dependencies, giternal freeze to create a self-contained deploy tag with all externals at a known version, and giternal unfreeze to go back to live subtrees. If you've been shying away from dealing with externals in your git repositories, give it a shot.

Ruby Inside has been some surveys for the past couple of months, and they still show that only 25% of Ruby Inside's visitors have ever developed a Merb application. With the stability that the 1.0 release offers (older versions of Merb had a reputation - fair or not - for a constantly shifting API), it's now a great time to give Merb a try. It's also a great time to get into writing tutorials and documentation!

Quick Start

Install Merb from Rubyforge: gem install merb

If you'd rather go from Merb's "edge" repository: gem install merb --source http://edge.merbivore.com

NOTE: Make sure that you are running RubyGems 1.3.0 or higher (run gem -v to check). If not, you need to upgrade (I found this page very useful for doing that.

Then follow a tutorial such as Life On The Edge with Merb, DataMapper & RSpec, Slapp: A Simple Chat Wall Merb Tutorial or Move Over Rails. Here Comes Merb.

Once you're ready to roll, bookmark this page for safe keeping and read on for our Merb resources! We've divided them up into sections to make it easier. Some will also be left in the comments by other readers!

Merb News and Community Sites

Merb Tutorials and Documentation

Merb Books

Merb Sample Apps

Merb Events

Merb Miscellaneous

Got any more Merb resources? Please leave a comment!

Towelie

The first contender is Giles Bowkett's Towelie, which uses parsetree and ruby2ruby to look through a set of files searching for duplicates. Unfortunately, Towelie in its current state was unable to handle my test case (the Active Record subtree of Rails), persistently erroring somewhere in parsetree. Admittedly, ActiveRecord is an extremely large and often arcane code base - though yours may be also.

Giles has written an extensive blog post on Towelie, which includes a screenshot of a successful output. Clean and to the point. Give it a try and see if it works on your code base - there's a lot of potential here.

Flay

Next I looked at Flay, which just showed up (instantly at version 1.0.0) on RubyForge. From Ryan Davis, Flay uses sexp_processor and ruby_parser to examine the structure of Ruby code. It's capable of detecting both exact and close matches, and did in fact find some spots in Active Record where patterns repeat. In its current state, Flay's output is very primitive: a list of repeated code nodes, together with a weight to rank them by and line numbers and file names where they show up.

Just gem install flay, and then flay *.rb to get playing with Flay.

Simian - A more general approach

Turning away from pure Ruby tools, I grabbed a copy of Simian, a code similarity analyzer that's been around for quite a while. Written in Java, Simian can handle Ruby source code just fine - and indeed, it very quickly found a number of duplicate lines in the source I was looking at. For open source projects, Simian is free; others will pay $99 or more to license. This is definitely a more mature and faster tool than either Towelie or Flay; the drawback is that it has no knowledge of Ruby code structures, and so can't do the sort of logical looking for duplicate intent that the native tools promise.

Conclusion

The verdict? If I were coming into a new codebase with suspicious provenance, I'd run all three tools against it to get a sense of how bad the situation is. But I'd love to see the Ruby community push along the two native tools to a point where they have better output and can actually be used in a nightly build to watch for problems. We're not there yet, but could be reasonably soon - thoughts?

A few days ago, the Obama campaign ran another call for donations and offered the chance for ten donors to sit on the "Front Row to History" - basically the front row of an Obama event in Grant Park, Chicago. Rubyists Bruce Williams (of FiveRuns) and Damon Clinkscales (Austin on Rails) have made it into this group, and they've rapidly launched The Tweet Row to History (obamaftw.org) - a Twitter fuelled site with their up-to-the-minute adventures in Chicago.

Naturally, Bruce and Damon are flying the Obama banner pretty strongly, but this is a bipartisan site, so may whoever you voted for win!