Collapsing the Lighthouse ticket form

We’ve been using lighthouse for the last few months to track bugs/features for RestaurantZite. Overall, its a pretty good bug tracker; not great, but good. One thing that bothers me about it is the expansive nature of the ticket entry/edit form:


Usually, my browser is sized to where the submit button is off of the bottom of the screen, as well as the tag input. The description box is larger than it needs to be (for our use anyway, since we are describing bugs for ourselves and can usually capture it in sentence or two), and the whitespace to the right of the description seems wasted.

To help with this, I wrote a custom stylesheet that turns the above form into:


Its not perfect, but works for me. I compacted the header and the subtab row as well, which will be reflected on all of the pages. I also compacted the ticket view page (which has this form at the bottom for updates) to reduce its vertical space usage.

The css is available for Firefox on for the Stylish plugin, or as a gist. I haven’t tried it in Safari or an SSB, so let me know how it works or what changes you had to make if you do.

server_remote - A Rails plugin for easily accessing servers

Note: this post is out of date. This tool is now a gem instead of a plugin; read all about it here.

I just released server_remote on github. It is a plugin for connecting to remote servers. Once installed, it provides commands via script/remote:

* remote shell – same as ssh’ing to the server (this is the default command, so it can be called with just remote)

* remote console – executes a script/console on the server

* remote logtail – executes tail -f log/<environment>.log on the server

Configuration is in config/server_remote.yml, and is grouped into profiles.

Here is the output of remote usage:

 Executes commands on a remote server over ssh. Configuration is in:
You can override the profile used with -p profile. The default profile is: app
Learn more in the readme:
remote commands are:
commands          List all 'remote' commands
console           executes remote console
help              Provide help documentation for a command
logtail           executes remote tail -f on the log
shell             executes remote shell
usage             prints usage message
For help on a particular command, use 'remote help COMMAND'.

It uses remi’s simplecli gem.

I plan to add other commands as needed, or you can open up Remote::Commands and add your own. Install with: script/plugin install git://

Generating a TAGS file from a git hook

Any decent programmer’s text editor provides some form of symbol lookup. With TextMate, the lookup table generation is built in. If you are using vim or emacs, you will need to use an external program to generate the lookup table. This post covers generating the lookup table for emacs (and with some slight modification, vi), and adding a hook to git to regenerate the table after a pull/merge. For more information on using symbol (tag) lookup with emacs or vim, see this wikia entry for vim, or this emacswiki entry for emacs.


Traditionally, the ctags/etags executable was used to generate lookup tables for vi/emacs respectively. ctag would create a tags file for vi, and etag would create a TAGS file for emacs. Unfortunately, the etags/ctags that ships with MacOS X does not parse ruby code. For that, you will need to use Exuberant Ctags. You can install Exuberant Ctags on MacOS via MacPorts with sudo port install ctags.

git hooks

There are some nice hooks that you can define for git to call after/before it performs certain actions. You can read the full list here. Hooks are defined by placing properly named executables into .git/hooks/ in your repo. The two hooks we care about here are post-merge and post-commit ( Update: the script has been modified to register for the post-checkout hook as well, based on a suggestion from Bryan Liles). The post-merge hook will get called after you do a git pull to merge from another repository, and post-commit is called after a local commit. An important thing to remember about these hooks (and anything else in .git) is that they will not be pushed to the remote repo. So if you develop on multiple machines, or want to share hooks with coworkers, you will need to install them in each local repo.

the kitchen sink

Here is the script I use to handle generating tags from ruby code explicitly, generating tags from a git hook, and installing the git hooks. It really should be two different scripts, but… well… isn’t.

You can read it and see what it does. To have it install the hooks in the current repo, call it with the -i@ option. If you use vim instead of emacs, you will need to remove the @-e option and change TAGS to tags on the ctags call.

Once it is installed, your tags will be regenerated after every commit or pull. You can manually regenerate the tags by calling the script from the repo base directory.

Update: to see a video of this script in action, check out Bryan Liles’ post on

Setting options for Webby

I’m using Webby to manage the static Hand Built Software site, and had a difficult time finding how to set defaults for the webby rake tasks (specifically the deploy:ssh task in this case). Here is what I figured out: you set the values at the top of your project Sitefile like so:

SITE.user = 'tobias' = ''
SITE.remote_dir = '/path/to/site/'
task :default => :build
desc 'deploy the site to the webserver'
task :deploy => [:build, 'deploy:ssh']

For reference, here are the webby defaults which can be overridden (from lib/webby.rb)

  # call-seq:
