urgetopunt technologies

Hoptoad Notifier v2 and Older Versions of Rails

UPDATE 2009-11-18: It appears the issue has been fixed (though I haven’t had a chance to try it out myself).

(I’m documenting this because I had a hard time googling it.)

With a new Hoptoad API around the corner comes a new version of the hoptoad_notifier plugin. I’ve been using Hoptoad for about a year, and I’ve been generally pleased with it. Though I have no particular plans for taking advantage of the API in the foreseeable future, I figured it would be a good idea to start upgrading from 1.2.x to 2.0.x in case there are any gotchas. If you are using Hoptoad on an application that is running a pre-2.3 version of Rails, there are gotchas.

Among the data the notifier sends to Hoptoad when an exception occurs is the contents of the user’s session. Older versions of the notifier tried to convert the session object to a Hash using session#to_hash, but if the session object didn’t respond to #to_hash (and it doesn’t in Rails 2.2 and earlier) it resorted to sending the @data instance variable contained within the session object. In 1.2.x versions of the notifier you can see this going on in lib/hoptoad_notifier.rb. In the newer version of the notifier, this logic has been moved to lib/hoptoad_notifier/catcher.rb. It calls session#to_hash blindly which raises NoMethodError in Rails 2.2 and earlier.

After spending too much time figuring out what was going on, I stumbled upon a discussion about this very problem. As of this writing it appears the developers know what the problem is and are working to resolve it. Until then, hold off on version 2 of the hoptoad_notifier plugin if you are on Rails 2.2 or earlier.

Snow Leopard, Ruby & PostgreSQL: A Cautionary Tale

My development machine is a Mac running Snow Leopard in 64-bit mode with PostgreSQL (via MacPorts) and Ruby Enterprise Edition (via Ruby Version Manager). I recently upgraded my REE installation to version 1.8.7-2009.10 only to discover that the ruby-pg gem was no longer able to establish connections to PostgreSQL. In the error message I saw the words pg-0.8.0/lib/pg.bundle: no matching architecture, performed a jaunty shrug (I was in a cheery mood) and charged merrily into the task of reinstalling the ruby-pg gem in 64-bit mode.

(At this point a clever person would have paused to consider the fact that neither PostgreSQL nor the ruby-pg gem had changed at this point. A clever person would have taken a moment to double check the way the new version of REE was installed before wasting close to an hour that could have been better spent in the pub. I am not a clever person.)

I set about reinstalling the ruby-pg gem with no configuration options only to meet with verbose failure which began with:

In file included from compat.c:16:
compat.h:38:2: error: #error PostgreSQL client version too old, requires 7.3 or later.
In file included from compat.c:16:
compat.h:69: error: conflicting types for ‘PQconnectionNeedsPassword’
/opt/local/include/postgresql83/libpq-fe.h:266: error: previous declaration of ‘PQconnectionNeedsPassword’ was here
compat.h:70: error: conflicting types for ‘PQconnectionUsedPassword’
/opt/local/include/postgresql83/libpq-fe.h:267: error: previous declaration of ‘PQconnectionUsedPassword’ was here

I tried again with ARCHFLAGS="-arch x86_64" but to no avail. I tried ARCHFLAGS="-arch i386". Skunked again. Version to old? How could that be. The only version of PostgreSQL I’d ever installed on this machine was 8.3.8. I verified the installed version and that pg_config was in my path:

% port installed postgresql\*
The following ports are currently installed:
postgresql83 @8.3.8_0 (active)
postgresql83-server @8.3.8_0 (active)
% pg_config | grep VERSION
VERSION = PostgreSQL 8.3.8

Finally my feeble brain caught up with obvious reality. The build process was working with files from PostgreSQL 8.3.8 (see the path to libpq-fe.h in the error message), but it was unable to read symbols from the PostgreSQL libraries. It was trying to read a 64-bit library as if it were a 32-bit library. I took a closer look at the Ruby and PostgreSQL binaries:

% rvm use ree
<i> Now using ree 1.8.7 2009.10 </i>
% file $(whence ruby)
/Users/jparker/.rvm/ree-1.8.7-2009.10/bin/ruby: Mach-O executable i386
% file $(whence pg_config)
/opt/local/lib/postgresql83/bin/pg_config: Mach-O 64-bit executable x86_64

PostgreSQL was indeed built in 64-bit mode, but REE had somehow been built in 32-bit mode. I rebuilt REE explicitly telling it to build in 64-bit mode:

% export ARCHFLAGS="-arch x86_64"
% rvm install ree

After verifying the new REE binary was indeed 64-bit, I took another shot at rebuilding the ruby-pg gem. It worked perfectly. God’s in his heaven. All is right with the world.

Having opened and closed windows a number of times while trying to fix the problem, I’m unable to verify the state of the environment in which I originally upgraded REE, but I suspect I had a tainted ARCHFLAGS environment variable left over from an earlier task. The moral of the story is:

1. When building software always make sure your environment is clean.
2. Build everything 64-bit or nothing 64-bit.
3. Before wasting prime pub hours fixing something that isn’t broken (ruby-pg), consider what pieces have changed (REE) and investigate them first.

Better Conditional Sum in Google Spreadsheet

In the original article I described using SUM() and FILTER() in a Google Docs spreadsheet to calculate the sum over a subset of cells within a column. Turns out, there’s a better way:

=SUMIF('Worksheet name'!E:E, "food", 'Worksheet name'!D:D)

In this version, the SUMIF() function combines the behavior of the SUM() and FILTER() functions I was using before. The first argument is the column to be compared to the filter value, the second argument is the filter value itself (or the cell address containing the filter value) and the third argument is the column over which the sum is to be calculated. So in the above example, in column D of the worksheet named “Worksheet name” all cells for which the corresponding cell in column E contains the value “food” are selected, and the sum of those select cells is returned.

In addition to being more succinct and easier to read, the use of SUMIF() has the added benefit of returning 0 if there are no rows matching the filter. Using SUM() and FILTER() instead returns #N/A.