Elsewhere

HTTP Request => Rails 'params'

GET: /users => [:action => 'index']
GET: /users.xml => [:action => 'index', :format => 'xml']
GET: /users/1 => [:action => 'show', :id => 1]
GET: /users/1;edit => [:action => 'edit', :id => 1]
GET: /users/1.xml => [:action => 'show', :id => 1, :format => 'xml']
POST: /users => [:action => 'create']
PUT: /users/1 => [:action => 'update', :id => 1]
DELETE: /users/1 => [:action => 'destroy', :id => 1]

Prolific 'Edge Rails' blogger Ryan Daigle has written "Simply RESTful Support - And How to Use It", a great walkthrough of the features offered by the simply_restful plugin that's now a core part of Edge Rails and which will provide a lot of the new functionality to be seen in Rails 1.2.

Expat is the recognized big daddy of XML parsing. It's a stream-based XML parser written in C and, as a library, is used for XML parsing functions by many languages. Rubyists have tended towards REXML, however, a more flexible (though infinitely slower) parser. Sam Ruby, however, has come up with some techniques to get Ruby's REXML working with Expat.

I've joined forces with Obie Fernandez on the Ruby section at InfoQ, a prime news site for the enterprise software development community. The Ruby news at InfoQ has more of an enterprise feel to it than that here at RubyInside and is focused at team leaders, development managers, enterprise developers, etc, so there's less hacking, but more high-level Ruby stuff.

After writing a basic routine to print all prime numbers between 1 and 10,000 in Ruby, Pat Eyler found it took almost 3 seconds to complete, and seeked out a way to make it faster. Enter RubyInline (covered previous at RubyInside).. With RubyInline he added a basic C function into the Ruby mix and knocked down the time required to 0.3 seconds.

It's time to bring in a regular feature.. Troll Of The Month. Every month or so there appears to be a new article circulating that explains why 'Ruby sucks' or why you shouldn't use Rails to develop serious applications. Most of the time, they're unbalanced and poor explained, even if the author has some valid points.

Tomasz Węgrzanowski (aka Taw) has developed a Lisp interpreter embedded in Ruby called RLisp. It's early days and ultra-alpha-quality, but it's a cool project. You can find the source code here, and Taw is offering free beer for the first 10 developers to write a cool RLisp program. RLisp already has some basic OO support (and even HTTP support) so it's fun to play with.

_why announces a release of a new UTF-8 library (which adds UTF-8 support to Ruby, without using KCODE) by Nikolai Weibull. _why has also packaged it up (unofficially) into a gem to make it even easier to install (not all of us use git). Here's some demonstration code:

Scott Laird has announced the release of Typo 4.0, the first release of the original Rails powered blogging tool this year:

Scott Raymond has written a useful article showing the thinking behind his refactoring of IconBuffet.com from an action-heavy URL scheme to a REST based URL scheme.
The application behind IconBuffet.com, a royalty-free stock icon store, went from 10 controllers and 76 actions to 13 controllers that more closely followed the models involved, and 58 total actions. Most of the new actions are uniform and match to the new Rails methodology of mapping HTTP verbs (GET, PUT, POST, DELETE, etc.) to Rails controller actions. You can learn more about this structure from David Heinemeier Hansson's slides (PDF) from RailsConf, or watch the video of his keynote presentation.

This one is for Mac users only..

Bruce Williams tries to solve the problem of multiple parameter types in Rails. For example, an action may accept dates via a parameter, but dates may be supplied in many forms. A 'date' parameter might arrived as if from a date_select helper, or might even be typed in directly by a user, or be pulled from a database. Rather than use before_filters to check parameters and normalize them, Bruce suggests that it should be possible to add basic conversion tools to certain data types so that all data is normalized by the time it hits your controllers.

In the recent 19 Rails Tricks Most Rails Coders Don't Know article, I recommended the use and development of engines to implement common functionality in Rails applications. I simply provided a link to the Rails Engines site and left it at that.

Active Merchant is a payment processing library for Rails developed by the geniuses behind Rails powered e-commerce system, Shopify. It's under active development with support for different payment processor gateways being added regularly. So far it supports:

There are many scenarios where you might want the same controller action / method in your Rails application to perform multiple functions. For example, a wizard with multiple steps or a single form with multiple-stage AJAX calls. What you want to do is provide a 'context' to the specific request and have the controller handle that in some different way.

The indefatigable Assaf Arkin has done it again by developing a new Ruby HTML scraping toolkit, scrAPI. Peter Szinek recently wrote a popular article about scraping from Ruby using Manic Miner, RubyfulSoup, REXML, and WWW::Mechanize, but none of these are as immediately useful as scrAPI.. so why?

This library is so amazingly cool that it requires no descriptions beyond these code examples:

Geoffrey Grosenbach introduces the RaPT Plugin Manager for Rails, the answer to the problem of slow plugin installation. Installable as a gem (gem install rapt), RaPT caches the locations of different plugins so that installation is quick and easy. Future plans include developing a central plugin repository, auto-announcement of self-developed plugins, and automatic plugin upgrading. If you want the files direct, check out the Rubyforge project site for RaPT.

You can test your controllers, your models, and, well, most of your application, but till now there hasn't been a way to explicitly test your Rails application's helpers. Now there's a solution.. the helper_test plugin (with source and instructions).

MeantimeFilter is an interesting new plugin for Rails by Roman Le Negrate. It's a little like around_filter, but rather than using a class with 'before' and 'after' methods, it uses a single method (like the other types of filter) and passes in the method to wrap 'around' as a code block. You can then yield to this or pass it into anything you like. An example:

Paul Battley has developed a Ruby to JavaScript converter. I'm trying to think what this is useful for, but this is an amazing results for just a few hours' work.