And so I did just that, http://github.com/agoragames/brightcove

sudo gem install brightcove-api

>> require 'brightcove-api'
=> true
>> brightcove = Brightcove::API.new('0Z2dtxTdJAxtbZ-d0U7Bhio2V1Rhr5Iafl5FFtDPY8E.')
=> #<brightcove ::API:0x114dbc8 @token="0Z2dtxTdJAxtbZ-d0U7Bhio2V1Rhr5Iafl5FFtDPY8E.", @api_url="http://api.brightcove.com/services/library">
>> response = brightcove.get('find_all_videos', {:page_size => 3, :video_fields => 'id,name,linkURL,linkText'})
=> {"items"=>[{"name"=>"Documentarian Skydiving", "id"=>496518762, "linkText"=>nil, "linkURL"=>nil}, {"name"=>"Surface Tricks", "id"=>496518763, "linkText"=>nil, "linkURL"=>nil}, {"name"=>"Free Skiing", "id"=>496518765, "linkText"=>nil, "linkURL"=>nil}], "page_number"=>0, "page_size"=>3, "total_count"=>-1}

The application, and cluster deployment in general, is hamstrung by Erlang’s standard approach to cookies. The cookie, typically .erlang.cookie in the HOME directory of an application, must have only user read permissions. For a Linux RabbitMQ install, that would look like this:

bofh@rabbit_host1:~$ ls -al /var/lib/rabbitmq/
total 333
drwxr-xr-x  3 rabbitmq rabbitmq    160 2010-07-12 17:49 .
drwxr-xr-x 37 root     root       1008 2010-07-02 14:29 ..
-r--------  1 rabbitmq rabbitmq     20 2010-05-04 20:44 .erlang.cookie
drwxr-xr-x  3 rabbitmq rabbitmq     72 2010-05-04 20:49 mnesia
-rw-r--r--  1 rabbitmq rabbitmq     27 2010-07-12 17:49 pids

Any variation on these permissions and Erlang will refuse to start. The permissions requirement is embedded into Erlang itself, making it more or less impossible to work around. This creates the following problems:

• You must copy this file (or its contents) to all hosts in the cluster
• All users of rabbitmqctl must run it as sudo
• All monitoring tools must also run as root or have sudo capability
• You must have the cookie file present on the host running rabbitmqctl

Given how powerful rabbitmqctl is, you will likely still want to limit access to it, but this can be readily accomplished with standard Unix permissions. By expanding who can use it and where, your system administrator will be thrilled to reduce need for sudo access and your customers will be happy with the additional tools you can deploy to monitor your cluster and its clients to ensure that all is well, 24/7.

Thankfully, RabbitMQ’s scripts accept a lot of environment variables which can be passed into the Erlang runtime, and Erlang kindly provides a way to bypass the cookie file through a command line literal. The scripts are all located in the scripts directory inside your RabbitMQ installation.

bofh@rabbit_host:~$ ls -ald `erl -eval 'io:format("~s~n", [code:lib_dir()])' -s init stop -noshell`/rabbitmq-server*/scripts
drwxr-xr-x 2 root root 520 2010-07-21 14:47 /usr/local/lib/erlang/lib/rabbitmq-server-1.7.0/scripts
drwxr-xr-x 2 root root 520 2010-07-21 16:15 /usr/local/lib/erlang/lib/rabbitmq-server-1.7.2/scripts

The three standard scripts, rabbitmq-server, rabbitmq-multi and rabbitmqctl all source an environment script, rabbitmq-env, which in turn will source the file /etc/rabbitmq/rabbitmq.conf if it exists. This is the file that you can edit to take control of your RabbitMQ cluster.

SERVER_START_ARGS="+K true +A300 +P512000 -setcookie NOMNOMNOMYUMYUM -kernel inet_default_listen_options [{nodelay,true},{sndbuf,32768},{recbuf,32768}]"
MULTI_START_ARGS="-setcookie NOMNOMNOMYUMYUM"
CTL_ERL_ARGS="-setcookie NOMNOMNOMYUMYUM"

The value of each environment variable will be passed verbatim to the Erlang runtime. The SERVER_START_ARGS are passed to each node started by rabbitmq-multi, and directly affect the performance of a RabbitMQ instance. In this example, we have increased the number of native threads available to Erlang and allowed it to spin up numerous (Erlang) processes. We have also instructed the kernel to increase its TCP buffer sizes and disable Nagle's algorithm.

You can now run rabbitmqctl without sudo on any host which has this same configuration deployed. This solution still requires that you synchronize /etc/rabbitmq across your cluster, though there are many ways of solving that problem.

We have taken this a step further and enabled rabbitmqctl on any host in our network. All of our core software is deployed from source to /usr/local over NFS. We have deployed the rabbitmq.conf file there too, and have a small shell script wrapping rabbitmqctl.

