Integrating with other services is on the roadmap of almost any SaaS application. There’s only so much your application can do itself. Sometimes it’s best to leave tasks up to others who specialize on them.
Like any other build process, deploying Rails applications should be a quick and easy task. You should be able to deploy everything to your server with just one command. There are several tools available for this task. One of them is Capistrano, which is probably the oldest and by far the most popular deployment tool in the Rails community. Unfortunately the documentation is still not great and a lot of very handy features are unknown to many. Only digging through the API documentation and the source code reveals them.
Sometimes, when testing your code with RSpec, you’ll notice similarities and duplication between your spec files. Most of these will involve setup that doesn’t say much about the object under test. There’s something that helps you to reduce this duplication: Custom example groups! RSpec itself (rspec-rails) uses example groups for the different types of tests for models, controllers, helpers and views. In the following I’ll show you how to use them to reduce duplication and improve your tests.
During the last couple weeks I’ve been playing around with the iPad and Mobile Safari. I built a little tool to familiarize myself with the Multitouch JavaScript API provided by Mobile Safari as well as web applications for the iPad in general. I named the result Multitouch Inspector because that’s what it does: Inspect the TouchEvents fired by the JavaScript API. ;-) Today I decided to rewrite the tool to drop the dependency on Prototype.js and I published it on GitHub.
When testing helper methods that use Rails’ output buffer (for example
by calling concat) with RSpec, be sure to add this to your specs:
before (:each) do
helper.output_buffer = ""
end
Took me a while to figure this one out. Apparently RSpec doesn’t
initialize the output buffer and you end up with a NoMethodError on nil.