tbaggery

Smack a Ho.st

2010-03-04T00:00:00-08:00

Tired of having no choice but to add aliases for localhost to /etc/hosts every time you work on a site that uses subdomains? Me too. That’s why I grabbed smackaho.st and made it a localhost wildcard, pointing *.smackaho.st at 127.0.0.1. If you’re a Rails developer, try visiting http://dontmakeme.smackaho.st:3000/.

Episode IV: A New Pope

2010-02-28T00:00:00-08:00

I’ve moved my blog to Jekyll. I think this is the post where I’m supposed to apologize for falling off the blog wagon and promise to post more in the future, though truth be told I have few regrets and make no promises. My aged Drupal install had gotten to the point where I felt actively discouraged from posting. Now that I’ve rectified that, I’ve at least enabled myself to post in the future if I have any flashes of inspiration. Still, I promise nothing. I only migrated the handful of posts that seemed less than completely obsolete.

My migration process produced two noteworthy artifacts: Vim syntax highlighting for Liquid and the same for Markdown. There are existing implementations of both of these, but they had limitations I could not accept (most notably, I couldn’t combine them). The Liquid set has some Jekyll specific goodies like YAML front matter highlighting and support for Pygments highlight blocks. You need to explicitly specify which types of highlight blocks you want highlighted and map between the Pygments type and Vim type in your vimrc:

let g:liquid_highlight_types=["html","erb=eruby","html+erb=eruby.html"]

A Note About Git Commit Messages

2008-04-19T00:00:00-07:00

I want to take a moment to elaborate on what makes a well formed commit message. I think the best practices for commit message formatting is one of the little details that makes Git great. Understandably, some of the first commits to rails.git have messages of the really-long-line variety, and I want to expand on why this is a poor practice.

Here’s a model Git commit message:

Short (50 chars or less) summary of changes

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Write your commit message in the present tense: "Fix bug" and not "Fixed
bug."  This convention matches up with commit messages generated by
commands like git merge and git revert.

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, preceded by a
  single space, with blank lines in between, but conventions vary here

- Use a hanging indent

Let’s start with a few of the reasons why wrapping your commit messages to 72 columns is a good thing.

git log doesn’t do any special special wrapping of the commit messages. With the default pager of less -S, this means your paragraphs flow far off the edge of the screen, making them difficult to read. On an 80 column terminal, if we subtract 4 columns for the indent on the left and 4 more for symmetry on the right, we’re left with 72 columns.
git format-patch --stdout converts a series of commits to a series of emails, using the messages for the message body. Good email netiquette dictates we wrap our plain text emails such that there’s room for a few levels of nested reply indicators without overflow in an 80 column terminal. (The current rails.git workflow doesn’t include email, but who knows what the future will bring.)

Vim users can meet this requirement by installing my vim-git runtime files, or by simply setting the following option in your git commit message file:

:set textwidth=72

For Textmate, you can adjust the “Wrap Column” option under the view menu, then use ^Q to rewrap paragraphs (be sure there’s a blank line afterwards to avoid mixing in the comments). Here’s a shell command to add 72 to the menu so you don’t have to drag to select each time:

$ defaults write com.macromates.textmate OakWrapColumns '( 40, 72, 78 )'

More important than the mechanics of formatting the body is the practice of having a subject line. As the example indicates, you should shoot for about 50 characters (though this isn’t a hard maximum) and always, always follow it with a blank line. This first line should be a concise summary of the changes introduced by the commit; if there are any technical details that cannot be expressed in these strict size constraints, put them in the body instead. The subject line is used all over Git, oftentimes in truncated form if too long of a message was used. The following are just a handful of examples of where it ends up:

git log --pretty=oneline shows a terse history mapping containing the commit id and the summary
git rebase --interactive provides the summary for each commit in the editor it invokes
if the config option merge.summary is set, the summaries from all merged commits will make their way into the merge commit message
git shortlog uses summary lines in the changelog-like output it produces
git format-patch, git send-email, and related tools use it as the subject for emails
reflogs, a local history accessible with git reflog intended to help you recover from stupid mistakes, get a copy of the summary
gitk has a column for the summary
GitHub uses the summary in various places in their user interface

The subject/body distinction may seem unimportant but it’s one of many subtle factors that makes Git history so much more pleasant to work with than Subversion.

Easy Ruby Examples

2007-05-03T00:00:00-07:00