#!/bin/bash
ERL_PATH=`erl -eval 'io:format("~s~n", [code:lib_dir()])' -s init stop -noshell`
LATEST_VERSION=`ls $ERL_PATH | grep rabbitmq | sort | tail -1`
RABBIT_PATH="$ERL_PATH/$LATEST_VERSION"

set -f
[ -f /usr/local/etc/rabbitmq/rabbitmq.conf ] && . /usr/local/etc/rabbitmq/rabbitmq.conf
export CTL_ERL_ARGS
HOME=/var/lib/rabbitmq $RABBIT_PATH/scripts/rabbitmqctl $@

We can now connect to and monitor any RabbitMQ node from any host on our network

bofh@gateway:~$ rabbitmqctl -n rabbit@rabbit_host1 status
Status of node rabbit@rabbit_host1 ...
[{running_applications,[{rabbit,"RabbitMQ","1.7.2"},
                                {mnesia,"MNESIA  CXC 138 12","4.4.10"},
                                {os_mon,"CPO  CXC 138 46","2.2.2"},
                                {sasl,"SASL  CXC 138 11","2.1.6"},
                                {stdlib,"ERTS  CXC 138 10","1.16.2"},
                                {kernel,"ERTS  CXC 138 10","2.13.2"}]},
 {nodes,[rabbit@rabbit_host1,rabbit@rabbit_host2]},
 {running_nodes,[rabbit@rabbit_host1,rabbit@rabbit_host2]}]
...done.

Gemfile

gem ‘rails’, ‘3.0.0.rc’
gem ‘haml’, ‘3.0.14′

Obviously you have to tell your application to use the 3.0.0.rc. Also, it seems as if haml 3.0.13, which we were previously using, had some incompatible changes with Rails 3.0.0.rc

Rakefile

Change:

Rails::Application.load_tasks

to:

YourApplicationName::Application.load_tasks

config/environments/test.rb

Add:

config.active_support.deprecation = :stderr

config/routes.rb

Change:

YourApplicationName::Application.routes.draw do |map|

to:

YourApplicationName::Application.routes.draw do

Rails 3 routing in great detail: The Lowdown on Routes in Rails 3.

Before we jump into setup, first a bit about our pre-Rails3 environment:

• Mac OS X 10.5.8
• ruby 1.8.6 (2009-06-08 patchlevel 369) [universal-darwin9.0] (stock)
• RubyGems 1.3.7
• Various older versions of Rails (2.3.8, 2.3.5, 2.3.4, 2.3.2, 2.2.2, 2.1.1, 2.1.0, 2.0.2, 1.2.6, 1.2.3)

We will be installing the latest release of Rails which, as of this writing, is Rails 3 beta4.
We will also complete setup using the latest version of Ruby 1.9.
The minimal version of Ruby 1.9 required for this Rails release is 1.9.2.
To complete setup with Ruby 1.8.7, consult the Rails 3 release notes for the minimal version requirements.

The basic installation steps are as follows:

1. Install RVM (Ruby Version Manger)
2. Install Ruby 1.9.2
3. Install Rails3 beta4
4. Profit!

To install, issue the following commands in a terminal window:

1. bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )
   • This is the preferred RVM installation method as described in the RVM installation instructions.
2. rvm install 1.9.2-head
3. rvm 1.9.2-head
4. gem install rails --pre

Installation of the rails gem should also install it’s respective dependencies:

    [05:16:50][tquackenbush@TQuackenbush ~]$ gem list

    *** LOCAL GEMS ***
never
    abstract (1.0.0)
    actionmailer (3.0.0.beta4)
    actionpack (3.0.0.beta4)
    activemodel (3.0.0.beta4)
    activerecord (3.0.0.beta4)
    activeresource (3.0.0.beta4)
    activesupport (3.0.0.beta4)
    arel (0.4.0)
    builder (2.1.2)
    bundler (0.9.26)
    erubis (2.6.5)
    i18n (0.4.1)
    mail (2.2.5)
    mime-types (1.16)
    polyglot (0.3.1)
    rack (1.1.0)
    rack-mount (0.6.4)
    rack-test (0.5.4)
    rails (3.0.0.beta4)
    railties (3.0.0.beta4)
    rake (0.8.7)
    rdoc (2.5.8)
    thor (0.13.6)
    treetop (1.4.8)
    tzinfo (0.3.22)

To test out your new installation, try creating a new bare bones Rails 3 application like so:

1. rails new test_app
2. cd test_app
3. bundle install
   • Bundler is the new default dependency manager in Rails 3, and will install any missing gems required by the project.
   • In my case, this was ’sqlite3-ruby (1.3.0)’
