Darian Shimy » rails

SQL Logging to script/console

Darian Shimy — Sun, 11 Oct 2009 04:37:06 +0000

When running a Rails console session, a true time saver is directing the ActiveRecord logs to STDOUT instead of the log file. This is easily accomplished adding the following to your ~/.irbrc file:

if rails_env = ENV['RAILS_ENV']
  # Called after the irb session is initialized and Rails has
  # been loaded (props: Mike Clark).
  IRB.conf[:IRB_RC] = Proc.new do
    ActiveRecord::Base.logger = Logger.new(STDOUT)
    ActiveRecord::Base.instance_eval { alias :[] :find }
  end
end

If someone knows the original author of these lines, let me know and I’ll give them proper attribution.

Error Handling with XML and Authlogic

Darian Shimy — Sat, 10 Oct 2009 07:12:23 +0000

I was helping a friend integrate an API into the application. He is running Rails 2.3.4 with Authlogic. His authentication check method was the following:

def require_user
  unless current_user
    session[:return_to] = request.request_uri
    flash[:notice] = "You must be logged in to access this page"
    redirect_to new_user_session_url
    return false
  end
end

Although this worked great for the HTML requests, the XML requests were getting HTML response with a redirect to the login page. Not what we were looking for. Instead, the require_user method needed to be aware of the mime-type and return an appropriate response.

Here is the block that responds to the mime-type. Instead of getting an HTML response to an XML request, an XML error reponse with the correct HTTP status code is returned.

def require_user
  unless current_user
    respond_to do |format|
      format.html {
        session[:return_to] = request.request_uri
        flash[:notice] = "You must be logged in to access this page"
        redirect_to new_user_session_url
      }
      format.xml {
        user = User.new
        user.errors.add_to_base("Authentication is required.")
        render :xml => user.errors, :status => 401
      }
      end
    return false
  end
end

Capistrano – Deploying a Branch

Darian Shimy — Thu, 08 Oct 2009 14:00:00 +0000

When deploying from Capistrano, I like to have the following in my ‘deploy.rb’ file:

set :scm, "git"
set :repository, "git@www.example.com:project.git"
set :git_shallow_clone, 1
set :deploy_via, :remote_cache

This allows speeds deployments by keeping a versions checked out on the server in ‘shared/cached-copy’. When it comes to deploying, it is always best to deploy from a branch instead of the master/head/trunk. To handle this, add the following:

set :branch, fetch(:branch, “master”)

When you deploy, run the following:

$ cap deploy -S branch=REL_1.0

If you don’t specify the branch, the master is used.

Capistrano – Email on Deployment

Darian Shimy — Wed, 07 Oct 2009 14:00:12 +0000

It’s a good practice to send a notification to certain people when a new version is deployed. This process can easily be automated in Capistrano. Add the following file to the ‘lib’ directory with the filename ‘cap_mailer.rb’:

require 'rubygems'
require 'actionmailer'
 
ActionMailer::Base.smtp_settings = {:address => "localhost", :port => 25, :domain => 'example.com'}
 
class CapMailer < ActionMailer::Base
  def deploy_notification(options)    
    message = "Deployment\n\n"
    options.each_pair do |k,v|
      message << "  #{k}: #{v}\n"
    end
 
    recipients "notify-deployment@example.com"
    from       'noreply@example.com'
    subject    "Deployment to #{options[:rails_env]}"
    body       message
  end
end
 
module CapistranoMailer
  def send(options)
    CapMailer.deliver_deploy_notification(options) 
  end
end
 
Capistrano.plugin :mailer, CapistranoMailer

In the ‘deploy.rb’ file, add the following:

require 'lib/cap_mailer'
require 'etc'
 
namespace :deploy do
  desc "Sends an email upon successful deployment"
  task :notify do
    mailer.send(
      :rails_env => rails_env,
      :deploy_to => deploy_to,
      :branch => branch,
      :application => application,
      :repository => repository,
      :deployment_time => Time.new.to_s,
      :deployer_username => Etc.getlogin)
  end
end
 
after "deploy", "deploy:notify"
after "deploy:migrations", "deploy:notify"

Capistrano – Install Gems Remotely

Darian Shimy — Tue, 06 Oct 2009 14:00:49 +0000

Capistrano does not have out-of-the-box support for installing gems on your servers. You may not need this if you are packing them, but some of us would like to run the equivalent of ‘rake gems:install’. To do this in capistrano, add the following to your deploy.rb file:

namespace :gems do
  desc "Install gems"
  task :install, :roles => :app do
    run "cd #{current_release} && #{sudo} rake RAILS_ENV=#{rails_env} gems:install"
  end
end

Capistrano – Adding Help to Deployments

Darian Shimy — Mon, 05 Oct 2009 14:00:05 +0000

