Sunday, October 28, 2007

Better Capistrano Rewrite Rule for Maintenance Page

Capistrano comes with a nice little tasked called deploy:web:disable that puts up a maintenance page on your site. Assuming your webserver detects the presence of this page and rewrites any requests to display that page, this effectively disables your site. Very handy.

I found that the common configuration available on the Internet didn't work for me. Specifically, the Apache Rewrite rule needs to reference DOCUMENT_ROOT. Here are my rewrite rules; remember that for this to work, they have to be first:

RewriteCond %{DOCUMENT_ROOT}system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ %{DOCUMENT_ROOT}system/maintenance.html [L]

Thursday, October 25, 2007

acts_as_solr, Capistrano, and testing


I've recently deployed acts_as_solr and the Apache Solr server for full text searching in a new app I am building. The plugin works great, is easy to setup, but can cause some havoc with your deployment strategy if you don't pay attention.

For one thing, out of the box the plugin stores volatile information (tmp files, the indices used for searching, and log files) within the plugin itself, because it comes with its own version of Solr pre-installed. That makes it easy to get started and play with Solr but is not acceptable for a production environment (because every time you redeploy your code you'll be destroying and re-creating those directories within the plugin).

The Java Underworld

Unfortunately this means you'll have to descend from the mighty, glistening tower of Ruby into the Java underworld to setup a Tomcat servlet running Solr. This tutorial does a great job of explaining the process which is pretty easy.

Starting and Stopping Solr

I also have added some Capistrano tasks to start and stop the Solr server during deployments to lessen the chance that the index will be corrupted:
namespace :solr do

task :start, :roles => :app do
run "cd #{latest_release} && #{rake} solr:start RAILS_ENV=production 2>/dev/null"

task :stop, :roles => :app do
run "cd #{latest_release} && #{rake} solr:stop RAILS_ENV=production 2>/dev/null"

task :restart, :roles => :app do

For Capistrano to be able to run the above tasks, I also had to patch the start:solr rake task that comes with acts_as_solr to use backticks instead of exec:

`java{ENV['RAILS_ENV']} -Djetty.port=#{SOLR_PORT} -jar start.jar`


acts_as_solr will greatly slow down any tests that use fixtures (because the indices get updated every time the fixture data gets added or removed). Ideally you would mock the Solr server in unit and functional testing (unless you're directly testing your app's interaction with Solr), but I haven't found a way to mock Solr before your tests run, when fixtures are being added. One way to go might be to create something like mailtrap for Solr requests. The other thing that might help is installing a modification of Solr called background-solr which defers all the index save and destroy requests and performs them in batches -- the idea being that during testing, maybe you would just avoid calling that batch update method for most of your tests, except where you are testing interaction with Solr (as in an integration test).

Building the Index

This is really great rake task to help build the Solr index. It's much faster and more effective that doing it manually for each of your models.

Saturday, October 20, 2007

random_data v1.1 released

I received a patch from Hugh Sasse for random_data which adds separate male and female first names and adds more names. I've released these changes as v1.1.
sudo gem install random_data
or get it manually from the rubyforge site.

Thanks, Hugh!

Friday, October 12, 2007

Finding Improv Musicians (advice from Travis Ploeger)

One of BIG's troupes is looking to collaborate with a musician on a future project, so I asked the director of Washington Improv Theater's awesome iMusical for some advice. If you've never seen them perform you should definitely check it out -- they put together amazing shows. Travis kindly gave me permission to quote his excellent reply below:

I would first try to find any actors/improvisers that happen to play piano-
then find out if they also compose/write songs.

(My own background is as an actor/improviser. I went to a music
school, but to be a Broadway star, not a music director.)

If the pianist can successfully put themselves "in the shoes" of the actor
on stage, then it goes a long way. The ability to be a great pianist is
honestly not that important. Being able to quickly follow singers is a
skill that can be learned if someone is able to play competently- provided they
already have an ability to improvise music at the piano on their own. Most
songs usually have about 3 to 4 chords in them. The better the pianist,
the "dressier" those chord/progressions end up being.

If you can't find an improviser/actor that plays piano, the next place to
look would be an accompanist that has experience with accompanying live musical
theater, pref. somebody who also writes songs on their own and has a sense of
humor. They can borrow chord progressions from the catalog of past shows
they remember, if they can't come up with tunes and progressions on their

Interestingly, this advice matches what Neutrino told us when they trained us in their Neutrino Video Project techniques: it's better to teach improvisors how to film scenes than to teach camerapeople how to improvise.