4. rails server

As in Rails 2, this should launch a WEBrick server instance listening on localhost port 3000 with output similar to:

    => Booting WEBrick
    => Rails 3.0.0.beta4 application starting in development on http://0.0.0.0:3000
    => Call with -d to detach
    => Ctrl-C to shutdown server
    [2010-06-23 16:54:06] INFO  WEBrick 1.3.1
    [2010-06-23 16:54:06] INFO  ruby 1.9.2 (2010-06-22) [i386-darwin9.8.0]
    [2010-06-23 16:54:06] INFO  WEBrick::HTTPServer#start: pid=6529 port=3000

And that’s it! You’re all ready to go with Rails 3!

Update: June 25th, 2010 (David Czarnecki)

I ran into an issue on one system where rvm and Ruby 1.9.2 were correctly installed on the system, but Rails 3 would not install. The installation would go as follows.

machine-name:~ dczarnecki$ gem install rails --pre
WARNING:  RubyGems 1.2+ index not found for:

RubyGems will revert to legacy indexes degrading performance.

I blew away the ~/.gemrc file and Rails 3 installed successfully. YMMV.

Update: June 29th, 2010 (Joshua Childs)
Ran into two issues with with dependencies while getting setup on my Ubuntu workstation.

First was while problem I ran into was while following the installation steps.

# Command:
josh@jagar-tharn:~$ rvm install 1.9.2-head

# Response:
fail: bison is not available in your path. Please ensure it exists before compiling from head.

# Solution:
sudo apt-get install bison

And the second problem I ran into was while using bundle to setup my dependencies. My workstation did not have sqlite3 installed.

# Command:
josh@jagar-tharn:~/projects/test_app$ bundle install