If you don’t do something everyday, you tend to forget how to do it. The same is with the deployments. To help this, you can easily add a help section to Capistrano in your ‘config/deploy.rb’ file. Here is a sample:

desc "Print usage/help information"
task :help do
    puts "Usage: cap  -S stage=[staging|production] -S branch="
    puts ""
    puts "Examples:"
    puts "----------------------------------------------------------------------"
    puts "  Production:"
    puts "    $ cap deploy:migrations -S stage=production"
    puts ""
    puts "  Staging:"
    puts "    $ cap deploy:migrations"
    puts ""
    puts "  Production with branch:"
    puts "    $ cap deploy:migrations -S stage=production -S branch=rel_001"
    puts ""
    puts "  Staging with branch:"
    puts "    $ cap deploy:migrations -S branch=rel_001"
end

When you forget how to do something, just run the following:

$ cap help
 
Usage: cap <task> -S stage=[staging|production] -S branch=<branch_name>
  * executing `help'
Examples:
----------------------------------------------------------------------
  Production:
    $ cap deploy:migrations -S stage=production
 
  Staging:
    $ cap deploy:migrations
 
  Production with branch:
    $ cap deploy:migrations -S stage=production -S branch=rel_001
 
  Staging with branch:
    $ cap deploy:migrations -S branch=rel_001

Capistrano – Multiple Environments

Darian Shimy — Fri, 02 Oct 2009 20:55:27 +0000

Capistrano is designed to deploy your Rails application (yes it can handle others, but more work is required) to production. However, most applications need to be deployed to more than one environment. For example, we deploy to a staging environment in addition to production. This lets select users and internal employees kick the tires before we release it in the wild. After many complaints, capistrano-ext was born. I am all in favor of using plug ins, but this is such a trivial issue, it’s easier to add the code than worry about the plugin.

set :stage, "staging" unless variables[:stage]
set :deploy_to, "/var/www/#{application}"
 
case stage
when "staging"
  set :rails_env, "staging"
  role :web, "staging.example.com"
  role :app, "staging.example.com"
  role :db,  "staging.example.com", :primary => true
when "production"
  set :rails_env, "production"
  role :web, "production.example.com"
  role :app, "production.example.com"
  role :db,  "production.example.com", :primary => true
end

To deploy to the correct environment call capistrano:

$ cap deploy -S stage=staging

If your staging and production share the same machine (not the best idea):

set :stage, "staging" unless variables[:stage]
server "example.com", :app, :web: db
 
case stage
when "staging"
  set :rails_env, "staging"
  set :deploy_to, "/var/www/staging-#{application}"
when "production"
  set :rails_env, "production"
  set :deploy_to, "/var/www/production-#{application}"
end

Update: Fixing Rails in Snow Leopard

Darian Shimy — Fri, 04 Sep 2009 05:27:12 +0000

I was too quick to declare success in my update to Snow Leopard earlier this week. As it turns out, much of my recovered space came from Xcode being uninstalled. Easy fix. Grabbed the DVD and installed it in a few minutes. After doing some deeper checking, I found anything with native extensions or compiled with Leopard was not working. Thanks for the heads up Apple.

With the move to 64 bit, my older 32-bit version of MySQL was moved to /usr/local/mysql-5.0.45-osx10.4-i686. Grabbed the latest and installed the 64-bit version. You may want to skip the preferences pane since it runs in 32-bit and causes the System Preferences to reload each time.

Macports needed a fresh install as well. After that I needed to clean out the old builds with:

$ sudo port -f uninstall installed

This wiped everything out and I needed to reinstall my ports. As expected my gems were in need of help as well. Although most were resolved with the following:

$ sudo gem update

the MySQL gem needed some help finding it’s cousins:

$ sudo env ARCHFLAGS="-arch x86_64" gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config

Finally, Mongrel decided to hang during the startup and WEBrick as no better. Had to grab Thin. Worked like a champ. Note to self: need to switch to Passenger for development.

I’m sure I’m missing a few things, but right now, most things seem to be working. I’ll update this post if I find anything else.

Update: Mongrel can be fixed by uninstalling mongrel and fast thread and reinstalling mongrel:

$ sudo gem uninstall mongrel fastthread
$ sudo gem install mongrel

Capistrano is Fixed in Snow Leopard

Darian Shimy — Fri, 04 Sep 2009 03:20:03 +0000

There were a number of things that seemed to break with the upgrade to Snow Leopard. The latest is my ability to deploy Rails application using Capistrano. For some reason, the SSH connection would hang. Looks like this was fixed today with the 2.0.15 release of net-ssh.

To get things working again, just update net-ssh:

$ sudo gem update net-ssh
Updating installed gems
Updating net-ssh
Successfully installed net-ssh-2.0.15
Gems updated: net-ssh

Deployments work like a charm.