Everything to love about Ruby: the concise, powerful language; the sexy testing frameworks; and finally, the people.

If you’re one of our regular readers, well, thank you. But also, you may have been wondering where the heck we’ve been for the last 9 months.

I got passed the baton by Giles Bowkett. In my flattery, I've decided to return the favor by aping his style. He also pinged a bunch of people, and thus far only Paul Dix and I have responded.

How old were you when you started programming?

Selenium is a great way to test your app automatically through a browser. See how it works in this episode.

class="note"

Updated 2008-06-19 – better support Halcyon

JSON-P Rack Handler

Juicing Ruby

Rails based JSON-P

For the last 2 months I've been working on part of a project for a large publisher rolling out some new web services that use Rails based JSON to display comments on static web pages. This project has been a learning experience for nearly everyone involved on the Rails side and on the front end development side. We’ve overcome a number of limitations with the lack of a safe data transport in web browsers and limitations in the way Rails handles JSON-P and cross site REST. Some of the problems are unique to the solution we’re providing but they are no doubt a thorn in other developers’ sides. This is a follow up to a post I made about a month ago called JSON-P on Rails with JQuery. Below I’ve laid out some of the Rails problems and solutions related to JSON-P, cross domain JSON using JSON-P, JSON-P with jQuery and Rails caching JSON-P.

1. JSON-P with Rails
2. JSON-P with jQuery
3. Rails Caching JSON-P
4. Cross Domain RESTful JSON-P

JSON-P with Rails 

I was initially skeptical of Passenger aka mod_rails (because it seems to good to be true) but tonight I became a believer. We recently finished work on fairly high profile project. The installation seemed to be running fine but after installing monit regular tests revealed mongrel instances were hanging or unresponsive and randomly coming back online. After 3 days of the mysterious mongrel issues, apache tweaking of the proxy config, replacing mod_proxy_balancer with haproxy, and experimenting with other backends like thin and ebb I decided to give Passenger a shot. The gem was super easy and the apache install application was super easy and very helpful. After installing Passenger the new site is rocking. Goodbye mongrel.

I was on Slashdot and there was actually something I cared to comment about… then I got this.

Rails Hosting

I get a lot of questions about Rails hosting from this blog, so I’ll take a minute to post about some of my experiences.

Site5 Rails Hosting

JSON-P based Comment

Over the last several months I’ve had the pleasure of developer JSON based commenting solutions for publishers. I couldn’t be happier using JSON as a transfer method for moving ActiveRecord based object from the database almost directly to the consumer. I’ve run into some difficulties here and there mainly due to the Same Origin Policy which is a bastard of a browser rule that makes sending JSON across domains difficult. Even though prototype.js seems to support sending requests across domains there is no native script transport in prototype and worse yet it appear some browsers won’t allow AJAX across subdomains to overcome the SOP rules. I searched all over the web and found a few hacks for adding the script tag to prototype.js but I found the best solution was built native into JQuery’s getJSON. I was really taken with JQuery’s ability to handle the script transport method out of the box but I think even more I’m taken with JQuery’s syntax. I had a conversation with Less Everything’s Steven Bristol about 6 months ago and he asked if I had checked out JQuery. I had briefly looked at it but I wasn’t wowed by it (probably because I didn’t use it on a project). Steven: “isn’t it the best thing you’ve ever seen?” Me: It’s ok. (*my answer to everything – ask my wife). Six months later I get to use it on a project and my answer to you Steven is YES it is the greatest.

JSON-P

Back to the subject… So the problem is that a browser doesn’t want to send a request across domains for fear that your secret info will be compromised by some would be hacker. The solution JSON padded with a callback method combined with a plain old script tag aka JSON-P. With JQuery the idea is that you can pass a URL into JQuery’s getJSON method with a ? for JQuery to bind it’s on changing function name that handles a callback. Sound like a hack? Yes but everyone is doing it. I’ve seen some skeptics but overall this is an accepted solution. And until JSONRequest is accepted as a safe cross site transport JSON-P is here to stay.

Does Rails support JSON-P?