# Response:
...
Using rails (3.0.0.beta4) from bundler gems
Installing sqlite3-ruby (1.3.0) from rubygems repository at http://rubygems.org/ with native extensions /home/josh/.rvm/rubies/ruby-1.9.2-head/lib/ruby/1.9.1/rubygems/ext/builder.rb:46: warning: Insecure world writable dir /usr/local/libevent/ in PATH, mode 040777
/home/josh/.rvm/rubies/ruby-1.9.2-head/lib/ruby/1.9.1/rubygems/installer.rb:483:in `rescue in block in build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)

/home/josh/.rvm/rubies/ruby-1.9.2-head/bin/ruby extconf.rb
checking for sqlite3.h... no
sqlite3.h is missing. Try 'port install sqlite3 +universal' or 'yum install sqlite3-devel'
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
	--with-opt-dir
	--without-opt-dir
	--with-opt-include
	--without-opt-include=${opt-dir}/include
	--with-opt-lib
	--without-opt-lib=${opt-dir}/lib
	--with-make-prog
	--without-make-prog
	--srcdir=.
	--curdir
	--ruby=/home/josh/.rvm/rubies/ruby-1.9.2-head/bin/ruby
	--with-sqlite3-dir
	--without-sqlite3-dir
	--with-sqlite3-include
	--without-sqlite3-include=${sqlite3-dir}/include
	--with-sqlite3-lib
	--without-sqlite3-lib=${sqlite3-dir}/lib
...

# Solution:
josh@jagar-tharn:~/projects/test_app$ sudo apt-get install sqlite3
josh@jagar-tharn:~/projects/test_app$ sudo apt-get install libsqlite3-dev

First, install some gems.

#On all systems
sudo gem install ZenTest
sudo gem install redgreen
sudo gem install autotest-rails
sudo gem install shoulda
sudo gem install factory_girl

# Only on my OSX machine
sudo gem install autotest-growl
sudo gem install autotest-fsevent

# Only on my Ubuntu machine
sudo gem install test_notifier
sudo apt-get install libnotify-bin

Next, I setup my ~/.autotest file:

#!/bin/ruby
require 'redgreen/autotest'
require 'autotest/timestamp'
require "autotest/restart"

#Only Ubuntu
require "test_notifier/autotest"

#Only OSX
require "autotest/growl"
require 'autotest/fsevent'

# All machines
Autotest.add_hook :initialize do |autotest|
  %w{.git .svn .hg .DS_Store ._* vendor tmp log doc}.each do |exception|
    autotest.add_exception(exception)
  end
end

Also, I really like git instaweb. I sent it to G, our brilliant (ex)intern and he likes it too. To start it I use:

git instaweb -d webrick --start

You can automate this by adding the following to your ~/.gitconfig:

[instaweb]
httpd=webrick

You can also add a port option (port=8000) if you want.

Also, to stop instaweb, from the git repo that you started instaweb from run:

git instaweb stop

Finally, I tend to branch a lot and store them server-side. I like tracking branches to automatically push/pull changes to a branch from a remote repository. All this really does is add a few lines to your .gitconfig, but hey, who doesn’t like a shortcut.

  git branch --track branch remote

Last but not least, the Cheat gem is awesome. It’s like man, but distilled to the things you’ll actually use. (It’s actually where I read about instaweb) Use it!

sudo gem install cheat

So in general, that’s the interesting bits of my environment. How about yours?

Holy crap is this visually confusing; even Firebug returns nothing! That said, it’s a perfect example of why performing only in-browser testing fails miserably. Functional tests.. use em!

#/usr/bin/ruby
require 'openssl'
require "base64"
require 'uri'

# First lets encrypt the string!
plaintext = 'Super secret message'

# Create the cipher
cipher = OpenSSL::Cipher::Cipher.new("aes-256-cbc")
cipher.encrypt # Tell OpenSSL to operate in encrypt mode
puts "Cipher wants a key that is #{cipher.key_len}"
key = '01234567890123456789012345678901'
cipher.key = key

puts "Cipher wants an initialization vector that is #{cipher.iv_len}"
cipher.iv = iv = cipher.random_iv # Create and set a random initialization vector

# Encrypted
encrypted = cipher.update(plaintext) + cipher.final
encrypted = iv + encrypted # Send along the IV

# Lets pretty up the encrypted string
encrypted = Base64.encode64(encrypted)
#encrypted = URI.escape(encrypted, Regexp.new("[^#{URI::PATTERN::UNRESERVED}]"))
encrypted = URI.escape(encrypted)

# Now lets unencrypt it, first start with a new cipher
cipher = OpenSSL::Cipher::Cipher.new("aes-256-cbc")
cipher.decrypt # Use SSL in decrypt mode
cipher.key = key
encrypted = URI.unescape(encrypted)
encrypted = Base64.decode64(encrypted)
cipher.iv = encrypted.slice!(0,16) # Remove the IV from the encrypted data
decrypted = cipher.update(encrypted) + cipher.final 

# Test
puts 'The original was '+ plaintext
puts 'Encrypted that was ' + encrypted
puts 'Decrypted we have ' + decrypted

There are a few rake tasks that I’ve been using more and more now that all of our applications are running in a shared, virtual enviroment. They are:

* rake -T     # -T, –tasks [PATTERN]            Display the tasks (matching optional PATTERN) with descriptions, then exit.

Everyone should know and use this task at least once in their Rails-development life.

* rake rails:freeze:gems   # Lock this application to the current gems (by unpacking them into vendor/rails)
* rake gems:unpack   # Unpacks all required gems into vendor/gems.
* rake gems:unpack:dependencies   # Unpacks all required gems and their dependencies into vendor/gems.

So, once I’ve created my project with “rails [project name]“, then next thing I do is “rake rails:freeze:gems” to freeze the Rails gems. I’ll enumerate the application’s dependencies in the environment.rb file and then run “rake gems:unpack” to make sure those dependencies exist with the application. Example:

config.gem 'will_paginate', :version => '2.3.11', :source => 'http://gemcutter.org'
config.gem 'factory_girl', :version => '1.2.4', :source => 'http://gemcutter.org'
config.gem 'fakeweb', :version => '1.2.8', :source => 'http://gemcutter.org'

Why do I like this approach? In a shared environment, it means we don’t have to have our systems folks install any dependencies for our application to run making the application self-contained. This is mostly fine for gems that don’t have an explicit native component. Also, in being explicit about versions of the gems that an application is using, we do not run the risk of chasing a moving target. Again, in a shared environment, if someone updates a gem on the system, it’s probably not an issue until the one time it is and you’re being called at 3 AM that the application is down because of a gem incompatibility change.

That’s it. Any other packaging dos and don’t?

I just inherited an application and was adding some tests and noticed that one of the tests was randomly failing. As I dug in more, this particular controller test, in executing the controller’s index method, was actually calling out on the intertubes to request some data. For an integration test that’s probably OK, but my view is that unit and functional tests should be self-contained.

Enter Fakeweb.

“FakeWeb is a helper for faking web requests in Ruby. It works at a global level, without modifying code or writing extensive stubs.”

3 lines of code later and I have a self-contained functional test that works with real data.

def setup
FakeWeb.allow_net_connect = false
end

def teardown
FakeWeb.allow_net_connect = true
end

test "should get index" do
FakeWeb.register_uri(:get, 'http://my.real.url.on.the.internets.com', :body => File.join(File.dirname(__FILE__), '../fakeweb', 'some-file.xml'), :content_type => "text/xml")

get :index
assert_response :success

...

All I needed to do was simply register the URI that was being referenced in my test, provide a valid (or invalid depending on the test) response, and my test will never try to access the real internet.