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
endIf someone knows the original author of these lines, let me know and I’ll give them proper attribution.
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:
1
2
3
4
5
6
7
8
| 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.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| 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 |
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.
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’:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| 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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| 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 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
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 <task> -S stage=[staging|production] -S branch=<branch_name>"
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"
endWhen 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 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
endTo 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
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:
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
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.
Comments (0) 
Technology
| 
console, hirb, irb, rails 
Themocracy