Tag Archives: PriceChirp

ActiveRecord strict mode

I really like ruby and rails, but I find it frustrating as a lone developer.

The main path for Ruby / Rails seems to be very well documented. However, the second I get off the main path, which it seems everyone must do, especially someone who is upgrading an app that started as a rails 2.1.0 application, the documentation is scarce. I find I wind up having to search in source code more often than not to understand what’s going on. And that’s scary.

Case in point, I recently upgraded from rails 3.2 to rails 4.0. They implemented a major change with ActiveRecords that I can find no mention of any where except in the source and change log.

* `mysql` and `mysql2` connections will set `SQL_MODE=STRICT_ALL_TABLES` by
default to avoid silent data loss. This can be disabled by specifying
`strict: false` in your `database.yml`.

This is a good thing. For years i have been silently losing data. Data I don’t care about, but still, since it’s silently loss, I didn’t know.

However, after upgrading the app, fixing all the deprecation warnings, and ensuring all my test passed, I pushed the code to production. Then I started getting errors like:

An ActiveRecord::StatementInvalid occurred in items#search:

Mysql2::Error: Data too long for column ‘name’ at row 1…. (with lots of boring mysql)

Basically, my name field, at 256 characters was not long enough for some data. The error message made it clear what was happening, but I didn’t understand why they would make this type of change, without documenting it in the migration documents. Maybe they could have gone through a deprecation phase where it warned you first, before going from silent to exception?

It wasn’t until after I had fixed my code to either have the proper field lengths, or manually truncate the data myself that I found that a simple “strict: false” in my database.yml file would have returned to the old behavior while I tracked down the problem, or properly checked for it, so I wouldn’t get a server error.

Another more deadly example, one that took me over a month to track down was back in rails 3.1 when they changed the meanings of .dup and .clone.

ActiveRecord::Base#dup and ActiveRecord::Base#clone semantics have changed to closer match normal Ruby dup and clone semantics.
What this really meant to me was, everywhere I was using .clone, I needed to change to .dup. I was having object rot because when It thought I was cloning an item to make a new one, I was changing the original. I needed to .dup it, so I would not copy the id at the time of duplication. Basically, for what I needed, .dup and .clone changed names. This happened silently without warning or being highlighted in the upgrade documentation.

PriceChirp has improved wishlist support

This week I improved the Amazon wishlist support in PriceChirp. One of the cool features of PriceChirp from the beginning has been how easy it is to import an Amazon wishlist into PriceChirp. The only problem with this feature is it was an all or nothing proposition. Now, we have the ability to view our wishlists in PriceChirp and select which items we wish to import. The old feature of importing everything is still thee, but now we have options.

To see this feature in action, log into your PriceChirp account and do a wishlist search. This is done by searching for the email address associated to your Amazon wishlist. Once your wishlists are displayed, you can select “view wishlist” to get a listing of your items. From this page you can easily select which item to import into your personalized tracker.

Have fun!

PriceChirp tracks prices on Internationial Amazon sites

PriceChirp is growing. This week I added support to allow people to track prices and be alerted of changes for all the international Amazon sites. This includes Amazon US, Canada, France, Germany, Japan, and the UK. Just select the location of Amazon you are interested in searching, and use PriceChirp like normal. It was designed to make it easy to manage products from multiple sites at once. I’m hoping this design decision will pay off if in the future I add more vendors to PriceChirp.

Gravatars on Rails

Gravatar is the globally recognized avatar run by the folks who run WordPress.com.

Your Gravatar is an image that follows you from site to site appearing beside your name when you do things like comment or post on a blog. This is done by associating an image to the users email address. Adding Gravatar to PriceChirp seemed like a fun thing to do.

The API is very simple, so adding it to a Ruby on Rails site is easy.

First, add a few lines to your application-helper.rb:

  def gravatar_url_for(email, options = {})
      :gravatar_id => Digest::MD5.hexdigest(email),
      :host => 'www.gravatar.com',
      :protocol => 'http://',
      :only_path => false,
      :skip_relative_url_root => true,
      :controller => '/avatar'

You may also need to add:

require 'digest/md5'

Now you can add the gravatar to your views like this:

  # standard gravatar url
  <%= gravatar_url_for 'user@gmail.com' %>

  # gravatar url with a rating threshold
  <%= gravatar_url_for 'user@gmail.com', { :rating => 'R' } %>

  # show the avatar
  <%= image_tag(gravatar_url_for 'email@gmail.com')%>

  # change the size of the avatar
  <%= image_tag(gravatar_url_for('email@gmail.com', { :size => 30 })) %>

Note: Gravatar is case sensitive on the user’s email address. They will match against an all lower case version of the email address. If you need to allow uppercase characters in your email addresses, you will need to .downcase the email address in the view or helper. I do not have this requirement, so I fix the case in the user.rb model at save time:

  before_save :fix_email_case


  def fix_email_case
    if !self.email.nil?