My new Roomba bumps into dark furniture

I wasn't sure what blog to post this to, but I thought it worthy of being posted.  I just recently got a Roomba for my condo.  Having two cats with mostly hardwood floors creates a lot of "cat hair tumbleweed" as I call it.  Those of you who have cats with hardwood floor know what I mean.  I figured the Roomba would be an ideal solution for keeping my floors clean, and since I live my condo is one level, the Roomba will be able to clean everything.  

The Roomba works better than what I was even expecting, except for one pretty serious problem.  The Roomba has sensors which "see" objects in front of it, so that way it will slow down before bumping in to them.  This sensor works great for my walls, but it doesn't seem to see most of my furniture and bumps in to it at full speed.  It seems like it doesn't see anything that's dark brown or black, which makes sense since it uses infrared to see.  After the first time I let Roomba run free, I noticed a nick in the leg of my entertainment center.  I also noticed a little wood splinter by my dresser that I can't figure out where it came from.  Both of these were definitely from the Roomba, when it hits the furniture it's going fast enough to do some damage.   

After reading a few web sites, I found a solution for this.  Buy rubber sponge tape, and attach it all the way around the front bumper of the Roomba.  That way, the rubber sponge will absorb the impact when the Roomba hits stuff at full speed.  So far this has worked great!  Here is a link to the roll of 1/4 inch thick, 3/4 inch wide, 10 foot long rubber tape that I bought from Hardware and Tools:

http://www.hardwareandtools.com/invt/7949985

Make sure when you attach the rubber tape that you attach it at the bottom of the bumper, it shouldn't cover the sensors.  As I learned the hard way, 3/8" is too thick, the Roomba won't be able to dock properly so be sure to get 1/4" thickness.  Also the 3/4" width is just about right, any wider and it will cover the sensors. 

The edges of the tape seem to start peeling off after lots of use.  I think I'm going to try to put some two sided tape on the ends of the section that I cut off so it wont' peel off so easily.

Applying individual timestamp migrations

I posted in my previous entry (Timestamp based migrations in Rails 2.1) about the new UTC timestamp based migrations in Rails 2.1. After working with them a little more, I found how to apply or remove individual migrations. Simply run rake db:migrate:up VERSION=YYYYMMDDHHMMSS to apply a single specific migration, or rake db:migrate:down VERSION=YYYYMMDDHHMMSS to remove a specific migration.

However, I found a bug with db:migrate:down as noted at http://rails.lighthouseapp.com/projects/8994/tickets/369-db-migrate-down-does-not-remove-migration-version-from-schema_migrations-table. When you run this, the self.down function of the migration is called and the database is changed. However, the entry in schema_migrations for this migration is not removed. So if you run rake db:migrate later, this migration will not be applied because Rails thinks that the migration has already been applied. My work around for this is to manually delete the row in schema_migrations after I run db:migrate:down.

Timestamp based migrations in Rails 2.1

One really cool feature added to Rails 2.1 is UTC timestamp based migrations. Now, when you generate a new migration, instead of the migration number being sequential, it's a UTC timestamp. That way if you're working on different branches of code, you don't need to coordinate between the braches who gets what version number.

But the best part of this is how the migrations are tracked. Instead of just keeping a current database schema number like before, Rails keeps track of each migration that has been run. Then when you run rake db:migrate, Rails only applies the migrations that haven't been run, they don't have to be in order.

As an example, say I added a migration two days ago called add_new_column with script/generate migration. 20080610012942_add_new_column.rb gets generated. My co-worker John is working off of another code branch, and yesterday he added a new migration called change_accounts. 20080610225643_change_accounts.rb gets generated. Then today I add a new migration called delete_state. 20080612020139_delete_state.rb gets generated. I have two migrations, and John only has his one. When I run rake db:migrate, my two migrations get applied, and when John runs it his one migration gets applied. When we sync our code branches, we get each others migration files. Even though John's migration was created AFTER the first one that I created, when he runs migrate, both of my migrations will get added, and his migration that was already added will not get run again. And when I run migrate, only John's migration will get added, even though it was generated before the last migration that I ran.

The way Rails does this is that the first time you run a migration with Rails 2.1, a new table gets created called schema_migrations. An entry is added to this table for each migration that gets run. The old schema_info table is deleted. That way any time you run a migration, it checks each migration file against the database to see if it's been applied to your database yet.

This feature is already proving very useful for me. I no longer have to have migrations completely syncronized between myself and the other developer working on my project. We each work on our own branch, and we merge our migrations together when we're ready to merge all of our code.

A good Railscast video showing this is up at http://railscasts.com/episodes/107.

New vacation pics on Flickr

Check out my Flickr page at http://www.flickr.com/photos/valenshek/. I just posted pictures, mapped ofcourse, from my recent vacation to Spain!

Dynamically changing img src doesn't always show new image with Internet Explorer 6

When you dynamically change the source of an image with Javascript, Internet Explorer 7 and Firefox will display the new image fine. But sometimes, I believe when the change was triggered from an event, the image won't display in Internet Explorer 6 after the change. A blank area will appear where the image should be (if you specify a width and a height for the image), and if you right click on the area and click Show Picture, the image will display. I really have no clue why IE6 behaves this way. I found a posting at http://blogmatrix.blogmatrix.com/:entry:blogmatrix-2006-10-15-0000/ that lists two solutions. A third solution, described in Comment #1, is the easiest solution though. Simply return false in the event that triggers the change. Example:

Say you have an onClick event in a link to change a different image on the page. Your code should be:

<a href="javascript:void(0)" onClick="changeImage(); return false;">Change Image</a>

The return false will make the image always display in IE6.

How to disable the image toolbar for images in Internet Explorer 6

By default, when viewing an image on a page with Internet Explorer 6, a little toolbar will appear in the upper left corner when you hold your mouse over the image for a few seconds. This toolbar really gets in the way if you want users viewing your page to do things with the image, like capture mouse clicks, drag the image, etc. Thanks to http://www.thesitewizard.com/webdesign/imagetoolbar.shtml, I found two ways to disable this. To disable the image for a whole page, add a meta tag to your header:
<meta http-equiv="imagetoolbar" content="no" />
Or to disable this on a per image basis, add:
galleryimg="no"
to the img tag.

Assigning custom data types to new columns during migration, part 2

In my previous article, Assigning custom data types to new columns during migrations, I showed how you can create columns with custom data types during a database migration. Simply specify :"data type", instead of :integer, :string, :binary, etc. An example would be :"smallint", since there is no direct way to create a MySQL smallint during a Rails migration.

However, I recently found that this doesn't always work. It works fine if you are creating a new table in your migration. But this does NOT work if you are adding or modifying a column in an already existing table, you get the error:
rake aborted!
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]

Has anyone else run in to this problem? It's annoying to have to construct SQL statements to add columns, after all that's what migrations are supposed to get rid of.