Ithaca

rlwrap

2013-01-20T05:00:00Z

Problem

Recently I've been working with REPLs a lot. In many cases, the REPL has Readline support built in. This means that you can use the Up and Down arrows to scroll through the history of the commands you've entered, and often you will even be able to auto-complete language builtins using Tab. If you are already comfortable with Readline from your shell, then you will be able to use Ctrl-a and the like immediately in your REPL of choice. In all these ways and more, Readline makes you far more productive.

Some REPLs, however, have no support for Readline. That means that if you enter an Up arrow, you get garbage output like this:

$ sml
Standard ML of New Jersey v110.75 [built: Fri Jan 11 10:32:43 2013]
- ^[[A

Solution

Luckily, there's a handy and simple solution for cases like this: rlwrap. Simply install rlwrap via your operating system's package manager (or manually), and then invoke the REPL via rlwrap:

$ rlwrap sml

(Edit: On OSX, you definitely want to use a package manager to install rlwrap -- for example, Homebrew or MacPorts -- since you're likely to have trouble installing it otherwise. The problem is that newer versions of OSX don't use GNU Readline. Thanks to a Hacker News commenter for pointing this out to me.)

At this point, even if you do nothing else, the REPL is now at least able to handle Up and Down arrows to scroll through history, and you can use basic Readline commands like Ctrl-a and Ctrl-e to go to the start and end of the line respectively, Ctrl-u to delete back to the prompt (and save the deleted material), Ctrl-y to paste saved text back into the prompt and so on. One other nice thing is that rlwrap saves history per command across invocations. That means that the next time you use that same REPL, your previous commands are still in rlwrap's history. Lovely.

But Wait: There's More

What I've covered is already great, but rlwrap can do even better. You can customize its behavior in various ways. I'm going to run through one customization that's fast and simple, but very powerful. When you invoke rlwrap, you can feed it a file filled with additional completions. rlwrap reads the file before starting, splits the file into words and then supports Tab-completion for all those additional words. For example, if you create a file with all of SML's keywords, then you can load those into rlwrap when you start SML's REPL:

rlwrap -f keywords sml

Now your SML REPL will autocomplete those keywords using the Tab key.

"Sure," you say, "but that's a little annoying." You think it's a pain to enter -f <filename> every time, and it also means you must keep track of where that file is, and so on and so forth.

No problem: rlwrap has you covered. Create a directory somewhere and set an environment variable RLWRAP_HOME in your shell to point to that directory. For example:

mkdir ~/.rlwrap
# Added to my .bashrc
export RLWRAP_HOME="$HOME/.rlwrap"

Now simply save your keywords file in that directory as $RLWRAP_HOME/.<command>_completions. rlwrap will now automagically load those completions every time you call rlwrap command. (I've gone a little fast here. For further details see man rlwrap, particularly the section on files.)

Conclusion

I'm embarrassed to admit that I had not heard of rlwrap until this weekend. But I'm awfully glad I met it. I see hours of happy yak-shaving in my future as I customize it. Most importantly, now my life in the REPLs for SML, Lua and Chicken Scheme, all of which are very minimal, will be far more productive.

git-prompt.sh

2013-01-02T05:00:00Z

Stop Rolling Your Own

Many people have written or adapted complex scripts to get information from git, munge that data and then put it into their shell's prompt. (I've done it myself.) However, git-prompt.sh -- which comes with git -- provides a very high-quality way to do that with nearly no effort. We should all stop writing our own and leverage what git already provides.

Disclaimer

Much of what follows only applies to git 1.8.1. Earlier versions of git-prompt.sh have __git_ps1, but they don't have the extra methods to hook into PROMPT_COMMAND. So you may need to adjust what follows depending on your version of git and its accompanying scripts.

That raises another good point. Whenever you upgrade git, make sure to reread and update the shell-completion and prompt scripts that come with it (git-completion.bash, git-completion.zsh, git-completion.tcsh and git-prompt.sh). They're frequently updated and improved. I upgraded last night, and I was excited to see some changes to git-prompt.sh. So I'm sharing what I found there. Nothing life-changing, but definitely worth looking at. (Note that I use bash, so most of what follows applies to bash specifically, but you can easily adjust it for other shells.)

Final disclaimer: Although these scripts come with git, they may not be automatically installed or sourced, depending on your operating system and package tools. Check for them, for example, in /usr/local/etc. No matter what you can find them in the source directory for git at contrib/completions. Wherever they are, you probably need to source them manually in your shell's startup files.

Three Choices

The script git comes with is excellent, but a little complicated. You can now add Git information to your prompt in three ways. I'll go through each way and give small examples.

For the following, I'm going to assume that I have two helper functions defined already in my .bashrc:

get_dir() {
    printf "%s" $(pwd | sed "s:$HOME:~:")
}

get_sha() {
    git rev-parse --short HEAD 2>/dev/null
}

PS1

The first way to use git-prompt.sh is the simplest. Just place the magic function __git_ps1 into your PS1. For example,

PS1='\u \W$(__git_ps1)\$ '

Most of that is a normal PS1. The call to $(__git_ps1) adds git information to the prompt automatically if you are in a Git repository. The %s expands to name-of-branch in parentheses and adds a space before the addition. The result looks something like this:

achilles ithaca (master)$

If you want more control of the string that git prints, you can add a double-quoted string:

PS1='\u \W$(__git_ps1 " [%s $(get_sha)] ")\$ '

Here I've switched to square brackets, added a space before and after the Git information and used the get_sha function to add the SHA1 number of my last commit to the prompt as well. The result might look something like this:

achilles ithaca [master 8348cc8] $.

PROMPT_COMMAND

The second and third ways use PROMPT_COMMAND instead of PS1 directly. In each case, you add __git_ps1 to PROMPT_COMMAND. The difference between the second and third method is how many strings you provide after __git_ps1. You can add either two or three.

If you provide two strings only, the first string will automatically appear before the Git information in the resulting prompt and the second after the Git information. For example:

PROMPT_COMMAND='__git_ps1 "\u@\h:\w" "\\\$ "'

This gives you a fairly traditional listing of your username, your machine's hostname, your current directory, git information and then $ or #, depending on whether you're running as a regular user or root. Here's what it might look like:

achilles@ilium:~/code/ithaca (master)$

You can also add a third string to PROMPT_COMMAND. In this case, the third string formats output in the style of printf. Here's an example with the third string:

PROMPT_COMMAND='__git_ps1 "\u \W" "\\\$ " "{%s $(get_sha)}"'

Now I'm adding curly brackets and using get_sha. This time, I've also removed all spaces to make the prompt more compact. The result looks like this:

achilles ithaca{master 8348cc8}$

In all the cases where you add a string for formatting, the %s will be the branch-name, everything else is up to you. I'm using my little custom function to get the last SHA1 number, but you can do whatever you like there.

Wait: There's More

Finally, there are a number of variables that you can set in your shell that __git_ps1 will pick up on.

GIT_PS1_SHOWDIRTYSTATE=1
GIT_PS1_SHOWSTASHSTATE=1
GIT_PS1_SHOWUNTRACKEDFILES=1
# Explicitly unset color (default anyhow). Use 1 to set it.
GIT_PS1_SHOWCOLORHINTS=
GIT_PS1_DESCRIBE_STYLE="branch"
GIT_PS1_SHOWUPSTREAM="auto git"

The variables set to 1 can be set to any non-empty value. The others provide choices. (For more details about what each of these does, read through git-prompt.sh.) If these variables are set, __git_ps1 will automatically display information about the state of your repository by adding various symbols to your prompt. SHOWCOLORHINTS also adds color to your prompt, as the name suggests. (This only works if you use one of the two PROMPT_COMMAND methods.)

Let's assume I've set the values as above. The result might look something like this:

achilles dotfiles [master *+= 1a9c53b] $

The * tells me that I have unstaged changes in the repo. The + tells me that I have staged changes in the repo. The = tells me that I'm neither ahead of nor behind the remote branch. (A < means I'm behind, a > means I'm ahead and <> shows that the branches have diverged.)

Using these environment variables in combination with __git_ps1 effectively removes the need for the 50-100 line custom scripts that many people have been using for years to munge Git information into their prompts. (You obviously have slightly less control over what characters show up as hints, but if you really want to control that, you can edit git-prompt.sh itself.) The bottom line is that I trust the maintainers of this script to keep up with changes in how git provides information much more than myself. It also means not everyone on the planet has to create their own munging functions.

One Last Thing

Finally, PROMPT_COMMAND can include more than one command. If you want to use it both for your PS1 and to set your terminal's title-bar, you can do that too:

 PROMPT_COMMAND='__git_ps1 "\u \W" "\\\$ " " [%s $(get_sha)] "; set_titlebar "$USER@${HOSTNAME%%.*} $(get_dir)"'

By the way, PROMPT_COMMAND appears to be the new hot thing. In the past I only remember seeing it to set a terminal's title bar. Now in the last month, I've seen it in three places. Git is obviously using it here. In addition, both chruby and rvm recently began to use PROMPT_COMMAND rather than overriding cd to provide automatic switching of Ruby interpreters when you enter specific directories. I was initially worried about adding too many commands to PROMPT_COMMAND, but so far I'm not seeing any trouble with it. (Note: I use it only for __git_ps1 and set_titlebar. I don't need auto-switching of Ruby interpreters.)

Vim, Ruby and OSX

2012-10-18T04:00:00Z

Disclaimer

This is primarily about solving problems that I had building Vim the way I wanted on OSX. On other systems, a lot of this might be irrelevant or even unhelpful.

The Problem

What I wanted:

vim built with support for perl, python, ruby and lua (for various scripts or plugins)
an easy way to update and rebuild vim
the ability to build Ruby 1.9 with the falcon performance patches
the ability to build the vim against the resulting ruby interpreter

Solving The Problem

In order to solve the first two problems, I've been using my own version of a Homebrew formula for vim.

This formula combines aspects of the "official" homebrew-dupes vim formula with parts of the widely used and widely forked gist vim formula. (Which reminds me: Did you know that you could use a gist as a Homebrew formula? It's easy. For some time, it's been possible to use an arbitrary URL as a homebrew formula in the following way:

brew install URL

To use a gist, you simply get the raw URL and plug that in.)

The combined version of the vim formula that I've put together has the following advantages:

Uses mercurial rather than patches (faster, less chance of a single patch 404-ing).
Offers alternative feature sets as an option when building: tiny, small, normal, big or huge (defaults to "normal")
Offers options to allow building vim with support for numerous programming languages: lua, mzscheme, perl, python, python3, tcl and/or ruby.
Easy to upgrade the formula itself. Simply specify a new version number in two places and done.

Put that all together and a standard build for me will look like this:

brew install --with-features=huge --enable-interp=lua,ruby,perl,python \
    https://raw.github.com/telemachus/homebrew/vim-mine/Library/Formula/vim.rb

You Can't Always Get What You Want

Up until recently, however, I hadn't been able to get this version of vim to build against 1.9 versions of the Ruby interpreter. That meant that I had to build vim against Apple's older 1.8.7 ruby interpreter. I thought that the problem was on vim's end -- that it didn't work with ruby 1.9.3. Recently, however Jack Nagel pointed towards a patch that fixed the problems between ruby 1.9 and vim 7.3. He added this patch to Homebrew's ruby formula.

Since I prefer to use ruby-build, I threw together a formula for it that combines the falcon patches and the patch that vim requires. I've updated the build formula to use the latest falcon patches. It works with ruby-1.9.3-p327.

Putting It All Together

So the workflow now is this:

Build ruby 1.9.x using ruby-build and a custom build formula

Install vim as described above:

brew install --with-features=huge --enable-interp=lua,ruby,perl,python \
      https://raw.github.com/telemachus/homebrew/vim-mine/Library/Formula/vim.rb

Stop shaving yaks

Grep Trimming

2012-07-18T04:00:00Z

The Trick

Today I learned that you can avoid one of the two uses of grep in things like the following:

 ps a | grep cmd | grep -v grep

If that's not clear to you already, the -v option in the second call to grep inverts the matching. So the last bit of the pipeline selects items that don't match the string 'grep'. By adding that second grep, we can trim results that would otherwise look like this:

telemachus ~$ ps a | grep irssi
 2118 s000  R+     0:00.00 grep irssi # We don't want to see this.
  867 s001  S+     0:07.86 irssi

Here's the trick:

# Replace [c]md with whatever command you really have. E.g., [i]rssi.
ps a | grep [c]md
# Let's test it on the example from above.
telemachus ~$ ps ax | grep [i]rssi
  867 s001  S+     0:10.71 irssi

We replaced grep cmd | grep -v grep with grep [c]md. That removes one process from the pipeline. It turns out that we can get the same result without two calls to grep. Awesome. But, um, how the hell does it work?

The How

The pattern [c]md should seem odd. More specifically, it should look useless. Here, however, the apparently "useless use of a character class" serves an important purpose. It hides the grep invocation from the grep results. By the time grep gets to work, the character class [c] has been expanded to just c. So grep goes looking for 'cmd'. However, what ends up in your process list is the unexpanded version: grep [c]md. That of course is not a match for 'cmd', and so the grep you wanted left out of the results disappears. QED. Exactly why the process list gets the unexpanded grep [c]md is still not 100% clear to me. I need to read more about the precise order of operations for shell lines.

(I'm assuming readers know about the use of [] for a character class. Just in case anyone doesn't know about those or wants a review: inside of a character class, you can include one or more literal characters or a type of characters to match. You can also have a negated class, but let's stay simple. So, for example, [bm]at would match 'bat' as well as 'mat'. What's weird about [c]md is that it should be exactly equivalent to cmd since there's only one thing in the character class. Hence, the thought above that it should look useless.)

The Wrinkle

First, a detour. I discovered this trick in a great set of slides by Jan Schaumann. Also, to be perfectly honest, I didn't understand why the trick worked until I listened to the audio recording. It's important to give credit where it's due. Finally, the talk's title is "Useless Use of...This and That", and even if you're not a fan of "useless use of cat"-style lectures, it's very worth a look. (I have mixed feelings myself about "useless use of x" as a slogan. On the one hand, I like the opportunity to improve code by simplifying. On the other hand, people who actually say "That's a useless use of x" in IRC or forums are often just showing off. Bottom line: Jan isn't being a jerk or showing off. He knows a ton. Learn from him.)

Once I understood the idea, I had a further problem. The places where I wanted to use the trick were slightly different: instead of a literal 'cmd', they used a parameter passed to a shell function. My new problem was "How can I use the same trick when I don't have a literal string?" I tweeted Jan himself, and he quickly suggested ps waux | grep $(echo ${cmd}). But he added, "a bit hackish, though." My initial response was that if I was willing to create another process for echo, I might as well just use grep -v (since it's far clearer). After thinking more about Bash parameter tricks, I came up with this:

ps ax | grep [${cmd:0:1}]${cmd:1}

That's foul to read, but it works. The crazy ${cmd:0:1} stuff is built-in Bash substring expansion. In addition to being ugly, though, it's a Bashism, as Jan pointed out to me. It's not supported in POSIX shell. In my case that was fine, but it's not always a good idea. (I was dealing with an explicitly Bash script.)

Where Are We?

Well, I learned a good trick today, but it has some limitations. I figured I would share the tip since I haven't blogged in a bit. Also, I was hoping that maybe some reader would have a suggestion I haven't thought of for how to use the trick even with variable parameters. I'll probably post this to Hacker News and/or Reddit, but you can also respond to me on Twitter. Please let me know if my explanation or examples have any problems.

More importantly, Jan's site is filled with good things (both slide decks from talks and blog posts). You should probably check that out and stop hanging out here.

(Thanks to @nadir for reading a draft and giving me helpful feedback.)

Having an Opinion

2012-04-03T04:00:00Z

TIL

Today I learned that The Los Angeles Times built a site that enables you to search for contributions for and against Proposition 8 by name, employer, date or amount. There's been a great deal of buzz about this recently because Brendan Eich, the creator of JavaScript, donated $1000 to support Proposition 8.

This being the internet, a lot of the responses were hate (in any and every direction) or bad puns or otherwise useless. But I only want to talk about one common thread since I think it's a textbook, but unrecognized, case of derailing. (That is, it's not in the canonical list of derailment strategies in Derailment for Dummies.)

The response I want to talk about is "He has every right to support Proposition 8."

Every Right

What does "He has every right..." mean here? It could mean the literal thing: He has a right (moral or political) to have this opinion. But I doubt it. Certainly in this context, nobody was suggesting we pass laws to outlaw the opinion that gay people should not be allowed to marry.

The real point, I think, is in the implied continuation, "He has a right to his opinion and therefore (sic?) you're somehow wrong to have disagreed." This is pure derailing. After all, what are you likely to respond? "Obviously, he has a right to his opinion. I just think he's wrong..." But now --- by magic --- we're no longer arguing about Proposition 8 or gay marriage. We're discussing people and their right to opinions. We got derailed.

Point?

The point is this: saying "He/I/Whoever has a right to have an opinion" is not a helpful response to criticism. Criticism is (generally) an attempt to engage. "So-and-so has a right to an opinion" is an attempt to disengage. Better responses include reflection, argument, consideration, discussion, etc.

Because, to bring this back to the present case, opinions matter. They change people's lives. In the case of Proposition 8 (and other such laws), they affect a vast number of people who cannot enjoy the rights and privileges marriage brings. If the best response you can think of is "He has a right to his opinion," please try harder. That response doesn't affect the real conversation --- Will we or won't we give equal rights to the people who currently lack them? --- at all. That response is merely hot air.

Adding Categories

2012-03-30T04:00:00Z

nanoc

Before discussing how I added categories to the blog, I need to say a little about how this site works. I use nanoc, a static site generator. (If you already know all about tools to make static websites or nanoc in particular, you should probably skip this section.)

Here's a simplified version of how nanoc works. You create an input folder and fill it with content. The content can be images and other media, but in general it will be text files in whatever format. Common examples will be HTML, CSS, Javascript, Markdown and so on. Once you have everything ready, you run nanoc and it processes the input folder and creates an output folder. The output folder is your website, which you can then upload to your server via FTP or rsync or whatever means you like.

Based on what I've said so far, you might be wondering, "Why not just create the files, place them directly in the output folder and skip the nanoc step?" That is, what does nanoc add? Again this is simplified, but what nanoc adds is filters and processing rules. These give you a lot of the strengths of a dynamic website (rapid site-wide changes, easy to work on in pieces) without giving up the strengths of a static site (speed, security). For example, I write content in Markdown and layouts in ERB. When I have new content or a new layout ready, nanoc automates the process of (1) turning the Markdown into HTML, (2) piping that HTML though the ERB layout and then (3) running the finalized HTML content + ERB layout through Typogruby to give me prettier content. Another simple example: the front page of my site always shows the latest five articles in reverse order of posting. If the site were completely static, I would have to update that list of links every time I wrote a new article. With nanoc, that's handled automatically (via a little Ruby in a template).

Out of the box, nanoc provides a ton of helpers and filters, but I wanted a categories helper. There is a tagging helper, but it wasn't quite what I had in mind. Also, this was a nice opportunity to learn more about nanoc's internals by building something extra for it. For the most part, this was very simple, but I'm going to walk through it anyhow. It will help me solidify what I learned and maybe help someone else too.

Categories?

What do I mean by categories? My site is mostly posts. Each post covers one or more topics, and those topics often overlap. I talk about Vim in a number of places. Same with Ruby, Bash and so on. I wanted every post to display its key topics (its categories), and I also wanted to have the categories be clickable links. Click on Ruby, and you should be taken to a page that shows you all the posts that include Ruby as a topic. Also, I wanted to create a page on the site that displays all the categories as clickable links. When a new category is added anywhere in the site, that page should be updated. (Another good example where a static site generator makes life easier than a truly static site.)

Code, please.

So enough talking, how does it work? There are three main pieces of functionality:

Add categories to posts and display those categories in individual posts
Create a page for all categories
Create pages for individual categories

The first step is simple. In nanoc, textual items are always content plus metadata. The metadata is stored as YAML, and it's completely freeform. So you can add whatever you need there. As an example, the YAML for this page looks like this:

---
title: Adding Categories
kind: article
created_at: 2012-03-30
location: New York, NY
h1: Categories
categories:
- blog
- nanoc
- categories
---

Add that categories item to the YAML, and boom. Now every page has an array of categories.

It's equally easy to access that information about an item. Any metadata for a page can be accessed at @item[:attribute]. So to add the list of categories to each post, I just added this to the posts layout:

<p>Categories: <%= link_categories(@item[:categories]).join(', ') %></p>

The link_categories method hasn't been explained yet, but we'll get there soon. Notice that it takes zero new code to add metadata to an item in nanoc. In order to create category pages, however, and to make the categories links, we need to add helper code. By default, nanoc will require any Ruby code we place in a lib folder at the root of our project. The following lives at lib/categories.rb:

  def all_categories(posts=articles)
    cats = []
    posts.each do |article|
      next if article[:categories].nil?
      cats << article[:categories]
    end
    cats.flatten.compact.uniq
  end
  memoize :all_categories

  def has_category?(category, article)
    if article[:categories].nil?
      false
    else
      article[:categories].include?(category)
    end
  end

  def articles_with_category(category, posts=articles)
    posts.select { |article| has_category?(category, article) }
  end
  memoize :articles_with_category

  def articles_by_category(posts=articles)
    cats = []
    all_categories.each do |cat|
      cats << [cat, articles_with_category(cat)]
    end
    cats
  end
  memoize :articles_by_category

  def link_categories(cats)
    cats.map do |cat|
      ['<a href="/categories/', cat, '.html">', cat, '</a>'].join
    end
  end

The first method goes through an array of articles (all of them by default, though you can pass in a smaller selection) and returns an array of all the unique categories. (Maybe I should use a Set? I'm thinking about it.) The has_category? method should be pretty clear: return true or false if a given category is found for a given article. That method in turn is used by articles_with_category to find all the posts for a given category. The articles_by_category method returns what I think of as an array of tuples. Each item in the array is a two-member array: the first item is a category, and the second is an array of all the articles in that category. I'll need that method soon to build up all the individual category pages and display their posts. The final method, which is pretty kludgy takes an array of categories and returns an array of those category names as HTML links. It's ugly, but better hidden away here then in an ERB view.

The Hard Part

So far, all of this has been pretty simple stuff. The only thing that was complicated was the following. Normally nanoc scans the input folder for items which it then runs through filters according to a set of rules, placing the final results in the output folder. But in this case, the individual category files aren't yet in the input folder. In fact, they can't be there yet. Until we've scanned the articles for their categories, there's no way to know what pages we will need. This gave me a bit of a headache at first, but it turns out that nanoc has us covered. During processing nanoc works with an @items array, and it's possible to add things to that array dynamically and in-memory. That is, you can add things to @items that have no textual representation in advance. In addition, nanoc provides a preprocess method that you can call during compilation. Whatever code you run in that method happens after the site has been scanned but before nanoc compiles the @items. This is exactly the hook I needed. Here's the final method in lib/categories.rb:

def create_category_pages
  articles_by_category.each do |category, posts|
    @items << Nanoc::Item.new(
      "<%= render('category', :category => '#{category}') %>",
      {
        :title => "Posts in #{category}",
        :h1 => "#{category} posts",
        :posts => posts
      },
      "/categories/#{category}",
      :binary => false
    )
  end
end

Using the articles_by_category method from above, we go through each category, create a new nanoc item for it and add that item to the @items array. The content of each item is a single line of ERB that renders some metadata through a template. The rest of the parameters provide the metadata, specify the items identifier (which is sort of its filename) and specify that the item is textual not binary. (For more information about Nanoc::Item initialization, see the API docs.) All of the posts for each category are fed as metadata to the category's in-memory page, waiting to be rendered as links later in a template. It's a little bit of hocus-pocus, but not very much work at all for us to create a large set of pages with no textual reality at all. Shiny.

Links and Credits

The source code of my site is available on Github. Here's the categories code if that's all you want to look at. I just noticed that I don't have a license there, but I'll put one up shortly. In a nutshell, it's "take what you like, but don't blame me". While working on all of this, I received advice from Justin Hileman and Denis Defreyne (nanoc's creator). Justin also shared a gist of some code he uses on his blog for tags. However, nobody but me is to blame for anything stupid in my categories implementation. That's all me.

Blog Tweaks

2012-03-28T04:00:00Z

What's new?

I had a little vacation, and I took the opportunity to improve the site a bit. Although I made a bunch of minor adjustments, there are three real changes: typography, icons and categories.

Typography

I've been using Redcarpet for Markdown and SmartyPants parsing for some time now. Overall I love it and I'm still using it for Markdown, but the SmartyPants handling has some bugs. On the advice of Justin Hileman and Denis Defreyne, I'm trying out Typogruby instead. It does SmartyPants transformations and more. So far, I like it a lot.

Icons

I worked through Code School's CSS Cross-Country last week, and the course does a great job presenting sprites. So it seemed like a good opportunity to practice something and add a little shiny to the site at the same time. I found and bought a beautiful set of social web icons made by @Simek. He includes a set of overlay effects that make it easy to create simple hover effects. So after a little time tweaking the icons and writing some CSS (with the help of Sprite Cow), we now have icons on every page with links to my Github profile, my Twitter profile and the RSS feed of this site.

Gist-deleter Updated

2012-03-08T05:00:00Z

When I released gist-deleter yesterday, I knew it had one stupid flaw: if you clicked repeatedly on the bookmarklet, it would create extra 'delete this gist' links. But I figured that most people wouldn't do that, and I wanted to get it out quickly.

Unfortunately, I got a quick bug report from Mathias Lafeldt who told me that the problem was worse than I thought. Repeated clicks on the bookmarklet created an almost exponential explosion of links. I pushed out a quick-fix yesterday, but here is a full and proper update.

As of now, multiple clicks should not produce any redundant links. Please delete your old version of gist-deleter and update it with the one below. If you find any trouble with this version, please let me know via Github or Twitter.

Gist-deleter v0.0.4

Gist deleter

Announcing Gist-deleter

2012-03-07T05:00:00Z

tl;dr

I've written a bookmarklet that makes it easier to delete multiple gists from the main gist viewing page. (Normally, you need to visit each gist's page in order to delete it. This is tedious if you want to delete five or ten gists.)

Drag the link below to your bookmarks bar. Then to activate it, simply visit your main gists page and click the bookmarklet.

Gist deleter

NB: This is v0.0.2, thanks to Mathias Lafeldt who pointed out that multiple clicks of the bookmarklet increased the number of links exponentially.

NB: Now it's v0.0.3. Enjoy.

NB: And...v0.0.4. Amazing how quickly kids grow up, isn't it?

A little more explanation

I love Github. Truly. Love, love, love it. I love gists. Truly. Love, love, love them. In fact, I probably love gists too much --- and that's where the problem begins. I create a lot of gists: for myself, when I'm on irc, to email people and so on. But many of these gists are very trivial. I'm not likely to ever want them again. In and of itself, that's not a huge deal. However, it makes it harder for me to find the gists I really care about in the sea of throw-away ones.

So every now and again, I want to clean up my gists. This turns out to be slightly harder than it should be. When you visit your primary gist-listing page, there's no way to delete gists from that main page. You can see about fifteen or so gists, but to delete any of them, you must click on the gist's link and then delete it from an individual show page. After deletion, you're redirected back to the main gist show page. The pattern is: list gists, pick gist, delete gist, redirect, list gist, pick gist, delete gist, redirect and so forth. What I want is a simpler workflow: list gists, delete gist, delete gist, delete gist. Done.

As problems go, this isn't the end of the world. I posted a wishlist support ticket on Github, but so far no luck. Fixing it myself didn't occur to me. But yesterday Alexis Sellier tweeted about a bookmarklet he wrote to tweak Github: github-unwatcher. And, thus, an idea was born --- and stolen.

The bookmarklet is the result of a couple of hours noodling around. It appears to work well, and I don't see any bugs. I've tested it on OSX, using Safari, Chrome and Firefox. If you can think of any improvements in the Javascript or have any trouble with the bookmarklet, please let me know on Github or via Twitter. Otherwise, enjoy deleting lots of gists.

A visual explanation

Before:

After:

Just Works?

2012-02-20T05:00:00Z

The good news

Apple now provides a simple, small package if you want a compiler and its basic requirements, but you don't want Xcode. You can get the package here. The download is free, though you will need an Apple developer account. (That's free too.)

If you regularly work on OSX, and you don't care for Xcode, you know this is a big, big deal. The Xcode download is over 3GB. The new command-line-tools-only download is only 164MB. There's also a principle or two involved. I want to compile software. I don't want Xcode or the iOS SDK or anything else. I just want a compiler and its toolchain. The person we owe this to, primarily, is Kenneth Reitz. He's written more about how it all happened and what it means for Homebrew users on his blog.

How to get in on the fun

Warning: Don't do any of this until after you've read the bad news below. You've been warned.

Uninstall Xcode:

sudo /Developer/Library/uninstall-devtools --mode=all

Download the Command Line Tools for Xcode. Install them.
Done (but see below).

The bad news

Apple no longer provides autoconf or its (relatively) vanilla gcc-4.2. This will cause you some problems if you want to install things that still won't build with clang or Apple's llvm-powered gcc. (For example, Ruby 1.8.7.) It will also cause you problems if you want to install something via Homebrew that has a hard-coded dependency on /usr/bin/autoconf. (Up until recently, gnupg was doing this, though that formula was just updated. A quick grep says aplus, fuse4x and sshfs are still offenders.)

How to deal with the bad

Install gcc-4.2 following these instructions (which I owe to Caius Durling):

curl -O http://opensource.apple.com/tarballs/gcc/gcc-5666.3.tar.gz
tar zxf gcc-5666.3.tar.gz
cd gcc-5666.3
mkdir -p build/{obj,dst,sym}
gnumake install RC_OS=macos RC_ARCHS='i386 x86_64' TARGETS='i386 x86_64' \
SRCROOT=`pwd` OBJROOT=`pwd`/build/obj DSTROOT=`pwd`/build/dst SYMROOT=`pwd`/build/sym
sudo ditto build/dst /

Install autoconf via homebrew-alt:
```
brew install https://raw.github.com/adamv/homebrew-alt/master/duplicates/autoconf.rb
brew link autoconf
```
This is John Firebaugh's idea. I had forgotten that Homebrew even had a version of autoconf, so I installed it in $HOME/local/autoconf. His solution is simpler if you're already using Homebrew.
Fix any formula that demands /usr/bin/autoconf specifically.

Depending on your machine, the gcc-4.2 build will take an hour or so. Use the time to do something useful.

Thanksgiving

2011-11-25T05:00:00Z

The part where I'm an idiot

Yesterday, I was a jerk on the internet. Nothing very unusual really. I was frustrated with a few things and in that state where you're mumbling and cursing to yourself as you try to make it all work. Like many people now, I didn't keep my grumbling to myself. I shared it on Twitter. I complained about a software build. Then, I complained about a website being down. To mix things up, I went back to complaining about the software build. Next, I moved on to complain about a software packaging format. Finally, I unloaded on a newly-installed Vim plugin.

All of this was in the space of about thirty minutes. I wasn't patient. I didn't try to understand my problems better. I wanted things to work immediately and to work as I thought they should. I was a jerk. As I said above, this is nothing special. I'm often a jerk. And people often use Twitter to dump this sort of anger and frustration now. (Other places as well, obviously.)

The part where I get humbled

Also yesterday I read Thoughtbot's Thanksgiving post. I remember thinking it was classy, and I almost tweeted about it. I didn't, and beyond thinking briefly that it was classy, it had no further effect on me.

This morning, I woke up to see that Erik Kow messaged me a few times on Twitter. He maintains the website I was complaining about. He thanked me for letting them know the site was down and apologized to me for the problems. Please let that sink in. He thanked me, and he apologized to me - emphatically apologized actually.

The part where I try harder (aka, Don't put it on Twitter)

I remember watching adults grow frustrated and angry. Probably everyone does. Your teacher or father or neighbor or the guy at the store is trying to do something, and it's not working. It keeps not working, and the person begins to mumble and curse and complain. Depending on how bad the problem is, how much the solution matters and who the person is, they maybe even began to yell at other people or throw things. Adults and children, not much different really. I'd love to say that the contemporary difference is just Twitter (or the like). Twitter makes it easy to unleash all of that immediate annoyance on the rest of the world.

Bullshit. Seriously, bullshit. The difference is how you choose to handle yourself. The difference is how you choose to treat other people and their hard work. Every day I see people dump on other people's hard work on Twitter. This software sucks. That software is a piece of a shit. Angry, merciless, rageful bursts. I'm not sure why that's ok, but it's certainly common. It seems especially common among programmers. Maybe they're especially critical by training or nature, or maybe I just follow more programmers?

So, two new rules for me. First, I unfollow anyone who does that. Second, I work much, much harder not to do it myself. Enough is enough. The people who maintain that website, write that software, provide that Vim plugin -- they do it for free, and they let me have both the product and the source code under permissive licences. What the hell is wrong with me?

Thank you, Eric. I'm sorry. You shouldn't have thanked me or apologized to me. I didn't earn either.

Two New Vim Plugins

2011-11-22T05:00:00Z

Like many Unix people, I'm perpetually tweaking, changing, updating and amending my dotfiles. (If you don't know what dotfiles are, that's cool. But you should probably stop reading now. This will only bore you.)

Today's little post is about two new plugins that I'm using in Vim. One is organizational (a kind of meta-plugin, if you like). The other is a small, but very helpful syntax highlighter for HTML files.

Unbundle

Unbundle is a light replacement for Tim Pope's Pathogen. I've talked about Pathogen itself in another post, but here's the tl;dr version. Pathogen manages all of your other Vim plugins. It makes sure that Vim loads plugins (and their documentation), and it allows for a much, much more organized ~/.vim directory. (It also works very nicely with version control, since you can maintain each of the separate plugins in its own version-controlled folder.)

Unbundle, which Suraj N. Kurapati wrote, does the same basic thing as Pathogen. However, it's meant to be lighter, and it has one nice improvement. Using Pathogen, you place all of your plugins under ~/.vim/bundle and they are all loaded when you start Vim. Unbundle allows you to place bundles either under ~/.vim/bundle (in which case they are always available) or under ~/.vim/ftbundle/<something>. If you go the second route, then bundles are only loaded per filetype. So, for example, if you have a great number of complex plugins for Ruby, those will not be loaded when you are working on Perl (or Bash or Haskell or whatever). In all honesty, I haven't ever noticed sluggishness when first starting Vim with Pathogen, but I like the cleanliness of this approach. More modular is often more better.

Having said that, Pathogen is more mature than Unbundle, and I can imagine some edge cases where using ~/.vim/ftbundle/ gets complicated (see below for a specific example). However, so far I'm finding Unbundle to be a solid alternative to Pathogen. Thanks to Luca Pette for a post which led me to discover Unbundle.

MatchTag

Meanwhile, over on Stackoverflow, someone wondered "Can Vim highlight matching pairs of HTML tags in the way that Notepadd++ does?" Now I have to admit that I've never used Notepad++, but the screenshot made me curious to try this in Vim. The idea is that when the cursor is on an HTML tag, that tag and whatever tag matches it are both highlighted. This isn't essential, but it's a nice way to be visually grounded as you're editing HTML. Stackoverlow and Vim's ecosystem being what they are, the question was answered in a few days. Even more: Greg Sexton answered by writing MatchTag, a new Vim plugin to provide this feature for Vim. I've only been using it for a few hours so far, but in a nutshell: I love it.

When I installed MatchTag, I ran into a small issue with Unbundle (or with my use of Unbundle). Initally I placed MatchTag at ~/.vim/ftplugin/html since - duh - the plugin is for HTML. However, what about html.erb files (which are classified as eruby files by Vim)? At the moment, my hackish fix was to put MatchTag also at ~/.vim/ftplugin/eruby. This solves the immediate problem, and disc space is cheap. However, it feels kludgy, and I would need to repeat it for other filetypes. Working through this has also made me realize that I have no idea how Vim handles files with multiple syntaxes in them. I'll probably try to learn more about that and rethink how I'm handling this over the next few days, but if you have any suggestions, please let me know via Twitter. You can also discuss this post on Hacker News or Reddit.

Edit: (20111125) The colorscheme in the screenshot is Anthony Carapetis’ github.vim. A number of people asked, so I thought I should add it here.

Now with nanoc

2011-08-27T04:00:00Z

Has it been that long?

I'm depressed to see that I haven't written since November of 2010. That's bad. We'll say I've been busy and move on. K? K.

nanoc?

Yup. I originally created this blog using jekyll, "a blog-aware, static site generator". I liked it just fine. But ever since using nanoc to build a handful of sites, I've wanted to switch over. I've finally done it. I had thought about completely revamping the CSS, but in the end I just tweaked it slightly. I may still come back and tweak it some more.

Differences

So what, exactly, has changed behind the scenes?

nanoc instead of jekyll as the site generator, as I said above. This is the biggest change.
Sass instead of raw CSS. I'm just beginning to experiment with this, so for the moment, it's really .scss files with raw CSS in them. That should change in the next couple of weeks.
Redcarpet instead of Rdiscount for Markdown to HTML conversion. (As an added bonus, I'm finally using SmartyPants to get proper punctuation.)
I'm no longer using Typekit for fonts. That means that my semi-monthly switches to various exotic fonts is out. Instead, I'm using the DejaVu family from FontSquirrel.
Not to do with this site, nanoc or jekyll, but I'm using rbenv instead of rvm. I had a clean machine (wiped the hard drive and upgraded to Lion), so I decided to experiment. So far I like it a lot.

The source code for this site is still on Github. Feel free to poke around, if you're curious.

What's next?

School is back in session very soon. I would like to write more (such a cliché, but true). I'll shoot for at least one post a month.

In terms of software projects, I'm working on a Sinatra site related to the Washington Capitals. Yes, that's odd, but my wife is a huge fan, and I came across a really fun idea. Also, it gives me an excuse to get to know Sinatra better. Details forthcoming.

I Hate Haml

2010-11-16T05:00:00Z

In which our hero meets his sworn enemy for the first time

Once upon a time, there was a...

Nah, that's silly. Here's the thing: Smart, smart people keep saying how great Haml is. I've looked at it five or eight times, and each time, I quickly stopped looking at it. It just struck me as fussy and precious, and I already like HTML or Markdown just fine. So, no trouble: I just won't use it. No muss, no fuss.

Today though I submitted some content to a website. The site is about a piece of software I care a lot about, and the developer invited me to write something up (because I kept making trouble about it). I wanted to help out, so I forked the site's Github repo, cd into the relevant directory and...oh, crap, the files end in .haml. I popped back into irc, joked a little about Haml and fired up my editor.

Wherein our troubles begin in earnest

At first, things were fine. Haml is in fact fussy and precious, but nothing I can't survive. (By the way, when I say 'fussy and precious', I have in mind the love of whitespace and hatred of braces, brackets and punctuation that Haml displays. I find that precious and fussy, but obviously a lot of people disagree. Maybe I have poor taste.) Then I wanted to do the following: surround three words in a sentence in an <a> element to make those words (only) a link. The other words in that sentence — the words before and after those three — should be left alone. So I look at some Haml files and, hmm, that's odd.

To make only selected words a link, you need to add a newline at the end of the link. So you do something like this:

%p
  Now if you really like
  %a{:href => "http://haml-lang.com"} Haml
  you should visit their website.

The content below that should start at the same level of indentation as the line above it.

Initially, that seems dumb but sort of ok. It's dumb that there's no way except a newline to tell the Haml parser that you are done linkifying text, but, well, maybe that's ok.

I kept writing. Now I wanted to emphasize one or two words in a sentence. Then I wanted to wrap one or two words in a sentence in <code> tags. Can you guess how to do those? Yup:

%h2 Heading content
%p
  This is just some
  %em emphatic
  text. Maybe I'll talk about
  %code $BASH_VERSION
  here.

Seriously. Please let that sink in. Every freaking time you want to use <em>, <code>, <strong> or the like, you need to enter a newline. Your content becomes these little three to five line squibs. Don't believe me? Try it yourself at Html2Haml. Just enter this:

<h2>Heading content</h2>
<p>This is just some <em>emphatic</em> text. Maybe I'll talk about <code>$BASH_VERSION</code> here.</p>

I finished my bit of content, pushed up to Github, sent a pull request. Wow. Just wow.

In which we draw large conclusions from slender evidence

Shortly afterward, I tweeted this:

Who has two hands that love to type and hates #haml? (Now imagine me waving my #haml-hating hands in the air like I just don't care.)

And a bit after that, I added this one:

If you don't hate any software (libraries, code) - really hate, deep deep down - then I don't think I trust your judgment.

I stand by both.

A final admission

This post was found among the papers of a sad, deluded old....

Nah, that's stupid. Here's the thing: I should admit that I've used Haml for a total of about 15 minutes. It may be absolutely amazing, as good as everyone says. Also, I may be very wrong about wrapping select words in <code> or <em> tags. I popped into #haml on irc, but didn't get any response. If I'm dead wrong, please let me know by email (telemachus /at/ arpinum /dot/ org) or on Twitter (@telemachus). I'll be happy to update this by eating some crow.

Wherein I eat some crow

Posting this was helpful for two reasons. First, I learned something. Second, I let off some steam. So what did I learn? It turns out that Haml can handle what I wanted pretty easily.

First, you can simply put raw HTML into Haml. That's the easiest thing and what I should have done here. (It's documented in Haml's docs under plain text, and I simply wasn't looking there carefully enough.)
Second, apparently Haml really isn't made for chunks of content. This is well-known to people other than me, and a popular solution is to use a filter, like :markdown or :textile. So it might look something like this:
```
  %p
  :markdown
    This is some *emphatic* text. Now here's `$BASH_VERSION`
```

Thanks to all the commenters on Hacker News and the people who responded on Twitter. Many of them told me pretty clearly I was an idiot, but I learned something. I can live with that.

While I'm here again, Chris Eppstein wrote a post called Haml Sucks for Content. You should probably read it, since it's more accurate and fairer to Haml than mine was.

Ruby Loves Vim Conceal Too

2010-11-06T04:00:00Z

This is why Twitter is useful

Vim 7.3 has some serious new features, one of which at least (:h persistent-undo) is a really, really big deal. But I'm not going to talk about those right this moment. Instead, I'm going to talk about something I just came across in a tweet and blog post by Perl hacker Yo-Ann Lin (aka c9s, aka cornelius).

The new feature is conceal, and it allows you to visually alter your code so that in place of a keyword lambda (or immediately before a lambda-like structure), you see λ. This is completely unnecessary (it doesn't really do anything to your code), but it became absolutely essential to me. Having seen it for Perl and Python, I wondered how hard it would be to provide this for Ruby. It turns out not to be very hard at all.

The code

You simply need to create a small syntax file for your language of choice, and define a cchar for specific items you want to conceal. (In a minute, I'll say more about what conceal really means here.) As an example, here's all it takes to conceal Ruby's not with ¬ and lambda with λ

    if !has('conceal')
        finish
    endif

    syntax keyword rubyControl not conceal cchar=¬
    syntax keyword rubyKeyword lambda conceal cchar=λ

    set conceallevel=2

The initial bit simply tells Vim to move along if the conceal feature isn't available. After that, we specify what we want to conceal, and with what character. The final line sets the conceal level to hide the specified item completely and replace it with the chosen alternative. (There are four choices for conceallevel. See :h conceallevel for further details.)

The effect

Pictures speak louder than words here:

Take a close look at the two images. If your cursor is off the line where the conceal would occur, you see the conceal character only. However, if you move back up to the relevant line, the actual code reappears (so that you can edit it). What's important to clarify is that your code is never changed. The effect is purely visual.

Serious uses?

For the moment, I haven't gone any further with this, but I can imagine some cases where this feature could be genuinely useful:

HTML - no more - or & - replace the entity with the visual character you expect.
Markdown - See HTML, but imagine replacing + with a list's bullet.

On the other hand, you might argue that this would be a terrible idea for HTML. After all, you need to know that you typed < and not < in order to avoid breakage. So I'm not entirely sure yet how much I will use this feature in these ways. That said, I will certainly be seeing a lot of λ instead of lambda in Ruby. That one shouldn't get me into any trouble.

Links

For more on this feature and how people are using it, see the following:

The LaTeX example in particular might point towards more serious uses for conceal.

FTP Meet HTTPS

2010-10-14T04:00:00Z

Grandpa, what's FTP?

Nah, I'm not really going to talk about FTP, but I learned something today about using an old-school FTP configuration file with a new-fangled version control system.

For some time now, both git and github offer improved HTTP support. That is, using git over HTTP(S) is much, much more efficient than it once was. I've been somewhat randomly using HTTPS instead of SSH, and so up until earlier tonight, about 40% of my repos were HTTPS and the rest were still SSH. This is a pain, not least of all because my fingers often reflexively type one password when I need the other. Today, however, I read about a trick that convinced me (1) to change over to HTTPS altogether and (2) to stop using the damn password every time.

Short version: if you add something like the following to ~/.netrc, then you can pull and push from Github using HTTPS, without entering your password:

machine github.com
login YOUR_NAME_HERE
password DONT_TELL

Now, if you're anything like me, you're saying, "~/.netrc? What's that?" And that is where we come back to FTP. Your .netrc as the 'rc' suggests is a Unix/Linux configuration file. Apparently, back when dinosaurs walked the earth, people used this specific config file to store login information (and macros) for FTP sessions. Although most write-ups that I found online focus on FTP, one source says more generally, "This file is part of TCP/IP in Network Support Facilities." As such, it makes sense for git to check there for credentials, but I'm guessing that most people no longer even use a .netrc. I certainly didn't have one until today.

Although I now see that use of this config file is mentioned in the comments to Github's announcement of smart HTTP support, I only met the idea today in a tweet from Githubber (is that a noun?) @atmos (Corey Donohoe). After a little back and forth with him to figure out details, I suggest you do this:

vim ~/.netrc # mvim, mate, gedit, emacs, whatever...
chmod 600 ~/.netrc
cd where_you_keep_your_code
perl -i.bak -ple 's{git\@github\.com:}{https://github.com/}' */.git/config
perl -i.bak -ple 's{username\@}{}' */.git/config

You can then test that all is working well by cd-ing into a repo and running: git ls-remote. You should get results without needing to enter your password. (By the way, you may not need the second one-liner. I had some repos which were still using ssh and others which were using git 1.6-friendly URLs. See below on that. In any case, the first one-liner changes ssh repos to HTTPS and the second changes one form of HTTPS URL for another which you need to make this work.)

Caveats

Now for the fine print.

You are putting your Github password into a file in the clear. Depending on your machine's physical and network security, this might be a very bad idea. You've been warned.
This won't work with the URLs that Github currently suggests for HTTP, the ones that look like this: https://telemachus@github.com/telemachus/ithaca.git. According to @atmos, those exist for backward compatibility with older versions of git, and they are served from a different machine. Simply translate such URLs to http://github.com/telemachus/ithaca.git, and you're good to go.
That said, this also won't work with earlier versions of git (where earlier means 1.6 or lower, I think). So, depending on what version of git you're using, this whole idea might be moot for you.

If I've made any mistakes or you think this is a terrible idea, feel free to let me know at telemachus /at/ arpinum /dot/ org. Otherwise, I hope you find this as useful as I did.

Edit: A quick follow-up - An early commenter on Hacker News suggests that an ssh-agent is a better way overall to handle password-free login. I don't want to steer anyone wrong, so see comments there for counter arguments to this post.

A New Bash Prompt

2010-10-09T04:00:00Z

TODO: FIXME

For months, my $HOME/.bashrc had a big fat FIXME above the prompt. Like most shell users, I'm a relentless tweaker and I just couldn't get it to a place I liked. A recent blog post about Git information in a ZSH prompt gave me some new ideas. Here's the code I came up with as well as a screenshot.

    ## The prompt below gets ideas from the following:
    # http://briancarper.net/blog/570/git-info-in-your-zsh-prompt
    # http://github.com/adamv/dotfiles/blob/master/bashrc
    # http://wiki.archlinux.org/index.php/Color_Bash_Prompt
    txtred='\[\e[0;31m\]' # Red
    txtwht='\[\e[0;37m\]' # White
    bldred='\[\e[1;31m\]' # Red
    bldgrn='\[\e[1;32m\]' # Green
    bldylw='\[\e[1;33m\]' # Yellow
    bldwht='\[\e[1;37m\]' # White
    end='\[\e[0m\]'    # Text Reset

    function parse_git {
        branch=$(__git_ps1 "%s")
        if [[ -z $branch ]]; then
            return
        fi

        local forward="⟰"
        local behind="⟱"
        local dot="•"

        remote_pattern_ahead="# Your branch is ahead of"
        remote_pattern_behind="# Your branch is behind"
        remote_pattern_diverge="# Your branch and (.*) have diverged"

        status="$(git status 2>/dev/null)"

        state=""
        if [[ $status =~ "working directory clean" ]]; then
            state=${bldgrn}${dot}${end}
        else
            if [[ $status =~ "Untracked files" ]]; then
                state=${bldred}${dot}${end}
            fi
            if [[ $status =~ "Changed but not updated" ]]; then
                state=${state}${bldylw}${dot}${end}
            fi
            if [[ $status =~ "Changes to be committed" ]]; then
                state=${state}${bldylw}${dot}${end}
            fi
        fi

        direction=""
        if [[ $status =~ $remote_pattern_ahead ]]; then
            direction=${bldgrn}${forward}${end}
        elif [[ $status =~ $remote_pattern_behind ]]; then
            direction=${bldred}${behind}${end}
        elif [[ $status =~ $remote_pattern_diverge ]]; then
            direction=${bldred}${forward}${end}${bldgrn}${behind}${end}
        fi

        branch=${txtwht}${branch}${end}
        git_bit="${bldred}[${end}${branch}${state}\
    ${git_bit}${direction}${bldred}]${end}"

        printf "%s" "$git_bit"
    }

    function set_titlebar {
        case $TERM in
            *xterm*|ansi|rxvt)
                printf "\033]0;%s\007" "$*"
                ;;
        esac
    }

    function set_prompt {
        git="$(parse_git)"

        PS1="${txtred}\u${end} ${txtred}\W${end}"
        if [[ -n "$git" ]]; then
            PS1="$PS1 $git ${bldcyn}❯❯${end} "
        else
            PS1="$PS1 ${bldcyn}❯❯${end} "
        fi
        export PS1

        set_titlebar "$USER@${HOSTNAME%%.*} $PWD"
    }

    export PROMPT_COMMAND=set_prompt

And a screenshot:

Colors

The theme itself is a lightly modified version of Todd Werth's IR_Black, and the traffic lights colors idea I took from Brian Carper's ZSH version. I like the result a lot, but I have a hard time seeing the difference between the green dot (a clean repo) and the yellow (items staged but not yet committed). This may be because the colors are so close, and it may be because I'm red-green color blind. In any case, I'm leaving it as-is for the moment, but that's the next thing I'll obsess over.

Share and share alike

The code for both the prompt and the adjusted theme are in my dotfiles repo on Github. If you do something better with it, drop me an email at telemachus /at/ arpinum /dot/ org.

Fun with Perlbrew

2010-08-06T04:00:00Z

Now here's something we hope you'll really like...

I've written a lot about Perlbrew and RVM, so I won't go into any detail about them again. (Check the Archives if you want to look for posts with more about why I love them.) The news today is simply that I've written two small things to help myself and other Perlbrew users: a Vimscript to get the current Perl interpreter into your Vim status line and Bash completion for Perlbrew. I am very much a novice at both Vimscript and Bash completion, so I would be happy to receive any feedback, bug reports, suggestions, criticisms, etc.

In any case, you can find both scripts on Github. Feel free to fork and improve them:

Including Ruby Modules Dynamically

2010-07-29T04:00:00Z

You want what?

I'm not sure whether this is a common need, but I also doubt I'm the only person ever to want it. At a certain point in my application, I will include FileUtils. However, FileUtils comes in three flavors: FileUtils, FileUtils::DryRun and FileUtils::Verbose. The three flavors do pretty much what you would expect:

Default flavor: export cp, mkdir and company
A simulation flavor: export cp and company, but don't actually do anything. (This is like adding a :noop option to every command.)
A verbose flavor: export cp and company, but be chatty whenever you run a command. (This is like adding a :verbose option to every command.)

What would be nice is if I could let the user pick which version of FileUtils she wants by passing an appropriate flag at runtime. (It's a command-line application.) The options part is no problem (thanks to OptionParser), and I can easily pass the choice over to the part of the application that will do the include. However, this is where it gets tricky. This won't work. Can you guess why?

class Worker
  def initialize(choice)
    if choice == 'dryrun'
      include FileUtils::DryRun
    elsif choice == 'verbose'
      include FileUtils::Verbose
    else
      include FileUtils
    end
  end
end

It doesn't work because include is a private method of Module, and self is the instance inside the initialize not the class. Hrmm. At this point, I came up with two bad solutions. (They worked, but stank, and I won't even go into them here.) I also posted a question to Stack Overflow. (See the question, if you are really curious about the two bad solutions.) What follows are two better answers and a bit of increased Ruby understanding for me.

First solution: use the `self`

The first (and so far, only) response to my SO question began, "So what if it's private?" The author then reminded me that there are ways around that kind of privacy:

class Worker
  def initialize(choice)
    if choice == 'dryrun'
      self.class.send(:include, FileUtils::DryRun)
    elsif choice == 'verbose'
      self.class.send(:include, FileUtils::Verbose)
    else
      self.class.send(:include, FileUtils)
    end
  end
end

This delivers the desired include to the right object (the instance's class). Works great, and for my specific use-case, this is the answer. It does mean, however, that all instances of this class share the same include. But the response I got also showed me another way.

Second solution: let each instance do its own thing

In my case, all instances should work together. Either they all do a dry run only, or they all do it for real. But sometimes, you will want more granularity than that. You may want this instance to be verbose, but that one to work silently, while that third one over there is a no-op dry run. You can get that too:

class Worker
  def initialize(choice)
    if choice == 'dryrun'
      extend FileUtils::DryRun
    elsif choice == 'verbose'
      extend FileUtils::Verbose
    else
      extend FileUtils
    end
  end
end

Using extend, we bring the module's methods in for each object on a per-object basis (as singleton methods for that object, rather than class-level methods). Again, in my case, this isn't necessary, but it's good to know for some other time. While I'm here, there's another way to write this up as well:

class Worker
  def initialize(choice)
    if choice == 'dryrun'
      class << self; include FileUtils::DryRun; end
    elsif choice == 'verbose'
      class << self; include FileUtils::Verbose; end
    else
      class << self; include FileUtils; end
    end
  end
end

I can't think of any reason to prefer the more verbose version, but it's good to be familiar with the look since I may see it in other people's code.

Some Vim-related Notes

2010-06-28T04:00:00Z

Vim rocks, but you knew that, right?

I use Vim as my primary editor in a variety of environments (OS X, Debian and OpenBSD), and it's the bee's knees. Having said that, this post won't offer Vim-boosterism. Instead, I will note down a few things I've either discovered or improved lately.

Pathogen = plugin-organizing demon ninja

I have no idea what that header means either. However, I do know that Tim Pope's Pathogen plugin is an outstanding way to manage all your many Vim add-ons. It takes the same approach to package management that Homebrew or Stow does: each item goes into its own folder inside $HOME/.vim/bundle, and then Pathogen makes sure that everything inside there gets properly loaded at runtime. It makes updating or uninstalling individual items a breeze. Go get it; I'll wait.

Oh, ok, here's a brief run through of how to get it and set it up:

If you already have lots of things in $HOME/.vim, then the best thing is to move that entire folder out of the way and start fresh. It's a bit of work to repopulate your add-ons (took me about an hour and a half to get things all just so again), but it's worth it.
```
cd ~
mv .vim vim_backup-`date "+%Y-%m-%d"`
rm -rf .vim
mkdir -p .vim/{autoload,bundle}
cd autoload
curl -o pathogen.vim -L http://www.vim.org/scripts/download_script.php?src_id=12116
```
That last command uses the download link for the most up-to-date version of Pathogen today. In the future, I will try to remember to update this post, but if you have a problem, go to the main Pathogen download site (that link should never change) and adjust accordingly.
To enable Pathogen, you need to add some lines to your vimrc file. It's important that these lines go at the very top of that file, before the built-in filetype plugin is loaded.
```
filetype off
call pathogen#runtime_append_all_bundles()
call pathogen#helptags()
```
Those lines insure that every time you start Vim, all your plugins, colors, etc. are loaded (as well as their documentation). Make sure to turn on filetype detection somewhere below this (as normal).
Now you are ready to start installing add-ons. All additional Vim goodies, must go into distinct sub-directories of a the $HOME/.vim/bundle folder. So, if you download a zipfile from Vim's home site, you can simply unzip it this way:
```
unzip zowie_cool_plugin.zip -d ~/.vim/bundle/zowie_cool_plugin
```
But there's an easier, better way to handle this: use git and Github.
```
cd .vim/bundle
git clone http://github.com/msanders/snipmate.vim
git clone http://github.com/Townk/vim-autoclose
etc.
```
No unzipping needed, and in the future, you can upgrade those plugins by cd-ing into their directories and issuing git pull to get the latest changes from Github. To facilitate all this, many Vim add-ons now list Github repositories on their Vim.org pages.
To make it even better, you can automate the git{,hub} bit with a script like this one. (I adapted that from a script by Tammer Saleh. You can find the original on his post about Pathogen.)

Cool, huh?

What's in your status line?

I had never really messed with my Vim status line. The status line, if you don't already know, is the bar right down at the bottom of your editor with information about what you're currently doing. If you've enabled it but not tweaked its settings, it probably has the name of the file your working on and some information about the line and column number of the cursor. Useful, but not exciting.

Then a few days ago @bryanl asked people on Twitter about their Vim status lines. I looked at a few, thought about it and got to work. A couple of days later, and I'm finally done. (Along the way, I learned a bit of Vimscript and went back and forth a bunch with @fuzzymonk about how to get rvm.vim to show your current Ruby interpreter in the status line just right. Lots of fun.)

Here's the final result of my labors:

" status line hijinks
set statusline=%<%f\ %h%m%r%y
\%{exists('g:loaded_fugitive')?fugitive#statusline():''}
\%{exists('g:loaded_rvm')?rvm#statusline_ft_ruby():''}
\%{&filetype=='perl'?'['.system($perlv).']':''}
\%=%-14.(%l,%c%V%)\ %P

If you're visually inclined, try this:

Can't forget Perlbrew & Perl

I was able to get the current Ruby interpreter into the status line by installing Christoper Sexton's rvm.vim, as I said, but what about the current Perl interpreter? This turned out to be surprisingly tricky, and it highlights a difference between rvm and perlbrew that I didn't mention in my last post. Whereas rvm exports a lot of variables into your environment, perlbrew does not. That means that it's harder to get the information from perlbrew to Vim. (This isn't a criticism of perlbrew or rvm. They just handle things differently. Perlbrew is a pure Perl solution, and by definition a Perl script cannot export environmental variables back into its parent process. This is a good thing for security reasons. On the other hand, rvm makes use of Bash scripting, and this obviously can alter your environment. Neither way is better or worse. In different situations, they each have strengths or challenges.)

Edit 2010-06-23: Please ignore the crossed out bits below. I've worked out a slightly better solution and hope to post about it soon.

Edit 2010-08-06: Ok, I finally have the better solution worked out so that it's presentable. See today's post for more

Here's what I ended up doing. To manage your current Perl installation, Perlbrew switches a mess of symlinks in `$PERLBREW_ROOT/perlbrew/bin`. At any given moment, however, `perl` is guaranteed to point at your current Perl interpreter. And obviously Perl itself knows its version (it's in the built-in variable `$^V` for 5.6 and higher). So, I created this environment variable:

export perlv='perl -e "print $^V"'

Notice that's not an alias. It's a variable. Variables in your current environment are available to Vimscript by using the `$` prefix (just as in Bash itself you prefix variables with `$` when you want to use them). That's how rvm.vim gets your current Ruby interpreter: it's in `$rvm_ruby_version` (or other variables). Since perlbrew doesn't export such a variable, I created one, called 'perlv'. The magic comes when you consider what's in that variable and how Vim grabs it. The variable `$perlv` holds a string, and we grab it with Vimscript's built-in `system('command')` syntax. That syntax is normally for running external comamnds. By feeding `$perlv` to `system()` in this way, it's as if we're `eval`-ing the command that lies hiding in the string. It's a gross and utter hack, but it works. (It also switches when your Perl interpreter switches. Imagine you're already working in Vim and you issue `perlbrew switch perl-x.x.x`. Most of my initial solutions would never update the interpreter version. They were stuck with whatever version you had _when you started Vim_. However, the `perlv` solution updates: as soon as the status line refreshes, you will see the change.) ~~Finally, if you want the Perl interpreter in a Bash prompt or Bash script, simply `eval` it:~~

echo $(eval $perlv)

~~Again, not elegant, but it's the best I could come up with right now.~~

Rvm and Perlbrew

2010-06-13T04:00:00Z

What were those names again?

Meet my two new best friends: RVM and Perlbrew. They both do similar things, namely install and keep track of multiple Ruby or Perl interpreters and the matching gems or modules. These tools allow you to install and use multiple versions of Perl or Ruby without going crazy or doing hideous damage to any of your projects, co-workers or loved ones. They make me happy.

Why do I need them?

Let's go back a step. Ruby and Perl (with the capitals) are languages. By contrast, ruby and perl (with the miniscules) are interpreters. An interpreter is a program that turns source code into something that your machine can execute. (You like what I did there? I completely glossed over all the gory details of intermediate representation, machine code, bytecode and pretty much everything else. See Wikipedia's article on interpreted languages if you want more detail.) Ruby and Perl are also evolving languages. Ruby is moving towards Ruby 2.0, and new releases of Perl 5.x appear frequently. As the languages evolve, they gain new features, lose (some) old features and shift in various ways - some subtle, some not very subtle at all. Writing code for Ruby 1.8.6 is not quite the same thing as writing code for Ruby 1.9.2. This brings us back to the question in this section: Why do you need RVM and Perlbrew?

You need these tools because you will often want or need to have more than one version of the Ruby or Perl interpreter installed on a machine at a time. Why would you want that? Well, perhaps you have been working for years on a codebase using Perl. When you wrote that project, which is now being maintained rather than actively worked on, Perl 5.8 was the new thing. You know it works well with Perl interpreters of the 5.8.x series. However, Perl has kept improving, and you want to start a new project using 5.12 and its new features. When bug reports come in about the older project, you need to have an older interpreter handy, and you also want to keep all the CPAN modules you installed under the 5.8.x interpreter just where they are (we'll come back to modules in a minute.) Another reason you might want to have more than one interpreter is for learning and experimentation. You keep reading about how wonderful the Enumerators in Ruby 1.9.x are, but you've also read Yehuda Katz's warnings about the stability of Ruby 1.9.1. So you don't want to do all your work in 1.9.1, but you want a 1.9 interpreter around to play with. (Ruby has an additional complication: in addition to the standard MRI or YARV, written in C, for various versions of Ruby, there are also now a number of other implementations of Ruby interpreters written in other languages altogether: JRuby, Iron Ruby, Rubinius, etc.) A third reason, similar to the first, is that you won't always have control over what version of the interpreter you get to work with. I host this site (and some other things) using Geekisp, where their servers run OpenBSD. At work, I use various Macs running OS X 10.5 or 10.6. Those machines may or may not have the same version of the Perl or Ruby interpreter, and what they have isn't up to me. So if I want to work at home on one or another project, I may need to have access to more than one interpreter.

Assuming you now agree that you need multiple Perls and Rubies, you may still wonder why you need RVM or Perlbrew. Answer: installing and keeping track of multiple versions of Perl or Ruby is no small thing. Don't get me wrong, it's not the end of the world, but it does require thought, care and a lot of repetitive labor. That sounds like exactly the kind of task that you should automate via a program. The program would provide a systematic way to install new interpreters and keep track of where you have installed them, in case you want to remove one or more later. RVM and Perlbrew do just this. Moreover, each interpreter carries along with it a whole little ecosystem for documentation and user-installed libraries - Ruby gems or Perl modules from CPAN. You will want some method to switch not just which interpreter your shell is using, but the corresponding gem or perldoc commands as well. Again, RVM and Perlbrew have you covered here. If you are working in Ruby, for example, it's as easy as rvm 1.8.7 or rvm 1.9.2, and you have switched interpreters. Because RVM is smart, when you switch interpreter, everything else switches automagically: your irb, ri and gem follow along without any further intervention from you. Again, you could do all this yourself by installing different interpreters in carefully named subdirectories in /usr/local and adjusting your $PATH variable as needed. You would probably end up wanting to automate the installations and $PATH-switching. Before you knew it, you would end up reimplementing either RVM or Perlbrew. Most likely, you wouldn't do it as well. I certainly wouldn't. That's why you want one or both of these tools.

Installing and using RVM

First of all, RVM has excellent documentation on its website. You should read it. That said, here's a short overview of how to install and use RVM.

As a regular user, install this way:

bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

That command simply uses curl to fetch the latest version of the installation script and then feeds it to your shell to run. For the curious or paranoid, at the time of this writing, the installation script looks like this (note that you can always view the latest script before running it, simply by running the inner curl command without feeding its output to bash):

#!/usr/bin/env bash
if [[ -f /etc/rvmrc ]] ; then source /etc/rvmrc ; fi

if [[ -f "$HOME/.rvmrc" ]] ; then source "$HOME/.rvmrc" ; fi

rvm_path="${rvm_path:-$HOME/.rvm}"

mkdir -p $rvm_path/src/

builtin cd $rvm_path/src

rm -rf ./rvm/ 

git clone --depth 1 git://github.com/wayneeseguin/rvm.git

builtin cd rvm

dos2unix scripts/* >/dev/null 2>&1

bash ./scripts/install

When things are done, you will be prompted to add some lines to your shell's startup files, sourcing RVM. Add the necessary lines, and then either open a new shell or re-source your startup files. You're now ready to use RVM.

Some essential commands, with brief explanation about what each does:

# get help - these two are equivalent, very helpfully
rvm --help
rvm usage

# install and uninstall Rubies
# NB: you need to specify a patchlevel only if you want to install
# a patchlevel that isn't the default for rvm. At the moment, the
# default patchlevel for 1.8.7 is p174, and I'm living on the edge.
rvm install 1.8.7-p249
rvm uninstall 1.8.7-p249
rvm install 1.9.1

# switch to a specific version of Ruby
# again, the patchlevel isn't necessary unless you've installed a
# non-default version of that interpreter
rvm 1.8.7-p249
rvm 1.9.1

# choose a default Ruby for new shells
rvm --default 1.9.1

# switch to the default you've set
rvm default

# switch to the system's built-in Ruby interpreter, pre-rvm
rvm system

# show what rvm has installed and is currently managing for you
rvm list

RVM can do even fancier, more complicated things for you, but this is plenty to get you started. Again, read the excellent documentation. If you get very stuck or have trouble, visit #rvm on irc. RVM's creator Wayne E. Seguin is often there, and the room is helpful and friendly, in my experience.

Installing and using Perlbrew

Perlbrew is quite easy to install, but there's one thing worth considering before you do so. By default, Perlbrew will create a folder in your $HOME called perl5, and that's where it will install and manage various Perl interpreters. There's nothing especially wrong with this behavior (it's pretty standard, actually), but I prefer hidden directories (like RVM's .rvm) for things that I never view or touch except via the command-line. (I take this to the degree that my mail directories for Mutt and my music directories for MPD are hidden away as well.) If you are like me, or you want to change where Perlbrew works in any way, it's easily done. All you need to do is set and export a PERLBREW_ROOT variable in your shell before installation (and later in your startup files). Even with that extra step, installing Perlbrew is as easy as this:

export PERLBREW_ROOT=$HOME/.perl5/perlbrew
curl -LO http://xrl.us/perlbrew
chmod +x perlbrew
./perlbrew install

As with RVM, after you install Perlbrew, you will need to add some initialization to your shell's startup files. Once you've done that, open a new shell or re-source your startup files. Using Perlbrew then is as easy as this (these examples are taken directly from Perlbrew's own documentation, which you can get via perlbrew -h):

# Install some Perls
perlbrew install perl-5.12.0
perlbrew install perl-5.13.0

# Install from a git checkout
cd /path/to/src/perl
perlbrew install .

# See what were installed
perlbrew installed

# Switch perl in the $PATH
perlbrew switch perl-5.13.0
perl -v

# Turn it off. Disable it.
perlbrew off

# Turn it back on. Re-enable it.
perlbrew switch perl-5.13.0

Wrapping up

I've been using RVM for about a month now and Perlbrew for about two weeks. I already don't know how I managed without them. They take something tedious, error-prone and time-consuming and make it trivial and nearly error proof. Thanks to Wayne E. Seguin (@wayneeseguin on Twitter) and Kang-min Liu (@gugod on Twitter, and online here: http://gugod.org/) for these excellent tools.

Notes on Snow Leopard Upgrade

2010-05-23T04:00:00Z

The short version

This is a write-up for myself on a recent upgrade (of two machines - MBP and an iMac desktop) to Snow Leopard. For the most part, things went well. Since I forget details easily, it should be useful for me to have these notes here.

Procedure

Nothing too fancy, but let's make sure I remember the basic steps.

First, wipe the drive. Apple tells you that you can upgrade the OS in-place, without wiping your hard drive. This is true insofar as it's possible, but when I last tried this method, the result was a very sluggish install. (This was when upgrading Tiger to Leopard. After a clean wipe, the install was zippity-quick.) If you go with a full reinstall, you must back up data, music, etc., but you do that already, right? (Don't kid yourself: no backup = eventual fail.) Also, you need to reinstall 3rd party applications. I won't lie - a full wipe makes everything take longer. I still think it's worth it. (You can wipe the hard drive with the installer's disk utility tools. Don't simply "erase" the disk. Write some ones and zeros to that sucker.)

Next, install the OS. Take the time to do a "custom install". You don't get many options, but you can choose to leave out a bunch of cruft - printer drivers, fonts and documentation - that you will never need.

Then get more Unix goodness. To do this, you first need to install Xcode from Apple. There's no other way to get a compiler onto OSX that I know of. There should be: something for me to think about. Anyhow, the version on the installation disc will need an update, so you may as well just download it directly from Apple. (The downside is that you must be an Apple developer to do so. You can register for free. Also, the newest version of Xcode seems to only be available in a bundle with the iPhone OS tools and SDK. In the end, I installed from the disc and then upgraded.)

Here we come to a fork in the road: we need a package manager to handle the complexities of installing all our Unix goodies, and there are lots to choose from. Fink, MacPorts, Rudix or Homebrew? I've used Fink, MacPorts and Rudix before, and there are good things to say about all of them. However, I decided to go with the new kid on the block. So far I like Homebrew very much. It's fast, and the installs stay much slimmer than Fink or MacPorts. The process for submitting patches or new packages is also easy to follow and fast. (Over the first weekend I was using Homebrew, I had two patches accepted and a new package as well. All in about 30 hours.)

Finally, reinstall my data and 3rd party apps. This one is pretty self-explanatory, but some notes about which apps I really, really want.

Chrome for browsing
Bean for word processing
MacVim for editing
AppZapper for cleanup
Theremin (backed by MPD via Homebrew) for music
Gruml for RSS feeds
Itsy and/or Echofon for Twitter (if Itsy supported lists, it would be Itsy period)
Growl for notifications

Tweaks

Even less fancy, but again, it may be useful sometime to have these collected somewhere.

There's no preference to change the hideous default login background. Luckily, this works just fine:

defaults write /Library/Preferences/com.apple.loginwindow DesktopPicture \
    /path/to/picture.png

To manage multiple Ruby and Perl installations (and stay sane), use rvm and App-perlbrew. They both work on the same principle: they automate the installation of multiple language interpreters in your $HOME directory, and they make it easy to switch between interpreters. (rvm hides things away in $HOME/.rvm, and App-perlbrew puts things in $HOME/perl5. I prefer the tidiness of using a hidden directory, but it's not a dealbreaker. Edit: I didn't read the documentation carefully enough. You can change the default installation location easily. Simply set a different PERLBREW_ROOT prior to installation with export: export PERLBREW_ROOT=/path/to/wherever/perlbrew.) I'm going to write up a whole post just on these two later, but if you haven't checked them out, you should.

If you have a Homebrew-installed Python and you install Getmail, the binaries end up lost in /usr/local/Cellar/python/2.x.x/bin - far away from your likely $PATH. This breaks Mutt - or to be more precise, it means that Mutt can't receive mail. My solution: symlink the four Getmail binaries to /usr/local/bin. (There is probably a better fix for this, but I don't care enough about Python installations to bother searching for it.)

ln -s /usr/local/Cellar/python/2.6.5/bin/getmail /usr/local/bin/getmail
ln -s /usr/local/Cellar/python/2.6.5/bin/getmail_fetch /usr/local/bin/getmail_fetch
ln -s /usr/local/Cellar/python/2.6.5/bin/getmail_maildir /usr/local/bin/getmail_maildir
ln -s /usr/local/Cellar/python/2.6.5/bin/getmail_mbox /usr/local/bin/getmail_mbox

Homebrew will install MPD, MPC and Flac just fine, but you will also need to create a $HOME/.mpdconf. Most of the file is standard, but the audio output is odd. (Thanks to Evan Hanson for this tip in his post about MPD on OSX. I also hide my music files away in a hidden directory $HOME/.musica. Both MPD and MPC can find them there just fine, and I don't fiddle with them by hand. For whatever it's worth, here's my basic configuration file:

music_directory     "~/.musica"
playlist_directory  "~/.mpd/playlists"
db_file             "~/.mpd/mpd.db"
log_file            "~/.mpd/mpd.log"
pid_file            "~/.mpd/mpd.pid"
state_file          "~/.mpd/mpd.state"

user                "username"
bind_to_address     "any"
port                "6600"
log_level           "default"
metadata_to_use     "artist,album,title,track,name,genre,date,composer,performer,disc"

input {
plugin              "curl"
}

audio_output {
    type            "httpd"
    name            "My HTTP Stream"
    port            "8000"
    bitrate         "128"           # do not define if quality is defined
    format          "44100:16:1"
}
audio_output {
    type            "osx"
    name            "OSX"
}

mixer_type          "software"

The HTTPD output is not necessary if you don't want to stream music over HTTP. I haven't bothered to set up a Launchd item so that MPD launches automatically on boot. I should, but I need to read up first on Launchd. For the moment, I just launch it manually when I want music. (There's a discussion on the MPD wiki about setting up Launchd, but it's a bit brief. I want to read more about the whole process first.)

Edit: I forgot about fonts. For monospace fonts, I really like Microsoft's Consolas and Ralph Levien's Inconsolata. At the moment, I'm using David Zhou's straight apostrophe version of Inconsolata, Inconsolata-dz, which is worth looking at if you like Inconsolata itself. In order to get Microsoft's fonts on a Mac without installing Office or whatever, I use a modified version of Aristotle Pagaltzis's vistafonts-installer script. (This requires cabextract to work with the fonts, but you can get that from Homebrew. Pagaltzis's script is designed for a Linux environment, but it works well on OSX with only cosmetic changes.)

Edit 2: Last one, I promise, but I forgot one other annoyance. Out of the box on a Mac, you will discover a number of folders in your $HOME directory which you cannot remove. If you try to delete 'Music' or 'Sites' or the like, you get told you can't do that. The message, as I recall, seems designed to make you think removing those folders will break your system - which is bullshit. In a nutshell, Apple uses ACLs to lock these directories down. (ACLs provide permissions for complex scenarios where POSIX permissions give out.) You can remove the ACLs, however, with chmod -N. Once you remove this extra layer of permissions, you can do as you like with your $HOME directory. (The fullest discussion I could find from Apple on ACLs is in their documentation for file server administration. Warning: link goes directly to a pdf.)

By Any Other Name

2010-04-13T04:00:00Z

I want my name - even if it's not actually my name

Pretty much anywhere I regularly post online, I use the handle 'telemachus'. He's a character from The Odyssey. If you don't know who he is, that's ok, but you should probably read more. This post isn't about him though, and it's not about why I chose that particular name. It's about what happens when 'telemachus' isn't available. I hate not getting that name. I need to be Telemachus. He's me; that's my name. I want it. I need it. I must have it.

Of course it doesn't work that way. On most websites and forums, users must have unique names. If I get unlucky and some other Greco-Roman geek got to Telemachus before me, I'm out of luck. When this happens, my first move is to check out the "other" Telemachus. If he is a frequent or well-known contributor, I give up and choose a different handle. However, what often happens is that the name is taken, but the holder of that name rarely posts, or - and this is very common - he hasn't logged into the forum in years. (In irc, by the way, you can often petition to have names released. If the name hasn't been used in some period of time - often as little as six months - you can claim the name for yourself. This recently caused an ugly incident involving Bram Cohen, the creator of BitTorrent.) In that case, I look for a close variant.

First choice is simple capitalization. I feel slightly guilty about this, since it's almost certainly a designer error. (The software validating usernames should count 'telemachus' taken if 'Telemachus' is taken. It really is too confusing to have two users with names that close together. But sometimes people get this wrong.) I always try for 'telemachus' first - it's easier to type - but I'll take 'Telemachus' without complaint. This trick almost never works, but you never know.

Next, I'll try a spelling variant: 'telemachos' (and, of course, 'Telemachos'). The spelling 'Telemachus' is itself a Latin version of the original name. In Greek, the name is spelled with an omicron (ο). So, although many people probably think I can't spell, 'telemachos' looks perfectly fine to me. This compromise works most of the time. But not always. When this spelling is also already taken, then I have to try extreme measures.

My extreme measure of choice is the underscore. In many cases, you can do '_telemachus' or 'telemachus_'. These names are almost never taken, but some sites disallow the underscore as part of a name. Using an underscore has obvious cons: it looks odd & it's harder for other people to type correctly (say in searches or responses). I try to tell myself that '_telemachus' looks sort of like the convention whereby private method names in Perl or Ruby begin with an underscore, but that really doesn't help. (Many people use numbers, but I think these look terrible: tel3machus, telemach0s)

One odd thing is that I can't fully say why I care so much. After a number of years, I have grown unreasonably attached to 'telemachus'. It's my name, and I want it. However, as the internet fills up, it has become more and more common for me to join a site too late. In those cases, I usually flail around and come up with a mediocre, unsatisfying solution.

A new beginning

Recently I had this problem at Twitter. The Twitter name 'telemachus' is taken, and has been since 3:46 PM on September 12th, 2007. The holder of the account appears to have sent one tweet, twice within that same minute. He or she never tweeted again. (Despite that, the account has five followers. Go figure. Can you tell that I am taking this way too personally?) Once upon a time, Twitter would reap dormant or spam accounts if you asked nicely. However, at some point recently they changed their policy. They now politely write back explaining that they don't do that. You can't force a name to be released. I can understand their position. It's a hassle for them and technically there's no way to know that the dormant user might not come back tomorrow and tweet like mad for the rest of his life. They would have to create a policy and yada yada yada. All fair enough, but I wanted my damn name.

My initial approach was to create an account called '_telemachus', but I was never really happy with this. (Obviously 'telemachos' is taken too. Damn.) Seeing @_telemachus in retweets just looked stupid. I eventually deleted that account and stopped using Twitter. As petty as it is, the name was part of why I quit. Recently, I rejoined Twitter, and my current answer is decidedly odd, but at the moment I'm happy with it. The new account uses my real name (which I could get, luckily), but for the 'Name' portion of my Twitter profile, I entered 'Telemachus'. I'm not sure that this is literally a first, but it has to be rare: I used my actual name as an alias in order to be able to use my preferred nom de guerre.

Why am I telling this story?

No reason really. I haven't written a post in some time, and I really thought I should. Also, and this is closer to a real reason, I wonder whether other people are this attached to handles. If they are, I wonder what lengths they go to to get the names they want. Are there some tricks I should know? Is there a support group? Inquiring minds want to know.

No Resolve

2010-02-24T05:00:00Z

New Year's Resolutions and other failures

Apparently I still have a ways to go in terms of getting things done. Nearly two months into the year, and I have one post here. That's pitiful, but I'm going to skip the boring bit where I rake myself over the coals. This post itself will be mostly "recently seen" items. As you can imagine, it's mostly just an attempt to kick-start the process.

Ruby things you may want to look at

Just a few Ruby-related items from around the web:

Gregory Brown is releasing Ruby Best Practices as a free download. So far, chapters 1-5 are online. You can get them here: http://blog.rubybestpractices.com/.
Yehuda Katz has been posting frequently lately. What I particularly like about his recent posts is that he does a lot to clarify how to follow the grain, so to speak, as you work in Ruby. This is perfect for me, since I'm more and more comfortable with the basic syntax of Ruby, but still very much thinking in Perl idioms. Anyhow, I encourage anyone who works with Ruby to check out his blog.
A great short post by Avdi Grimm about a functional idiom in Ruby: First and Rest in Ruby

A manifesto on incestuous cross-posting

I don't remember how I came across this, but Tim Maly wrote a recent manifesto, urging people to unlink their feeds. What's his complaint? By relinking and reposting all your sources (over and over), into each other, you create "slurry everything boxes." No feed can develop or maintain its own voice or style because all streams run together and lose their distinct personalities.

Folks over at Hacker News were not impressed, but I think he makes a pretty good case. In particular, the idea that something I tweet might end up (in all its Twitter-formatted glory) pulled onto all my other sites and then feel completely out of place, unclear and useless makes a lot of sense to me.

In any case, it was good to see someone thinking seriously about how and why to use the internet. See the next heading for the other side of that coin.

It's the end of the world, but I feel fine

Apparently, quite a lot of people have no idea whatsoever how to use the internet. A few weeks ago, ReadWriteWeb ran an article titled Facebook Wants to Be Your One True Login. The article itself isn't interesting - a bland discussion of Facebook and AOL teaming up on blah, blah blah. Take a look, however, at the note that RWW had to post on the article:

Dear visitors from Google. This site is not Facebook. This is a website called ReadWriteWeb that reports on news about Facebook and other Internet services. You can however click here and become a Fan of ReadWriteWeb on Facebook, to receive our updates and learn more about the Internet. To access Facebook right now, click here. For future reference, type "facebook.com" into your browser address bar or enter "facebook" into Google and click on the first result. We recommend that you then save Facebook as a bookmark in your browser.

Apparently, quite a lot of people log into Facebook by (1) Googling for 'Facebook login' and then (2) assuming that the first hit is Facebook. When that doesn't work (as in this case), these people are utterly, utterly lost. They have no fallback position. If you browse through the comments, you won't know whether to laugh or cry or both.

Speaking of Twitter

I'm still tweeting, but I feel like I'm already running out of steam. I find it hard to figure out who else to follow, and I've already been badly disappointed by the streams of two people who (in other contexts) I found pretty interesting. Still, I'm going to keep using it for a bit. I may grow into it.

Having said that, I have found a few very interesting web applications built on top of Twitter's API. One in particular that I recommend is bettween. It's nearly impossible to follow long two-way conversations from Twitter, but bettween makes it easy and fun.

More soon - I promise (myself mostly)

Ok, well, at least I can say that I posted once in February. I just got a very interesting new book (HTML & CSS: The Good Parts by Ben Henrick), so maybe I'll push myself to write up a review of that next. Maybe March will even see two posts. Time will tell.

Yak Shaving

2010-01-02T05:00:00Z

Huh?

Let's start a little bit back from the central idea. I'm good at wasting time. I'm really good at it. I'm all-city, all-pro, all-American. I'm world class. I really wanted this website to have a little style. (I'm no designer, but something at least.) I just haven't done it because of all the time-wasting. Having said that, it's still important to explain a bit more about how and why I waste time so well. Let's do that, shall we?

I don't have a lot to say about why, so I'll do that first. I've thought about it a lot - it's a good way to waste time, after all - but I don't really understand why I have this tendency. I can say that it has something to do with a fear of not knowing enough. If I use Ruby, but Ruby's interpreter is written in C, do I need to know C? Part of me answers "No" for all sorts of good, sane reasons, but it nags me. I have this lingering guilt and shame that I don't really know Ruby, since I don't understand the language that its interpreter is written in. I know this is irrational (and just plain false), but again, it eats at me anyhow. In the case of making a website, there are endless things I might want or need to know more about, so this itch offers a lot of potential pain.

The how is somewhat more entertaining. What I like to do is begin task A, but then (almost immediately) delay A in order to work on task pre-A. Task pre-A - maybe it's obvious, but maybe not - is a task related to A as an (allegedly) necessary pre-cursor. It's something that I decide I absolutely must do before I can begin task A. It happens to everyone at one time or another: you start something and then realize that you have some prepatory work to do first. So you delay the goal and do the groundwork. Fine and good. However, what I do is start task pre-A, but then (almost immediately) push it off in order to do task pre-pre-A. You can probably see where this is going.

Before long, I have a deeply nested stack of things I need to do before I can get anywhere near whatever I started out to do. I'll take this site as an example. For about - awful confession time - five or six months now, I've been working on this site. Once upon a time, I had an ikiwiki blog that I used to post notes and reminders to myself about Perl or Bash or Vim or Debian or sys-admin stuff. It wasn't really a blog, just a place for me to put up things that I thought were cool or I figured out how to do or that I wanted to remember how to do later. I gave up that site some time ago, and eventually I wanted a new one. So I got right to work: I got some new hosting and immediately began stacking up things to do before I could actually write anything here.

Here's an abbreviated list (with sub-lists, naturally) of things I did first.

Push it way back and worry about platforms and version control:
- Git or Subversion?
- Ruby or Perl?
- Jekyll or Rails?
  - Markdown?
  - Textile?
  - Haml?
Are my standards in order?
- XHTML or HTML?
- HTML5 or HTML4?
- I should really learn more about HTML...
  - Microformats?
  - This whole semantic markup thing sounds cool. Let's read more about that.
  - Do I really understand REST?
    - I really need to know more about HTTP...
Should it have a feed?
- RSS?
- Atom?
- Feedburner or do-it-myself?
Comments?
- DISQUS?
- IntenseDebate?
What should the site look like?
- CSS?
- Sass?

At some point around here, I broke out of that cycle of despair. I realized that although I had read a lot and thought a lot and learned some useful things, I was hopeless. A few coincidences helped. First, I read Project Stack Push/Pop by Dave Rolsky and saw Randal Schwartz's comment about yak shaving. The article struck a nerve because it fit too well and my time-wasters aren't nearly as productive as Rolsky's. Second I'm a teacher, so I just had a two-week vacation. Naturally I planned to (finally) get the site going, and naturally I made zero headway. Finally, a new year just began. Although I don't really go in for resolutions, inevitably you get that hopeful but scary feeling that it's a clean slate and anything is possible.

So, that's why this page has no style. After a long, long time I had accomplished nothing except some decisions: Git, Ruby, Jekyll, Markdown, HTML4, an Atom feed and no comments. I was in the process of reading up more on HTTP and retooling my CSS chops in order to design the site. There's a line in Vergil's Aeneid where the hero Aeneas describes Italy as "semper cedentia" - always receding - because he feels as though no matter how much he struggles, he's no closer to reaching his goal (Aeneid III, 496). I felt like that, but less well written. So, the hell with it. I can write an article now about yak shaving and just post the damn thing. This will be good because (a) it will be some actual forward momentum and (b) I can hope that it will shame me into working on the CSS bit more quickly. It's January 2nd now. We'll see how that goes. (Oh, and by the way, the About page is a non-link at the moment. One thing at a time.)

What was that about a yak?

I thought I knew what 'yak shaving' meant, but it turned out I didn't. Here's Zed Shaw on yak shaving:

"Yak shaving" is a programmer's slang term for the distance between a task's start and completion and the tangential tasks between you and the solution. If you ever wanted to mail a letter, but couldn't find a stamp, and had to drive your car to get the stamp, but also needed to refill the tank with gas, which then let you get to the post office where you could buy a stamp to mail your letter—then you've done some yak shaving.

While I was writing this up, I went looking in Eric Raymond's Jargon file and elsewhere for definitions and quotations about yak shaving. I had always thought that it meant the unnecessary, neurotic activity where you spin in ever widening circles away from your goal, but apparently not. I use the word with this negative connotation, but the strict meaning appears to be neutral - or negative but in a different way. In Zed Shaw's example, you actually do need to fill the tank, to go to the post office, to buy the stamps, to finally mail the letter. This is a pain, but it's real work. It turns out that I've been using the phrase wrong all this time. When I figured this all out, my first thought was that I should retitle and rewrite this post. I didn't, for obvious reasons. After all, the first step may be admitting I have a problem, but for me the most important step is the rake task that will post this damn page.

What next?

Well, you know, baby steps and all that. Soon enough I hope to write the About page and add some CSS. At that point, I will have to decide whether to leave this page unstyled - it's kind of the point, really - or to link the style to this page as well. That will be one of those good problems to have. I should also write more posts. Lots to do. And I still need to learn more about HTTP. I hear that HTTP-bis is coming...

Some time later...

So, I finally have some CSS and I've decided not to leave this page in the browser default state. It's just too ugly. I guess that makes this post either ironic or pointless or odd or all of the above. Such is life.