#    => struct
# Returns a struct containing the configuration parameters for the 
# Webby site. These defaults should be overridden as needed in the
# site specific Rakefile.
return @site if defined? @site
@site =
:output_dir    => 'output',
:content_dir   => 'content',
:layout_dir    => 'layouts',
:template_dir  => 'templates',
:exclude       => %w(tmp$ bak$ ~$ CVS \.svn),
:page_defaults => {
'layout'     => 'default'
:find_by       => 'title',
:base          => nil,
:create_mode   => 'page',
:blog_dir      => 'blog',
:tumblog_dir   => 'tumblog',
# Items for running the heel webserver
:use_web_server => true,
:heel_port      => 4331,
# Items used to deploy the website
:user       => ENV['USER'] || ENV['USERNAME'],
:host       => '',
:remote_dir => '/not/a/valid/dir',
:rsync_args => %w(-av),
# Global options for HAML and SASS
:haml_options => {},
:sass_options => {},
# Options passed to the 'tidy' program when the tidy filter is used
:tidy_options => '-indent -wrap 80',
# List of valid URIs (these automatically pass validation)
:valid_uris => [],
# Options for coderay processing
:coderay => {
:lang => :ruby,
:line_numbers => nil,
:line_number_start => 1,
:bold_every => 10,
:tab_width => 8
# Options for graphviz processing
:graphviz => {
:path => nil,
:cmd => 'dot',
:type => 'png'
# Options for tex2img processing
:tex2img => {
:path => nil,
:type => 'png',
:bg => 'white',
:fg => 'black',
:resolution => '150x150'
# Options for ultraviolet syntax highlighting
:uv => {
:lang => 'ruby',
:line_numbers => false,
:theme => 'mac_classic'
# XPath identifiers used by the basepath filter
:xpaths => %w(
# other possible XPaths to include for base path substitution
#   /html/body//object[@usemap]
#   /html/body//img[@usemap]
#   /html/body//input[@usemap]

Note: this applies to webby 0.9.3

Stepping off the Rails - adventures with Sinatra (Part 2)

In this episode, our trusty adventurer actually runs his Sinatra app, and deploys it to Passenger on shared hosting. See Part 1 for details of building the application.

Launching locally: two ways to skin a cat

I realized that in Part 1 I did not cover launching the app to hit it from the browser. It’s easy! To launch the app, use ruby app_name.rb. This will fire up a mongrel instance on port 4567 for your viewing pleasure.

Once you have defined your rack configuration (see below), you can also run the app inside rack locally with rackup to test your rack settings. This will launch rack inside mongrel on port 9292. Thanks to @jnunemaker for the tip. In fact, John’s article is what I used as a basis for my deployment, with a few changes to support file based view templates.

Rack Configuration

To configure the application to run on rack under Passenger, you need to define a rack configuration file. Passenger expects that file to be named (see Deploying a Rack-based Ruby application in the Passenger documentation). Here is a minimum to run the application:

require 'rubygems'
require 'sinatra'
disable :run
require 'urlunwind.rb'
run Sinatra.application

The only real configuration there is disable :run. This prevents Sinatra from starting a mongrel on port 4567 when the app file is required. This configuration would work for an app that uses no file based templates, and does not reference anything in public/. If you run this config with rackup on url_unwind (rackup, you’ll see errors like:

Errno::ENOENT: No such file or directory - /opt/local/bin/views/index.haml

This is because rack by default sets its base directory to be the path to the called executable (and on my machine, rackup lives in /opt/local/bin/). So we’ll need to explicitly set the paths:

require 'rubygems'
require 'sinatra'
disable :run
set :views, File.dirname(__FILE__) + '/views'
set :public, File.dirname(__FILE__) + '/public'
set :app_file, __FILE__
require 'urlunwind.rb'
run Sinatra.application

Now the app should run properly with rackup.


Sinatra uses rack’s built in logging to log requests, and these log messages get printed to standard out. It would be nice to log these to a file, and we can do that as well in (based on this tip from Chris Schneider). We’ll also need to turn error raising back on, since by default Sinatra swallows errors in production mode:

require 'rubygems'
require 'sinatra'
disable :run
set :env, :production
set :raise_errors, true
set :views, File.dirname(__FILE__) + '/views'
set :public, File.dirname(__FILE__) + '/public'
set :app_file, __FILE__
log ="log/sinatra.log", "a")
require 'urlunwind.rb'
run Sinatra.application

This allows you to add your own logging messages as well, just puts, print, or p@ whatever you want to log. *Note:* you will need to create the @log/ directory for this to work.

Deploy with Capistrano

I used Capistrano to deploy to Dreamhost, and based my Capfile of off John’s directions here. I modified it a bit to pull from github, and to create the tmp/ and log/ directories if they do not exist. Here is my Capfile:

load 'deploy' if respond_to?(:namespace) # cap2 differentiator
default_run_options[:pty] = true
# be sure to change these
set :user, 'app_user'
set :domain, ''
set :application, 'url_unwind'
set :git_path_prefix, ""
# the rest should be good
set :repository, "#{git_path_prefix}#{application}.git"
set :deploy_to, "/home/#{user}/#{domain}"
set :deploy_via, :remote_cache
set :scm, 'git'
set :branch, 'master'
#set :git_shallow_clone, 1
set :scm_verbose, true
set :use_sudo, false
server domain, :app, :web
namespace :deploy do
task :restart do
run "test -d #{current_path}/tmp || mkdir #{current_path}/tmp"
run "test -d #{current_path}/log || mkdir #{current_path}/log"
run "touch #{current_path}/tmp/restart.txt"

Since the Sinatra gem is not installed on Dreamhost, I put it in vendor/ within the app. Since it is not a gem, it must be required with the full path to the base .rb file, both in and in the app file itself (urlunwind.rb in this case). Here is the final

require 'rubygems'
require 'vendor/sinatra/lib/sinatra.rb'
disable :run
set :env, :production
set :raise_errors, true
set :views, File.dirname(__FILE__) + '/views'
set :public, File.dirname(__FILE__) + '/public'
set :app_file, __FILE__
log ="log/sinatra.log", "a")
require 'urlunwind.rb'
run Sinatra.application