A few days ago, Courtenay of Caboose posted an article called ‘pretty tables for ruby objects‘ that give a MySQL-command-line-client style textual view of data stored in your Rails database. The syntax worked like this:

puts Invoice.pretty_table(nil,{:max_width => 50, :line_spacer => ‘-’, :find => { :order => ‘created_at desc’ }})

For an output like so:

| created_at | updated_at | name | due_at | p |
—————————————————————————————————————
| Fri Jun 09 14:17:00 PDT 2006 | Fri Jun 09 18:34:55 PDT 2006 | Website | Sun Jul 09 14:17:00 PDT 2006 | 1 |
| Fri Jun 09 14:01:00 PDT 2006 | Fri Jun 09 18:34:55 PDT 2006 | May | Fri Jun 23 14:01:00 PDT 2006 | 1 |
| Sat Jun 03 12:25:00 PDT 2006 | Fri Jun 09 18:34:55 PDT 2006 | Invoice 3 | Mon Jul 03 12:25:00 PDT 2006 | 3 |

It didn’t make sense to me and I suggested developing a version that worked in this way instead:

Something.find(:all, :conditions => ‘whatever’).pretty_print

This way you can use your regular model accessors and simply use the ‘pretty’ output on any result set whatsoever. Read More

Coda Hale is a Rails developer from Berkeley, CA, who’s developed a ton of useful plugins. I’ll leave the descriptions to Coda:

content_cache

Cache rendered views within the context of your layout, allowing you to mix dynamic content with cached static content.

dollars_and_cents

Stores prices as integers in your database, but access them as floats.

dynamic_session_exp

Allows you to configure Rails to serve up session cookies with expiration dates relative to the current time, instead of some fixed date in the future.

http_caching

Allows your Rails application to take advantage of the caching mechanisms built into HTTP 1.1 (i.e., 304 Not Modified return code). Read More

One of the features of Rails 1.1 was the ability to automatically detect clients that could understand XML and send XML responses to them using the respond_to method. This also works for AJAX requests and HTML, of course. Unfortunately, though, this relies on XML and API clients sending the correct Accept headers in most cases, and, as we all know, users aren’t necessarily so smart (even API users!).

In response to this problem, Edge Rails now accepts the format parameter on the URL, like so: http://www.yourapp.com/post/show/1?format=xml So while the Accept header method still works, you can also pass in the format directly via the URL. Read More

I’m not a Windows user at all, but RForward struck me as perhaps being very interesting to those wanting to roll out Rails apps on Windows servers. It sounds like some of the new UNIX-side solutions to deploying Rails applications.. that is, proxying requests from one daemon to another rather than doing it all from one.

RForward is a reverse proxy designed to make Ruby on Rails applications easy to install into Microsoft’s IIS web-server.

The traditional way of installing Ruby on Rails applications into IIS is to use FastCGI. I have written a tutorial – as you can see it is quite long-winded and error-prone. Read More

maiha from #caboose ran some benchmarks and produced this graph of ‘requests per second’ for a basic app under different dispatcher setups (Apache, lighttpd, Mongrel, etc.):

It shouldn’t be taken as definitive (the Litespeed + lighttpd time seems suspicious to me), but it definitely demonstrates the power of lighttpd and Mongrel. Read More