Yesterday, economist Tyler Cowen (famous on the Internet mostly for the superb MarginalRevoluation.com) released an ebook single for Kindle and Nook entitled The Great Stagnation: How America Ate All The Low-Hanging Fruit of Modern History,Got Sick, and Will (Eventually) Feel Better. The book has generated considerable buzz, both for its format (novella length, electronic only, $4 price) and for its content (an incisive, original, non-dogmatic treatment of the recent economic situation in the US and globally). Rather than add yet another comprehensive review, I want to take issue with two specifically technology-related points he makes, one where I think he’s missed the mark, and one where I think he was on the verge of an even better breakthrough.

If you are using Loose Change in a Rails 3 app, version 0.4.2 brings you a Rake task, loose_change:views:push, that scans a directory structure for map and reduce views in JavaScript or CoffeeScript, compiling the latter, and pushing them to the correct design document. To use, make sure your Gemfile includes gem 'loose_change', '~> 0.4.2' and (if you want to use CoffeeScript), gem 'coffee-script. The default directory for view files is db/couch/views/ModelName/view_name/, but you can specify a custom value via rake loose_change:views:push["/path/to/custom/"].

Recently (in version 0.4), loose_change gained GeoCouch support, allowing documents with spatial properties to be queried by bounding boxes. I’ve thrown together a quick demo app on Github that mashes up some sample geographic data in a Rails 3 app with the Google Maps API.

In the course of preparing Spiritwear for its honest-to-goodness for-real-this-time release, I made the decision to bite the bullet and make the upgrade to Rails 3. I have been using CouchDB for all of the models that deal with sizes and colors, because the open-ended nature of those values fit much better in a document-oriented world than a relational one. While on Rails 2.x, I used couchrest-rails as my Ruby adapter to the Couch, but it wasn’t suited to Rails 3’s new ActiveModel layer. I wanted a Ruby interface that felt enough like ActiveRecord and was compatible enough with ActiveModel that I could get some of the Rails freebies (like form_for, for example), but that kept some of the Couch niceties I’d grown accustomed to (custom views that I used to generate order summaries, for example).

While working on loose_change tonight, I ran into a situation I hadn’t run into before in Ruby — the need to keep track of attributes on a class that can be inherited. The solution is class_inheritable_accessor. I’d come across blog articles on the subject before, but for the most part, my eyes glazed over. There’s a limit to how much jargon I can process without a concrete example to compare. Here’s a walkthrough of the problem and the solution.