Monthly Archives: September 2009

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.

Upgradeing from Drupal 5.20 to 6.14

Today I upgraded from Drupal 5.20 to 6.14. I’ve been dreading the upgrade to the Drupal 6.x series for almost 9 months because I had no idea how hard it would be or what I would lose in the migration.

The instructions on the Drupal site are fine, but they didn’t prepare me for what would be different.

  • Back everything up
  • Deselect all non-core modules
  • Select a core template
  • Move the old Drupal version out of the way
  • Install the new version of Drupal
  • Copy your /files and /sites directory from the old installation to the new installation
  • Copy other misc files like your robots.txt to the new installation
  • Fix the /sites/default/settings.php
  • Run the update script — Pray

If all has gone well, you have an upgraded core. Now for the tedious part. Start upgrading each module one at a time, running your update script between each one.

After upgrading every module that had a Drupal 6.x version, here is what I lost:

  • My site template
  • All my views
  • Most of my custom menu items (Links to anything that did not upgrade cleanly was lost — ie.. links to my views, links to my galleries, etc…)

Differences of note:

  • Drupal 6 is much faster
  • HTML comments started appearing in my stories. I had to install the htmlcomment modules to get my comments to hide again
  • The views configuration menu is much improved
  • Status Report is now part of core
  • Gallery module is much improved
  • The wysiwyg module is more flexible than the old tinymce module

In the end, I am very happy with the upgrade. I still have work as I will need to find / hack a new template sometime so I don’t look like a default Drupal install.

Number to Currency Outside Rails

I created a module I am also using both in rails and for some batch processing outside of rails. In order to ensure my data was formatted the same with both environments, I needed to figure out how to get access to the active_view helper number_to_currency outside of rails. Here is how I did it: 

require 'rubygems'
require 'action_view'

def number_to_currency(number, options = {})
  ActionView::Base.new.number_to_currency(number, options)
end

Rescuing from open-uri timeouts

Found an issue with open-uri because today Amazon’s API is wonky. The same issue will occur when accessing any remote data via open-uri (like a RSS feed) if the data source is going to slow. The relevant part of my ruby code looks like: 

  begin
    doc = Nokogiri(open(api_url))
  rescue
    print "Connection failed: #{$!}\n"
    next
  end

For some reason, the rescue does not catch a timeout error. 

/usr/lib64/ruby/1.8/timeout.rb:54:in `rbuf_fill': execution expired (Timeout::Error)

Explicitly catching the timeout error fixes the code. 

  begin
    doc = Nokogiri(open(api_url))
  rescue Timeout::Error
    print "Timeout::Error: #{$!}\n"
    next
  rescue
    print "Connection failed: #{$!}\n"
    next
  end

Good to know, as you never know when your remote data provider will be slow.