Today I devised a little script to generate Ruby examples showing code and output.

% rubydemo '[1,2,3].inject {|m,o|m+o}'
[1,2,3].inject {|m,o|m+o} #=> 6
% rubydemo 1/0
1/0 #=> #<ZeroDivisionError: divided by 0>

Here’s the script I used for generation. (It could have been one line if I didn’t care so much about exception formatting.)

#!/usr/bin/env ruby
print ARGV.join(" ") + " #=> "
begin
  p(eval(ARGV.join(" "),binding,"(demo)"))
rescue Exception => e
  puts "#<#{e.class}: #{e.message[/.*/]}>"
end

The real killer app, though, is using it in conjunction with IRC. Here’s the alias I used in Irssi.

/alias rd exec -nosh - -out rubydemo $*

Now I need merely do /rd 2+2 to get a beautifully formatted 2+2 #=> 4 in any conversation.

Auto-loading Ruby Code

2007-02-11T00:00:00-08:00

An incredibly useful technique when using Ruby is to auto-load at start-up a custom library written for exactly that purpose. This is easy to accomplish with a couple of environment variables, but I see very little discussion on the subject. Thus, I’ve written a nice summary of how to go about setting this up.

The secret to running code at start-up is RUBYOPT. You’ve probably seen this environment variable before if you’ve used RubyGems. It is recommended to set this to a value of rubygems. This is equivalent to always calling ruby as ruby -rubygems. The -r option requires a library, so this option essentially does a require 'ubygems' each time Ruby is started. (The odd name of ubygems was picked to look nice next to -r.)

We’re going to be doing something similar, but with our own library. I’ve traditionally put this file in ~/.ruby/lib/tpope.rb, but I will be using the more user-agnostic mine.rb for the purposes of this example.

The first thing we need to do is find the right place to set this environment variable, along with setting RUBYLIB to a path that holds our file. If you are using a bourne compatible shell, like bash, add this to your shell’s rc file (~/.bashrc for bash):

if [ -f "$HOME/.ruby/lib/mine.rb" ]; then
  RUBYLIB="$HOME/.ruby/lib"
  RUBYOPT="rmine"
  export RUBYLIB RUBYOPT
fi

For C shells, add the following to ~/.cshrc:

if ( -f "$HOME/.ruby/lib/mine.rb" ) then
  setenv RUBYLIB "$HOME/.ruby/lib"
  setenv RUBYOPT "rmine"
endif

If you are running under a GUI environment, you will want to make this variables known to the top level GUI as well. Both Windows and Mac OS X have interfaces to set environment variables. Some desktop environments running under X11 provide such an interface as well, or you can just add similar lines to ~/.xsession or ~/.xinitrc, depending on your setup.

So now that we have this configured, what can we add to this new file? Plenty of things. Let’s start by enhancing the $LOAD_PATH (also known as $:). My strategy here is to pop the current working directory off the end, add a few more directories, then restore it.

old_current = $LOAD_PATH.pop if $LOAD_PATH.last == '.'
%w(.ruby/lib ruby/lib .ruby ruby).each do |dir|
  $LOAD_PATH.unshift(File.expand_path("~/#{dir}"))
end
Dir[File.expand_path('~/ruby/*/lib')].each do |dir|
  $LOAD_PATH << dir
end
$LOAD_PATH << old_current if old_current
$LOAD_PATH.uniq!

I add a wide variety of directories here, feel free to adjust as you see fit. Note the addition of every directory matching ~/ruby/*/lib, which makes it easy to install new libraries in ~/ruby. This is something that would be tricky to do just by adjusting RUBYLIB.

Next, let’s load RubyGems. We can do this in such a way that it won’t fail on systems where it’s not installed.

begin
  require 'rubygems'
rescue LoadError
end

What else? How about always keeping good old Symbol#to_proc handy.

class Symbol
  def to_proc
    Proc.new { |*args| args.shift.__send__(self,*args) }
  end
end

One thing to be careful about is not letting your code grow dependent on this auto-loaded library. For example, if you add the above snippet and start doing pets.each(&:feed) all over the place, your code will break for other people without your library. I still define Symbol#to_proc because it’s handy for debug statements and quick scripts and it’s easy enough to avoid using where it’s important. But I avoid something more invasive like require 'active_support' because it’s harder to keep track of everything it provides. Use your own best judgement.