AudioBook Log

Posted by code_monkey_steve on May 8, 2011 May 8

For over a year I’ve been commuting for almost 2 hours a day, and in an attempt to stave-off potentially lethal boredom, I’ve been passing the time listening to audiobooks. Here’s what I’ve been reading/listening to:

Note, format is: title (year), authors (readers)

While all of the books were good, the quality of the audiobook depends almost entirely on the voice of the person reading it. So far my favorites are Tom Weiner’s rich baritone and Richard Dawkins’ pleasant english accent. By far the worst, though, is anything read by Carl Sagan: I can highly recommend Carl’s plodding pace and odd word emphasis to insomniacs who don’t respond to strong drugs.

comments | Tags: books

Toward a More Perfect Mongo ODM

Posted by code_monkey_steve on Apr 23, 2011 Apr 23

MongoDB, MongoMapper, and Mongoid

I’m now well into my third Rails project using the MongoDB document database, and while I’m still a big fan of Mongo, I’ve been underwhelmed by the ODMs I’ve used. On the first project, I started with MongoMapper, which is very mature and well-supported, but was a little klunky and tried a little too hard to be like ActiveRecord.

For the second project, I switched to Mongoid, which was a huge improvement. It played nicely with ActiveSupport and ActiveModel, and had better support for doing things the Mongo way. But in the end, it had several nasty bugs related to associations and embedded documents, and the better I understood what I wanted from an ODM, the more I realized that Mongoid wasn’t it.

The Alternatives


I looked into Candy, and found its approach intriguingly fresh. Models don’t have to specify field names or types, and can be Arrays or Hashes or any other Ruby type. But I don’t like the lack of control over the serialization process (e.g. find, save, callbacks, validations, etc.), nor the absence of any sort of relational mechanism. Like Mongoid, it does have a nice query Criteria DSL, though.


I’m not sure Mongomatic even qualifies as an ODM, as it doesn’t seem to do any mapping. From what I’ve seen, it’s just a thin wrapper around the Ruby MongoDB driver, adding little. I don’t know why anyone would bother using it.

MongoODM (my fork)

It could use a better name, but it’s a nice ODM, if a bit immature. I especially like its support for embedded documents, i.e. you don’t have to do anything special, just assign a variable of the specified Mongo-serializeable type (Document or otherwise) to a field, and it Just Works. It also supports Arrays and Hashes that can take any heterogeneous collection of types.

It’s also better designed under the hood than Mongoid or MongoMapper, taking full advantage of Ruby conventions to be easily hackable. MongoODM is definitely the best candidate for Perfect ODM I’ve yet seen.

The Perfect ODM

Here’s what I really in my perfect Mongo ODM:

Plays Well with Rails

Like it or not, the ActiveRecord API is the standard convention for performing DB operations. And to the extent that SQL and MongoDB are conceptually similar, they should maintain the same API. This makes it easier to integrate with other software that may assume AR conventions, but more importantly, it keeps me from having to learn and remember a whole new set of only-slightly-different APIs.

Duck typing and Other Ruby-isms

This is one big feature that ActiveRecord does not (and cannot) have, but which Mongo gives us almost for free — dynamic typing, just like native Ruby. Mongoid supports this for polymorphism, but MongoODM also supports dynamic types in Hashes and Arrays, and it was this fact that original attracted me to it. I have no problem with declaring document fields, but why should I have to specify the type? For that matter, why should I be constrained to a static type?

Schema DSL

Even though I want the freedom to store any value of any type in any field, I know that schemas are still important, both for validation and configuration management. All ODMs provide ActiveRecord-style type-specifiers and validations (Mongoid and MongoODM also use ActiveModel), but I’d like to see document schemata become a top-level object, some superset of JSON Schema, with a friendly and extensible DSL. Something like this:

