Getting Rmagick to work again

Although we are running Lion on all our dev machines, we had an issue where a project using RMagick suddenly stopped working in dev mode, giving the error

Incompatible library version: RMagick2.bundle requires version 10.0.0 or later, but libltdl.7.dylib provides version 9.0.0

Managed to fix it following these steps:

Ran this in terminal:

gem uninstall rmagick
brew uninstall imagemagick
brew install –fresh imagemagick
gem install rmagick

After this, RMagick worked flawlessly again!

Still half-baked for SMS texting: Toktumi Line2

I really WANT to like Toktumi’s Line2 product. It’s got a reasonably easy setup, and the idea is killer.

But the value proposition, that it somehow acts like a second line for voice+texting, available from your phone or computer, is undermined by what is IMO truly shoddy SMS support. To whit:

Mere Annoyances:

  • No way to receive incoming SMS messages on your softphone.
  • No way to receive incoming SMS messages to your email.
  • No way to send SMS messages from your softphone.

**A Deal-killer: **

Throwing away parts of incoming SMS messages is a Bad Thing. We discovered this Line2 bug today:

If you send the following 150-character SMS text to a Toktumi Line2 number:

Your phone has JOINed 5 groups, including: Name 1 (650-555-1111) / Name Two (650-555-2222) / Name Three(509-555-3333) / Name four(415-555-4444) / Done<br></br>

Your line2 app throws away the last part, you see only:

Your phone has JOINed 5 groups, including: Name 1 (650-555-1111) / Name Two (650-555-2222) / Name Three(509-555-3333) / Name <del>four(415-555-4444) / Done</del><br></br>

At least, that’s the case for the iPad app.

A subtle problem with using update_attributes in Rails migrations

It’s fairly common to create a Rails migration that adds a column, then stuffs data into that column for legacy data, for example the addition of a guid field.

However, using update_attributes can quietly bungle your database by skipping certain records if you have added any new validations which did not apply to legacy data in the database.

For example, suppose you’ve had a Widgets table for a long time, and it has lots of existing Widgets in it. Originally, the name of a Widget could be any length, but a few months ago you added a validation so a Widget name should be at least 10 characters going forward.

Now you want to add an 8 character guid to Widgets. If you run the following migration using update_attributes (instead of a save(:validate => false) as I show here) your migration will pass, so you’ll think everything is fine, BUT any widgets with a too-short name will not receive their guid because the valiation fails.

Obviously there ARE times when you want validations when adding data, but probably not in a case like this where you are adding a new field with a use that is independent of any prior data values.

class AddGuidToWidgets < ActiveRecord::Migration
  def self.up
    add_column :widgets, :public_guid, :string

      # MUST reset to ensure new column info used
    Widget.find(:all).each do |w|
      g = (0...8).map { 65.+(rand(25)).chr}.join
      while !FinderItem.find_by_public_guid(g).nil?
        g = (0...8).map { 65.+(rand(25)).chr}.join
        # can NOT use update_attributes because might have validation errors
        # due to new validations added on certain other fields
      w.public_guid = g :validate => false )
      #DONT USE: w.update_attributes :public_guid => g