Futurechimp

I’d missed it, but Rails now incorporates the functionality previously provided by Thoughtbot’s quietbacktrace gem. It’s pretty easy to use, too. By default, it whacks all of the stacktrace garbage that used to happen in a Rails 2.2 app. It’s also possible to easily add new filters in your test_helper.rb file, e.g.

  # Add more helper methods to be used by all tests here...
  #
  Rails.backtrace_cleaner.add_silencer { |line| line =~ /lib\/shoulda/ }

Artificially inducing a test failure then gives a beautiful little stack trace, like so:

  1) Failure:
test: the JobsController should get new. (JobsControllerTest) [/test/functional/jobs_controller_test.rb:19]:
Expected response to be a <:successsadfsdaf>, but was <200>

Ubuntu releases with broken versions of the QCT Commit Tool appear to be something of a tradition, and Ubuntu 9.10 (Karmic Koala) is no exception. Qct is an easy to use, very lightweight commit tool which I always find myself reaching for when doing commits these days, and I go a bit mental when I need to use subversion and it’s not around. Anway, to the problem:

chimp@boomer:~/workspace/projectname $ qct
Auto-detected Subversion repository

Qct fires up, I type in a commit message, and select which files I want to commit. Everything looks good until we hit the “commit” button:

Error code 1 not expected
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.6/qctlib/gui_logic.py", line 801, in commitSelected
    self.vcs.commitFiles(checkedItemList, msg)
  File "/usr/lib/pymodules/python2.6/qctlib/vcs/svn.py", line 231, in commitFiles
    runProgram([self.svn_exe, 'commit', '-F', filename] + commitFileNames)
  File "/usr/lib/pymodules/python2.6/qctlib/utils.py", line 143, in runProgram
    raise ProgramError(progStr, out)
qctlib.utils.ProgramError: svn commit -F /tmp/tmpChpKyU  app/controllers/application_controller.rb: svn: '/home/chimp/workspace/projectname/ app/controllers' is not a working copy
svn: '/home/chimp/workspace/projectname/ app/controllers' does not exist

Note the space between projectname and app. An older version of qct is not loving the new subversion 1.6 in Ubuntu, which brings some new options with it. Ok, time for the source tarball off of http://qct.sourceforge.net. To compile it, you’ll need to sudo apt-get install pyqt4-dev-tools, then cd into the source directory and run sudo make site-install to install it system-wide. Did you do that? Bad news for not reading ahead, because attempting to use that qct binary gets you:

chimp@boomer:~/workspace/projectname$ qct
Traceback (most recent call last):
  File "/usr/local/bin/qct", line 13, in <module>
    from qctlib.gui_logic import CommitTool
  File "/usr/local/lib/python2.6/dist-packages/qctlib/gui_logic.py", line 9, in <module>
    from qctlib.ui_dialog import Ui_commitToolDialog
ImportError: cannot import name Ui_commitToolDialog

So, that one doesn’t even fire up.

Lastly, I grabbed the latest source for the project:

sudo apt-get install mercurial  pyqt4-dev-tools
hg clone http://bitbucket.org/sborho/qct/
cd qct
sudo make site-install

Don’t forget to apt-get install pyqt4-dev-tools first, or that’ll blow.

The latest source appears to work fine, very many thanks to the author Steve Borho for this great little tool.

Here’s a quick bit of capistrano to copy your production data into your staging environment if you’re running a multi-stage setup:

desc "Loads the production database and assets into the staging environment" 
task :load_production_data, :roles => :app do
  require 'yaml'
  # get the database.yml file from the server
  production_yml = "config/database.production#{Time.now.strftime '%Y-%m-%d_%H:%M:%S'}.yml" 
  staging_yml = "config/database.staging#{Time.now.strftime '%Y-%m-%d_%H:%M:%S'}.yml" 

  begin
    get "/path/to/your/production/current/config/database.yml", production_yml
    get "#{current_path}/config/database.yml", staging_yml

    # load the values
    p_config = YAML::load_file(production_yml)
    username = p_config['production']['username']
    password = p_config['production']['password']
    database = p_config['production']['database']
    s_config = YAML::load_file(staging_yml)
    s_username = s_config['staging']['username']
    s_password = s_config['staging']['password']
    s_database = s_config['staging']['database']
  rescue
    raise
  ensure
    `rm -f #{production_yml};rm -f #{staging_yml}`
  end

  # copy the SQL data
  filename = "/tmp/dump.#{Time.now.strftime '%Y-%m-%d_%H:%M:%S'}.sql.gz" 
  run "mysqldump -u #{username} --password='#{password}' #{database} | gzip > #{filename}" 
  run "gunzip -c #{filename} | mysql -u #{s_username} --password='#{s_password}' #{s_database} && rm -f gunzip #{filename}" 

  # Copy media files under system  
  run "cp -Rf /path/to/your/production/current/public/system/* #{current_path}/public/system/" 
end

Seems to work alright for us – remember that you may need to re-apply database migrations using cap deploy:migrate in case your staging database is ahead of your production database.