require "bundler/capistrano"
set :bundle_dir,     ""         # install into "system" gems
set :bundle_flags,   "--quiet"  # no verbose output
set :bundle_without, []         # bundle all gems (even dev & test)

Maybe someone finds it helpful.

Silent error in Ruby 1.8.7:

x = [:a, :b]
=> [:a, :b]

x.slice!(:a)
=> nil

x
=> [:a, :b]

Explicit error (resulting in a failing test) in Ruby 1.9.2:

x = [:a, :b]
=> [:a, :b]

x.slice!(:a)
TypeError: can't convert Symbol into Integer

Just yet another incompatibility, but for the better!

jasmine-headless-webkit really helps with that. guard-jasmine-headless-webkit makes it all even more enjoyable, although there’s one caveat – it’s not so easy to set it all up.

There is a great guide for that, but it lacks some important details on running guard-jasmine-headless-webkit without graphical interface (X server).

Assuming you already have Xvfb installed, execute this command to run Xvfb in the background:

Xvfb :0 -screen 0 1024x768x24 > /dev/null 2>&1 &

And then you need to setup the DISPLAY shell variable in order for guard-jasmine-headless-webkit to automatically connect to our virtual frame buffer. Here’s the excerpt from my .bash_profile (it first checks if there is Xvfb running on display :0 and only then sets the DISPLAY variable):

xdpyinfo -display :0 &>/dev/null && export DISPLAY=:0

$ g pull
Already up-to-date.

$ g co edge
Switched to branch 'edge'
==  AddFileTypeToSong: migrating ==============================================
-- add_column(:songs, :file_type, :string)
   -> 0.0048s
==  AddFileTypeToSong: migrated (0.1380s) =====================================

$ g rebase master
Current branch edge is up to date.

$ g co master
Switched to branch 'master'
==  AddFileTypeToSong: reverting ==============================================
-- remove_column(:songs, :file_type)
   -> 0.1674s
==  AddFileTypeToSong: reverted (0.1679s) =========================

Oh, and it will bundle automatically for you as well, so don’t hesitate and hookup your Rails project!

$ git push heroku
(...)
-----> Gemfile detected, running Bundler version 1.0.7
(...)

$ bundle --version
Bundler version 1.0.10

It’s a whole three patch versions behind! Now I don’t really know (and maybe don’t even really want to know) what has changed between .7 and .10, but I can easily imagine things braking precisely because those minor inconsistencies in Bundler versions.

And sure, I could downgrade to .7, but to do that just because of Heroku? Thank you, but no. I want to ride the latest.

class Order
  def shipping_cost
    total_weight * 5 + 10
  end
end

require 'test/unit'
require 'rubygems'
require 'mocha'

class OrderTest < Test::Unit::TestCase
  # illustrates stubbing instance method
  def test_should_calculate_shipping_cost_based_on_total_weight
    order = Order.new
    order.stubs(:total_weight).returns(10)
    assert_equal 60, order.shipping_cost
  end
end

and this snippet (emphasis mine):

The more interesting discussion deals with whether to mock or stub your database-backed model. One upside is speed: This test case will not hit the database at all. Another is independence. I completely isolate the code under test to the controller layer.

convinced me that there just might be some treasure to be found beyond the Test::Unit. And I know that it's just the tip of the iceberg.

Exciting times. Definitely exciting. Nice Xmas gift.

Somewhere in your view:

<%= render :partial => 'ads/ad', :locals => {:placement => 'frontpage-banner1'} %>

It’s quite concise, but how about making it even less verbose? Helpers to the rescue:

module AdsHelper
  def ad(placement)
    render :partial => 'ads/ad', :locals => {:placement => placement}
  end
end

And now you can write this in your view:

<%= ad 'frontpage-banner1' %>

Nice! I believe it’s as short as it gets. Sure, if you render this partial only a few times it might not be worth it, but what if you render it 20 or 30 times?

<% if logged_in? then %>
<p><%= link_to 'Edit', document_edit_path(@document) %></p>
<% end %>

into this:

<%= content_tag 'p', link_to('Edit', document_edit_path(@document)) if logged_in? %>

I don’t know about you, but to say that I’m impressed would be not enough. Available from Rails 2.0 upwards.

** !!! PID file log/mongrel.pid already exists.  Mongrel could be running already.  Check your log/mongrel.log for errors.
** !!! Exiting with error.  You must stop mongrel and clear the .pid before I'll attempt a start.

It usually happens when the server crashes. After that you need to ssh into it, remove the mongrel pid files and start the cluster manually. No more.

I assume you have mongrel_cluster setup properly, ie: project’s config file is in /etc/mongrel_cluster and the mongrel_cluster script has been copied from:
/usr/lib/ruby/gems/1.8/gems/mongrel_cluster-*/resources/
to the /etc/init.d directory. You need to edit the /etc/init.d/mongrel_cluster file:

Change this two bits:

start)
  # Create pid directory
  mkdir -p $PID_DIR
  chown $USER:$USER $PID_DIR

  mongrel_cluster_ctl start -c $CONF_DIR
  RETVAL=$?
;;

and

restart)
  mongrel_cluster_ctl restart -c $CONF_DIR
  RETVAL=$?
;;

to

start)
  # Create pid directory
  mkdir -p $PID_DIR
  chown $USER:$USER $PID_DIR

  mongrel_cluster_ctl start --clean -c $CONF_DIR
  RETVAL=$?
;;

and

restart)
  mongrel_cluster_ctl restart --clean -c $CONF_DIR
  RETVAL=$?
;;

respectively.

Adding the --clean option makes the mongrel_cluster_ctl script first check whether mongrel_rails processes are running and if not, checks for existing pid files and deletes them before proceeding.

You must be using the mongrel_cluster version 1.0.5+ for it to work as advertised (previous versions were buggy). To upgrade do:

gem install mongrel_cluster
gem cleanup mongrel_cluster

Here’s the related mongrel_cluster changeset.