class Person
    schema do
      property(:name) {
        type   String
        length 1..20
      property(:phone) {
        type Phone
      property(:aliases) {
        type Array.of(String)
      property(:vehicles) {
        type Array.of(Car, Boat, Spaceship)
        default []
      additional_properties false

Once the schema is nestled into object form, there’s a whole bunch of interesting things you can do, in addition to validations:

  • Schema versioning and heterogeneous collections
  • Data migrations and schema management
  • Client-side validations (via JSON Schema)
  • Automatic form generation (think: ActiveScaffold on steroids)
References and Associations

This area gets a bit tricky, partially because of SQL’s wretched legacy of foriegn keys and join tables, but also because the problem is just inherently difficult. Ideally, the database or ODM would provide an equivalent to Ruby’s garbage-collected memory management system, where any document field could be a reference to any other object of any type, and all objects would be automatically destroyed when no longer used.

MongoDB actually comes pretty close with their support for Database References. These allow you to assign to a document field a reference to any document in any collection. I’ve expanded MongoODM with a transparent Reference proxy, and assigning a reference to a field is as simple as calling .reference (or .ref) on a document. I’ve been looking at adding something similar for GridFS attachments, but with a reference count to allow easy sharing of large binary objects between documents.

The Future — No ODM?

This post is mostly just a dump of ideas I’ve had while working to expand MongoODM. But I find myself working more and more in Javascript, these days, and taking advantage of things like jQuery and Backbone to build rich client applications in the browser. In this situation, which I think will become more common, I don’t need so much ODM support in Ruby/Rails, and more-so in Javascript. So now I’m contemplating a MongoDB interface in JavaScript, passing through some sort of Rack proxy to perform access control. I’ll let you know how it turns out …

comments | Tags: mongodb

Back from the Dead

Posted by code_monkey_steve on Mar 19, 2011 Mar 19

Greetings, everyone! Welcome to my new-and-improved blog.

I’ve decided to merge my coding blog (“One-Banana Problem”), which has gone woefully under-updated, with my website (“”), which is gone woefully under-used, and you’re now looking at the result. If you’re thinking it looks a lot like One-Banana Problem …

  1. You actually read my blog? Wow thanks, you’re awesome, that almost doubles my audience!
  2. It looks the same because it’s a port of the original content and style from OBP to a new platform.

Why a new platform? I’m glad you asked, therein lies the story …

The Story

It all started a few months back, when I went to compose a long-overdue OBP post, and discovered that Mephisto wasn’t letting me login. How rude. A quick Google not only failed to provide a solution to the problem, but indicated that Mephisto was no longer maintained or supported. The consensus appeared to be to migrate to a combination of Jekyll, a static-site generator, and the Disqus commenting system. Over the months since, I’ve followed the same path, deploying the new blog on Heroku, my preferred hosting service. Porting the content was fairly easy, but porting the theme not so much.


The best I can say about Jekyll is that it works well enough to get things running again. At first, I was considering using it for some static brochure sites for friends and family, but after getting it working I’ve decided it’s not good for me for a few reasons:

  • No HAML support. Although there are lots of hacks and extensions that claim to fix this, I could never get any of them to work.
  • Heroku provides Varnish to automatically cache pages, so generating static HTML content doesn’t give any significant speed improvement.
  • I do have to check-in all that static content to Git, which just needlessly bloats the Heroku slug.
  • Heroku provides a Rack interface, which means I still need to use a (tiny) Sinatra app to serve that static content.

While I can appreciate the idea of storing the content in the blog code itself, with metadata in a YAML header block and the copy in Textile, I think I’ll stick to Sinatra for my static sites. I’m already working on a CMS-ish project that will probably replace Jekyll as soon as it’s done enough.

Moving Forward

I originally started One-Banana Problem in 2006, after getting laid-off from a failing startup. I wanted to make the switch from a C++ developer to a Ruby/Rails guy, and I thought a blog would help not only to share my hard-won knowledge, but also to market myself to the Rails community in hopes of finding a good job. To that end, I tried to keep the tone professional and the content mostly related to Ruby and Rails.

But here we are, five years later, and now I’m living living the dream of a full-time Ruby developer (woo-hoo!). However, having achieved that goal, I find myself with less motivation for blogging, and more importantly, with less time.

To counter this trend I’ve decided that, as part of The Great Blog Renaming, that I would expand the scope from a mostly coding-centric blog, to including hacking of all kinds. I am a geek, after all, and to my brain all problems have technological solutions. I have some interesting ideas for things like secure voting, digital currency, and even improvements to the democratic process (which hasn’t changed significantly in centuries), and I’ll try to find the time to comment on these sorts of political and social issues more freely in the future.

I’ve also come to the conclusion that trying to keep things “professional” is boring and pointless. If you can’t be open an honest bastard with the whole Internet, viewable by all and archive forever, then why bother blogging?

comments | Tags: blog jekyll heroku

Take my money, please!

Posted by code_monkey_steve on Oct 11, 2010 Oct 11

One of the downsides to being a good web developer is that it makes it really hard to ignore bad web developers. Ever since I started building commercial websites with an emphasis on usability, I can’t help but notice when other sites get it completely wrong. Case in point: credit cards. Just about every commercial site accepts credit cards, and since that is arguably the only feature that a for-profit site really needs, I would expect a little more thought would be put into it. But instead, my online shopping experience is often stymied by developers who are apparently either too lazy or too stupid to make it easy for me to give them my money. Here are a few of the more annoying mis-features I’ve run across:

Card number

  • Wrong: “enter card number without spaces or punctuation”
  • Right: strip invalid characters

Any time you ask a customer to sacrifice their convenience for the sake of your app, things have gone horribly wrong. But especially in this case, where stripping unwanted characters is such a trivial matter, I can’t understand why any self-respecting developer would make such a blunder. Every modern web language – including Ruby, Javascript, and even PHP – supports regular expression substitution. All you have to do is:

{% highlight ruby }
number.gsub!( /[^\d]/, "" )
endhighlight %}

Card expiration date

  • Wrong: “January”, “February”, “March” etc.
  • Right: 01, 02, 03, etc.

This is another no-brainer: the expiration date printed on my card is 03/14 (happy Pi month!), but some sites only give a list of months by name, forcing me to do the conversion in my head. Admittedly, the math is trivial, but why make customers do more work then they have to, especially when they are trying to give you their money. It’s no more difficult to populate a select element with numbers instead of words (in some ways, it’s actually easier), and any decent web framework should provide a function to do this for you; use it! In Rails, it’s just:

{% highlight ruby }
select_month( …, :add_month_numbers => true )
endhighlight %}

Card type

  • Wrong: “select card type”
  • Right: determine card type from card number

This one involves slightly more effort, but since we’re trying to make it as easy as possible for people to give us their money, it’s totally worth it. The crucial piece of information here is the fact that the type of the credit card can be determined from the card number itself, using the same ubiquitous regular expressions we used above. Here’s a mapping of card numbers to (some of the) card types:

{% highlight ruby }
/^4/: “Visa”,
/^5[1-5]/: “Mastercard”,
/^347/: “American Express”,
/^6011/: “Discover”,
endhighlight %}


Put a little extra effort into designing the payment section of your site, you want to make it as easy as possible for your customers to give you their money.

comments | Tags: design rant ui

Autotest and Ruby 1.9.2

Posted by code_monkey_steve on Sep 3, 2010 Sep 3

There’s a bug in autotest that prevents it from properly finding a project’s autotest discover file under Ruby 1.9.2. Until an appropriate fix is made, you can work around it on the command line like so:

{% highlight sh }
$ RUBYLIB=‘.’ bundle exec autotest
endhighlight %}

comments | Tags: ruby test