Sometime last year, around the time of the 2007 RailsConf if I recall correctly, I wrote a tiny little gem called google-geo. It’s a simple group of classes for making queries against Google’s geocoding service and getting some classy objects in return.

Here are some choice examples from the README.

geo = Google::Geo.new API_KEY

addresses = geo.locate '1600 Amphitheatre Parkway, Mountain View, CA'
addresses.size # 1, :locate always returns an Array

address = addresses.first

address.country      # 'US'
address.city         # 'Mountain View'
address.full_address # '1600 Amphitheatre Pkwy, Mountain View, CA 94043, USA'

address.query        # '1600 Amphitheatre Parkway, Mountain View, CA'
address.accuracy     # 8

In the case of sufficiently vague queries, Google::Geo will return more than one:

addresses = geo.locate 'hell'
addresses.size                # 2
addresses.map { |a| a.state } # ['PA', 'NC']

Somebody recently contacted me about including this gem in a OpenBSD package, so I added in a LICENSE and put the project up on GitHub.

The “package” is just an OpenBSD application package. It would be similar to FreeBSD or NetBSD’s ports or Debian’s apt-get system. I’m using your Google-geo library in the web app I’m currently building. I found it very clean and helpful and though the rest of the OpenBSD community should know about it, so I’m creating an application package for it. Therefore, someone can just do a `pkg_add ruby-google-geo` and have your library installed. Also, if someone queries the OpenBSD packages looking for some kind of geo coding library, your library will pop up.

Very cool! Thanks, Clint.

I’ve always been pleased with this library. I think it’s a great example of simple quality.

• First, it has tests. The tests use fixtures based on reasonable assumptions about what we can expect from Google’s service. This means that you can run the tests anytime and very quickly.
• Second, it has no dependencies outside the standard Ruby libraries. XML parsing is relegated to a couple simple methods that use regular expressions to extract values from the response markup. Heresy, eh? No, quality. The overhead and complexity of a “real” parsing library is simply. not. needed.
• Aaannnd you get great objects to work with.

Score!

I’ve noticed that RubyGems(as of version 1.0.1, anyway) does not offer a convenient way to unpack a specified gem and all of its dependencies. So, I decided to try to come up with something simple to work around that. After a few minutes inspecting the Gem API and some help from drbrain, I ended up with this:

#!/usr/bin/env ruby

if ARGV.empty?
  puts "Usage: runpack gem_name"
  exit
end

require "rubygems"
gem_specified = ARGV.first
Gem.gem gem_specified
gems_to_unpack = [gem_specified] +
  Gem.loaded_specs[gem_specified].dependencies.map { |d| d.name }
gems_to_unpack.each { |g| system "gem unpack #{g}" }

I’ve been playing with a little Merb app for my new personal website. One of the focuses of the project is for me to focus less on engineering principles and so-called best practices and more on features and doing new, creative things.

Recently I thought it would be cool if YouTube videos I linked to via my Delicious account were automatically embedded in the HTML representation of the Yahoo! Pipes feed which powers the main view of my new site. I came up with this:

CGI.unescapeHTML Hpricot(open(link)).at("#embed_code")[:value]

Now, if you want to split hairs, it’s definitely questionable. However, context is everything, and in my current one, this solution works great.

I was recently clued into Hackbot’s HaHa’s. It is a delightful and simple concept:

• Images of robots from earlier science fiction are funny.
• Cheesy computer synthesized voices saying things people might say are funny.
• The two combined are even funnier.

So, I made an RSS feed for Hackbot. It is powered by Dreamweaver created HTML, some of the finest quick hackery this side of The Appalachians, and the promise that new jokes are published every Tuesday.

Here’s hoping..

Chris recently wrote about bash aliases for git development. It reminded me of some bash profile tweaking I have done as I’ve gotten into git.

I use subversion as well as git, and I already had some terse aliases ingrained.

alias up='svn up'
alias upi='svn up --ignore-externals'
alias st='clear; svn st --ignore-externals'
alias sv='svn revert'
alias sc='svn ci -m'
alias sd='svn diff | more'
alias svnc='clear; svn st | grep "^C"'
alias sres='svn resolved'

After I make changes to my profile, I use alias sp="source ~/.bash_profile" to load them. To switch to git mode in a shell, I use alias spgit="source ~/.git_profile" which redefines all the subversion aliases as git commands. I like Chris’ checkout function, but I’m going to keep my name for it.

alias up='git pull'
alias st='clear; git status'
alias sd='git diff'
alias sc='git commit -m'
alias sa='git add .'

# sb      => git checkout master
# sb bugs => git checkout bugs
function sb {
  if [ -z "$1" ]; then
    git checkout master
  else
    git checkout $1
  fi
}

Keeping the same aliases for conceptually similar tasks has helped to keep me from slowing down as I ease into git development.