quick heads up regarding Echoe 3.0.1, GitHub and publishing to RubyForge

Make sure your Manifest file is up to date before firing off the Echoe’s :release task for publishing your Ruby gem to RubyForge. I had changed my README file to be named README.textile to make use of GitHub’s README rendering in their source browser but had forgotten to update the Manifest.

Today, I wanted to publish google-geo to RubyForge, and when I fired off the release with my outdated Manifest, this was the error I got:

_\m/ google-geo | rake release --trace
(in /Users/seth/p/google-geo)
** Invoke release (first_time)
** Invoke clean (first_time)
** Execute clean
Cleaning
** Invoke package (first_time)
** Invoke pkg/google-geo-2.1.tar.gz (first_time)
** Invoke pkg/google-geo-2.1 (first_time)
** Invoke CHANGELOG (first_time, not_needed)
** Invoke lib/google/geo.rb (first_time, not_needed)
** Invoke LICENSE (first_time, not_needed)
** Invoke Rakefile (first_time, not_needed)
rake aborted!
Don't know how to build task 'README'

Clearly, this is not the most obvious direction to the source of the problem. Why is it generating and invoking Rake tasks for file names? Why is it invoking things that are “not_needed”? Yeesh.

After wading through the source code, I eventually realized that Echoe was trying to build the list of files for the gem spec based on the Manifest. I still don’t understand how it ends up that Rake invokes a task named after a file, but that’s beside the point here. I checked the Manifest and saw that it was out of date, and I recalled that the Echoe documentation encourages you to run the :manifest task before :release. Mystery solved.

All this aside, I think it would be reasonable if the :release task ran :manifest for me, avoiding the potential for this confusion entirely.

geocoding info in Ruby.

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!

runpacker.

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}" }

a poor man’s YouTube API in Ruby.

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.