Today, at Rea we had our fourth Innovation Day. We have learnt a lot over the past year about how to engage the business, the QA’s and Operations. We have made every effort to make Innovation Days not just about developers. So today, Steve and I decided to have a play around with Street View and properties.

Over the past few months, I have become a fair bit familiar with the Google Maps API, specifically there third version. It is a very neat little API and allows me a lot of handles on little things that make playing with Google Maps and Javascript such fun. But until now, I had not discovered so many things missing between the V2 and V3 versions.

And it is not just functionality. The very way Street View motions down a street is so much more grainier and jerky in V3. Was it solely because they switched from flash to JS? If so, why? I think it may have been to accomodate iPhone’s lack of flash, but why a simple UserAgent check did not suffice, I do not know!

Things that I found missing from V3 that were in V2

  • panTo() method is missing from StreetView
  • Cannot seem to give a pancake to the cursor
  • Cannot put custom controls on StreetView

Out of those three, the most annoying is the first one, since that ensures that when you walk down the street in Street View, it zooms in rather than pans. And not only that, the movement between the two positions on Street View is a pulse, rather than a flow, negating what used to be a very cool warp effect. Also, these effects are still visible on their main site.

Do not get me wrong, V3 is a great; I am just wondering whether V3 should be called V1.9?

I needed a table to store some text and its index in a list at which the text occured. So as part of my migration, I decided to make sure the schema did not add to my legacy database structure, but relationally associate it. So part of the schema involved specifying the ‘index’ column, which I defined as

CREATE TABLE `meow` (
`index` tinyint(3) unsigned NOT NULL DEFAULT 1,
......
) ENGINE=InnoDB

Now I thought I was safe as I had not used something like int(11), something unfortunately I have come across previously *shudder*. Off I go, happily plodding along with my model and code, till I actually needed to implement the association.

I wrote a simple spec test for it:

Cat.meows = Meow.new(:index => 2)
cat_meows = Cat.meows
cat_meows.should have(1).meow
cat_meows.first.should be_a_kind_of(Meow)

And then inside my model Cat, I had:

has_many :meows, :foreign_key => 'cat_id', :class_name => 'Meow'

Seems simple, doesn’t it! AHA! You fool! You thought you could do this and life would be easy and wonderful and the world would make sense!
Such naivete! Adorable!

When I ran the spec and started getting errors which interpreted the `index` as boolean, I was intrigued. Looking at the API, I find this:

By default, the MysqlAdapter will consider all columns of type tinyint(1) as boolean. If you wish to disable this emulation (which was the default behavior in versions 0.13.1 and earlier) you can add the following line to your application.rb file:

ActiveRecord::ConnectionAdapters::MysqlAdapter.emulate_booleans = false

Now while the fix seems simple enough, I would like to point out that this is a very neat and elegant solution for a problem that simply should not have existed! Had Rails made the assumption about a `bit(1)` field, then I would have been fine. Had they made the assumption about `tinyint(1)`, even then I would not have complained. Even the MySQL docs list `tinyint(1)` only as a boolean. Anything else, is simply not a boolean. Rails however, treats all declarations of `tinyint` as booleans. Which is annoying! Not hard to fix, not complicated, but annoying.

Why couldn’t they make that assumption about the `bit` field ?