I've switched to a octopress-based blog hosted via github pages:

http://jfire.io

Xcode 4.3 no longer includes autotools. If you have installed Xcode 4.3 and uninstalled the previous versions, you will no longer have /usr/bin/autoconf. This isn't usually a problem for installing homebrew formulae, since the downloaded packages should come with configure pregenerated, but if you want to use brew install --HEAD or are building a package from a source repository, you may need it. Here's how to get it:

brew install https://github.com/adamv/homebrew-alt/raw/master/duplicates/autoconf.rb

brew link autoconf

At some point in the near future, homebrew will probably add an autoconf formula. At that point, you'll be able to brew install autoconf directly.

 On July 11th 2011, SFpark announced the first set of meter rate adjustments. Meter operational hours were divided into six distinct rate periods, and the hourly price of metered parking in the project's seven pilot areas was adjusted on a block-to-block basis in response to parking demand during each period:

• +25¢ in periods of 80% or more occupancy
• No change in periods of 60-80% occupancy
• −25¢ in periods of 30-60% occupancy
• −50¢ in periods of less than 40% occupancy

I created this visualization using the d3.js framework and data provided by SFpark. Click for full size.

In Ruby 1.8, constant lookup is mostly lexically scoped, even when using class_eval or instance_eval. That is, constant lookup always searches the chain of lexically enclosing classes or modules. The first lexically enclosing class or module is not necessarily the same as self.class:

Here's the output on 1.8.7:

Here we can see that within the lexical block defining Foo#foo, which is enclosed by class Foo, X refers to Foo::X, while in the lexical blocks used for the singleton method, class_eval, and instance_eval, which are not in class Foo's scope, X refers to ::X, the global constant.

However, in 1.9, the situation changes, and moreover, the behavior is different between 1.9.1 and 1.9.2. Here's the result of running rvm 1.9.1,1.9.2 constants.rb:

So, in 1.9.1, constant lookup in class_eval and instance_eval proceeds from the receiver, rather than the lexically enclosing scope. Particularly for class_eval, this turned out to be a problematic change, breaking existing libraries that depended on the 1.8.7 behavior and making it hard to build DSLs that behaved in predictable ways. Eventually, it was decided to revert to the 1.8 behavior, and this was supposedly implemented:

> [Matz] would like to revert all of instance_eval, instance_exec,
> class_eval, and class_exec to the behavior of 1.8 (including class
> variables). [...]

I have just commited it to the SVN trunk.

I say "supposedly" only because as you can see, the 1.9.2 behavior still differs from 1.8.7 in the case of instance_eval. Was this an oversight, or was the revert later unreverted for instance_eval? If so, what was the rationale? I searched the mailing list and subsequent commits, but couldn't find an explanation. If anyone can shed light on the matter, I would appreciate it.

As you can see, 1.9.2 also changed the behavior for singleton methods: the receiver's scope is now searched before the lexically enclosing scope. This change makes sense to me, and I haven't heard of it causing any problems.

Note that these rules apply to constant definition as well as lookup. In 1.8 and 1.9.2, a constant defined in a class_evaluated block will be defined in the enclosing lexical scope, rather than the scope of the receiver. This is one of the things that makes Foo = Class.new { ... } not quite the same as class Foo; ...; end:

The block passed to Class.new is effectively class_evaluated, so in this example, the constant Quux ends up defined at the top level. (And once again 1.9.1 is the exception: it defines Baz::Quux instead.) This behavior can cause problems if you are in the habit of defining test classes in RSpec describe blocks:

Here TestClass winds up in the global scope, not the scope of the RSpec example group that describe creates. If you have multiple specs that define test classes with the same name, you may get collisions unless you place each describe within a uniquely-named module or diligently remove the constants in an after block. In the above example, you'll get the error "superclass mismatch for class TestClass".

If you need to ensure a particular scoping is used (for example, if you need to support 1.9.1 as well as 1.8.7/1.9.2), you can always be explicit about it by prefixing constants with :: (for global lookup), self:: (for receiver scope), or the fully qualified desired scope:

The state of Selenium on Ruby is a bit confusing. Among the top google results for "selenium ruby" are several links that are badly out of date, and it's not clear which of the many gems are ones you would want to use. This post aims to clear up some of the confusion.

First of all, you should be aware that there are two Selenium APIs: the original 1.0 API, called Selenium-RC, and a newer 2.0 API called Selenium WebDriver. Internally, the two have quite different architectures. In a nutshell, Selenium-RC is based around a Java "Remote Control" server process that launches the browser under test and manages communication between the client process (the Ruby interpreter, in our case) and the browser. The browser is controlled by injecting the "Selenium Core" JavaScript framework into the Browser's built-in JavaScript interpreter. In contrast, WebDriver requires no external process; the browser is launched directly, and controlled via means that vary from browser to browser. For example, WebDriver controls Firefox via a custom Firefox extension.

Ruby has good support for both RC and WebDriver. The selenium-client gem (docs, source) provides bindings for the RC API, and the selenium-webdriver gem (wiki, docs, source) provides bindings for the WebDriver API. You will likely want to use one of these two gems, but which one? If you are using Selenium via a higher-level Ruby library such as Webrat or Capybara, the choice will be made for you: Webrat uses selenium-client, Capybara uses selenium-webdriver. If you want to access a Selenium API directly, I would generally recommend selenium-webdriver. The WebDriver API provides several advantages, including multi-browser testing, page navigation, drag-and-drop, and multi-frame and multi-window support. It recently released its first beta and is where the future of Selenium and Selenium on Ruby lies. It is, however, still beta software and sometimes changes its API in aggravating ways. If stability is of paramount concern, stick with selenium-client.

You may find references to some other Selenium-related Ruby projects. The Selenium gem (with a capital "S") and its associated website selenium.rubyforge.org paved the way for Selenium on Ruby, but today it is obsolete, as is the selenium-rails gem which depends on it. Unfortunately they are still prominently featured in search results and on the outdated "Selenium on Ruby" page, which doesn't even mention selenium-webdriver.

The Selenium RC API relies on an external Java-based server process, and though the selenium-client gem provides rake tasks to start and stop an RC server, it does not provide the actual jar file necessary to run the service. You can either download and install it yourself, or install the selenium-rc gem, which bundles it. You'll sometimes see a gem that depends on selenium-client also depending on selenium-rc solely for the jar, as the jasmine gem does. The selenium-rc gem has some Ruby code in it too, but it more or less duplicates functionality that's already part of selenium-client.

Finally there's the selenium and selenium_remote_control gems, which provide functionality similar to selenium-client and selenium-rc. They don't seem widely used and at first glance I don't see any reason to prefer them to the more popular gems. Recent releases of the selenium-webdriver gem include the selenium-client code as well, and personally, I hope that selenium-webdriver can usurp the "selenium" gem name and become the One True Selenium gem for Ruby.