Bet your ass it does. Right out of the box Rails supports the callback option to be passed in on a :json render. Like so:

render :json => @comments, :callback => params[:callback]

JSON-P Problems on Rails

So the issue you’ll run into primarily with JQuery is the changing name of the callback. JQuery binds a random function name to the request (presumably to protect from attacks of some sort, maybe for anti caching). The issue is that with action caching caches the entire response body meaning the next call has a stale cache (because of the now changed callback name) or has to generate a new response for a new callback name. While JSON is typically very light weight the to_json method can be expensive and when you’re dealing with high traffic situations you always want to squeeze every bit of performance out that you can. We also do paginated result sets with will_paginate so it means there is a bit of post processing after a plain old find_all_by_blah… The solution I’ve been using is a mix of cache_fu for model level caching along with fragment caching the to_json results then interpolating the cached json into the callback. Sound like a hack? It is but it feels a bit better when you crunch out over 500/reqs/s as opposed to 14/reqs/s.

For the future

Let’s cross our fingers for CouchDB. I’ve been experimenting with Couch over the last week or two and I’m really pleased with the possibility of a RESTful document based database with native JSON and coming support for MapReduce. The future looks bright, I can imagine not so distant support for native ruby object level persistence. Yay!

Have you ever wanted needed to write a Ruby wrapper for an XML based API?

If you have a burning desire to seamlessly exchange data over the web or you just want to use the latest Interweb 2.0 service – you’re most likely contemplating writing your API client in Ruby… yes that’s why you’re here isn’t it?

Why Use Ruby to Parse XML?

Very often when projects go into production there are a few tweaks needed to make sure the app works correctly in its production environment and stays working. Below are some tips I’ve come up with from my experience rolling rails apps. Most of them are no brainers and some probably apply only to the Rails development we’re doing at work.

Rotate Rails Log Files

Log files get big really quick on high traffic sites. Some server apps rely on the operating system or a log rotating script to archive or delete old logs. Rails has a built in feature thanks to Ruby’s Logger class. The following code will keep 50 archived logs each 1mb in size and automatically rotate the log out once it hits 1mb.

Some friends recently reminded me that my blog has been down for almost 2 months. So I’ve managed to spend some time to bring the site back up in Typo 5. It kind of goes without saying that deploying rails apps on shared hosts sucks and I can stand behind that. But that’s OK – right tool for the right job.

In the last two months there’s been a lot written about Ruby. There’s been some bad press (zed and friends) and a lot of good press (Rails Machine, Rails 2, Ruby 1.9). Some crying fowl about Rails not being enterprise ready, the community sucking, it’s hard to deploy or whatever else. Who cares! Most of the complaints and accusations I’ve read are from people that need to point the finger in the mirror.

While my site was down a lot changed. Anyone keeping track of me (yeah lots of you I’m sure) knows my startup was a non-starter and I spent 2 long dreadful PHP filled months at a search marketing company and have since moved on to more reputable endeavors with a Connecticut firm building Rails based entertainment apps. I’m working with a team of experienced producers and engineers and I couldn’t be happier. So you can expect some new Ruby and Rails tidbits here again soon.

Some of you might have seen the O’Reilly article by former Rails trumpeter Derek Sivers entitled 7 reasons I switched back to PHP. Or the Slashdot article, even more ominously named Thinking about Rails? Think Again. In typical fashion, Slashdot ran the link with a suggestive name which I’m sure will effect the credibility of Rails in the eyes of the uninitiated masses of PHP developers trolling the website.

I happened to read the article earlier in the morning before it made it to Slashdot and didn’t think too much of the arguments behind the article. I can honestly say from my own experiences that mismanagement of a project, not limitations of a framework or language are usually to blame for missed deadlines, and project failures. I can say that from experience after developing the same project in both PHP and Rails with about 1/3 of the tables (and probably logic).

Anyone with a lick of common sense can tell you that if you’ve got a legacy application with 90 tables, migrating that data and accompanying application to an MVC framework is going to be a big project. With a 2 person team, 1 of which is the owner of the company (who should be focusing on more important things), the project is going to take a long time, cost a lot of money and the likelihood of failure is high.