In our previous post in the series, we took a look at how a Rails core committer could best pull in a branch submitted by a contributer. Today, we're going to be looking at things from the opposite side: How a contributer can best maintain a branch intended for pulling.

Before I continue on in my workflows series, I wanted to take a moment to elaborate on my earlier comments about commit messages. 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.

A few months back, I started a low profile project to create a set of Vim runtime files for various Git filetypes that would ultimately be included with Vim. Given the warm reception they have received, an official announcement seems prudent. Five different filetypes are provided: gitcommit, gitconfig, gitrebase, gitsendemail, and git (which is a generic filetype for things like git log output).

There's no formalized install procedure but the following shell commands should suffice:

mkdir -p ~/.vim
git archive --remote=git://git.tpope.net/vim-git.git HEAD|tar tf - -C ~/.vim

The files tagged with v1.0 are already slated to be included with the next Vim release, and those tagged v2.0 have just recently been submitted for inclusion.

Welcome to my series of articles providing example workflows for working with the Rails core Git repository. My first post is designed for Rails core committers and explains one way to deal with contributions that come in the form of a Git URL and a branch name.

The Ruby on Rails core is now hosted on Git. This is great news for Git fans like myself. For those of Rails core contributors who are coming late to the party, here's a quick list of tips I've put together especially for you. This no substitute for a proper tutorial but rather a Rails biased supplement to one.

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/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.

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.

Ever since I took up IRC, I've noticed an ever increasing tendency to substitute homonyms for other words in my writing. I used to never so much as confuse "it's" and "its", now I routinely catch myself typing "you're" for "your", "to" for too", and even oddities like "one" for "won." Not only has it directly affected my online discussions, I also find it creeping into other, more deliberate forms of writing. Discussing this with my fellow chatters has revealed other people having noticed this phenomenon in their own lives as well when they began to do more communicating online. I would like to propose the term "homonyslexia" to describe this curiosity. I choose this word both because I love clever word play, and because it has zero homonyms of its own. So what is the cause of "homonyslexia"? Is it because of constant exposure to other chatters who demonstrate less than stellar grammar and spelling? Or does the more rapid pace of online chat, as opposed to other written communication, allow us less time to reflect on word choice, with the sloppiness gradually seeping into other areas of our lives?

The Rails plugin for Vim now has an official website. Coinciding with this announcement is a new release of rails.vim. Things have come a long way in the last six months.

Recently, when crafting some HTML macros for Vim, I had a profound idea for a general interface to deal with pairs of parentheses, quotes, HTML tags, and just about anything else. After a few hours work, I had an early version of surround.vim, a Vim plugin which allows one to easily add, remove, and change what I have termed "surroundings." This is perhaps the most useful plugin I have written since rails.vim (which recently had an update, by the way). Examples of use of surround.vim, along with a link to download, are available from vim.org. The development version can also be snagged from my CVS repository.