I also have an Logitech MX Revolution that I used to use. It was a good mouse until I changed my time machine backups to use a server instead of a USB Drive. The change meant that the backups now happen over my Wifi connection. Right after the change I noticed was that my mouse stopped working every time the backup kicked on. The mouse uses the same 2.4Ghz spectrum as the 802.11 card and the flood of data from the backup would kill the mouse connection. I called their tech support on this one too to see if there was a solution. Their idea? Get a different mouse and plug it in during the backup then plug the Logitech mouse back in. (Every hour during the Time Machine backup). I bought an Apple Magic mouse instead and then replaced my Logitech keyboard with one of the latest from Apple.

I'm done buying Logitech.

Disguise makes it simple to swap out the views used by your rails application either by selecting a theme using an admin UI or by changing out the theme based on the current url. For most apps the feature is probably not relevant, but if you are building a piece of software like a blog or social network then letting your users customize the look of the site is crucial to adoption.

Find the install instructions on the project's github account.

While setting a given theme works fine and doesn't incur much of a performance hit beyond method call, swapping out the theme based on the current domain can incur a performance hit since it reloads the localization strings. Here's the bit of code that swaps the views:

 
      def setup_theme
        return if !Disguise::Config.themes_enabled
        return if current_theme.blank? || current_theme.name.blank?
        theme_view_path = File.join(Disguise::Config.theme_full_base_path, current_theme.name, 'views')
        if self.view_paths.first == theme_view_path
          return
        else
          return if !theme_exists(theme_view_path)
          clean_theme_view_path
          self.prepend_view_path(theme_view_path)
          clean_theme_locale
          set_theme_locale
          I18n.reload!
        end
      end
 

I'm hoping to find a way to improve performance when changing themes, but for now be aware that changing themes based on domains is a work in progress and shouldn't be used in a production environment.

• acts-as-taggable-on
• acts_as_taggable_on_steroids
• acts_as_taggable

I think the original acts as taggable is now defunct. The other libraries are derivatives of that library. In using tags on various sites the problem I always seem to run across is how to deal with tag case. For example, to some blue is the same as Blue. However, is god the same as God? It depends on who you ask. It seems that acts-as-taggable-on handles the case problem properly. I noticed that if I add the tag 'blue' to an object I cannot add another tag called 'Blue'. However, if I delete 'blue' and then add the tag 'Blue' it works as expected and the upper case tag becomes associated with the object.

acts_as_taggable_on_steroids doesn't handle the case problem especially well and I frequently run across this error:

  ActiveRecord::RecordInvalid (Validation failed: Tag has already been taken):

It turns out that that the key difference between the two libraries is in how they setup the tag relationship.

acts-as-taggable-on does this:

 
def save_tags
          (custom_contexts + self.class.tag_types.map(&:to_s)).each do |tag_type|
            next unless instance_variable_get("@#{tag_type.singularize}_list")
            owner = instance_variable_get("@#{tag_type.singularize}_list").owner
            new_tag_names = instance_variable_get("@#{tag_type.singularize}_list") - tags_on(tag_type).map(&:name)
            old_tags = tags_on(tag_type, owner).reject { |tag| instance_variable_get("@#{tag_type.singularize}_list").include?(tag.name) }
 
            transaction do
              base_tags.delete(*old_tags) if old_tags.any?
              new_tag_names.each do |new_tag_name|
                new_tag = Tag.find_or_create_with_like_by_name(new_tag_name)
                Tagging.create(:tag_id => new_tag.id, :context => tag_type,
                               :taggable => self, :tagger => owner)
              end
            end
          end
 
          true
        end
 

while acts_as_taggable_on_steroids does it this way:

 
        def save_tags
          return unless @tag_list
 
          new_tag_names = @tag_list - tags.map(&:name)
          old_tags = tags.reject { |tag| @tag_list.include?(tag.name) }
 
          self.class.transaction do
            if old_tags.any?
              taggings.find(:all, :conditions => ["tag_id IN (?)", old_tags.map(&:id)]).each(&:destroy)
              taggings.reset
            end
 
            new_tag_names.each do |new_tag_name|
              tags << Tag.find_or_create_with_like_by_name(new_tag_name)
            end
          end
 
          true
        end
 

The key difference is in this:

 
Tagging.create(:tag_id => new_tag.id, :context => tag_type,
                               :taggable => self, :tagger => owner)
 

versus:

 
tags << Tag.find_or_create_with_like_by_name(new_tag_name)
 

The first will return false and on go on it's way. The second throws an exception. Which is the right way of dealing with the problem? I guess it depends. I don't feel like either is a great solution. Both libraries assume that 'blue' == 'Blue'. If that assumption is correct then a different bit of code should change in each library. Tag.rb should lower case the names in the comparison:

 
  def ==(object)
    super || (object.is_a?(Tag) && name == object.name)
  end
 

changes to:

 
  def ==(object)
    super || (object.is_a?(Tag) && name.downcase == object.name.downcase)
  end
 

However, if you want to leave each tag as the user specified rather than change the case then a different line needs to be changed in tag.rb

 
  # LIKE is used for cross-database case-insensitivity
  def self.find_or_create_with_like_by_name(name)
    find(:first, :conditions => ["name LIKE ?", name]) || create(:name => name)
  end
 

will need to change to

 
  # = is used for to ensure tags are case sensitive
  def self.find_or_create_with_like_by_name(name)
    find(:first, :conditions => ["name =", name]) || create(:name => name)
  end
 

Of course the second change will result in the duplication of tags in your site - you will end up with tags 'Blue' and 'blue', but that is the intent. Your searches might need to be adjusted accordingly.

undefined method `assert_no_difference'

and

undefined method `assert_difference'

It turns out that I needed to change my base classes from Test::Unit::TestCase to ActiveSupport::TestCase:

 
class UserTest < Test::Unit::TestCase
  # stuff
end
 

changes to:

 
class UserTest < ActiveSupport::TestCase
  # stuff
end
 

Here's what I got for Christmas this year:

A chance to play Santa Claus with the most beautiful Misses Claus in the world until 3 am. I'm glad she wraps the presents and puts everything together while I eat the cookies.

A few (short) moments of watching my children excitedly rip through presents during the few years that they still feel the magic of Christmas.

A few days away from my computer and from code. I love my job but sometimes I forget what it's like to be a normal human being.

One Lego train from a beautiful Misses Claus and an hour to put it together with my brother. I'm getting old but it is nice to remember what Christmas was like when you were ten.

2 loaves of my grandmother's bread.

A couple of days with family.

A couple of days to go home and recover from family.

An awesome Christmas card from Zach Poulter.

A couple of hours with friends that I haven't seen in many years.

In Rails the way to work with OAuth is the OAuth gem and the OAuth-Plugin gem which take almost all the pain out of implementing an OAuth solution. A big thanks to Pelle Braendgaard for a great library.

I won't go into all the details on how to implement the gems in your project. Instead checkout the README for each gem and the articles on Pelle's blog: Developing OAuth clients in Ruby, Major update to Ruby on Rails OAuth Plugin, and Consuming OAuth intelligently in Rails.

Once you have an OAuth solution in place the next step is to do something with the tokens. I figured that it was my problem to figure out how to call the various service's apis using the OAuth token. I spent a fair amount of time trying to figure out how to send the correct headers, sign the values, etc. I turns out that the OAuth gem takes care of this for you so to save you hours of time, once you have your application setup and configured you can do stuff like this:

Google Contacts API:

 
limit = 10000
user.google.get("http://www.google.com/m8/feeds/contacts/default/full?max-results=#{limit}")
 

The gem will handle signing the request and adding the needed values to the header.

Pretty cool.

<p>Some String</p>

to

<%= 'Some String' %>

I didn't really feel like having to change my string into that format was going to help my productivity so I abandoned Ruby Mine and instead started looking at the Rails I18n Textmate bundle from Sven Fuchs. Look inside the tools directory.

Alas, I couldn't get that tool to work either. Instead each time I hit command+shift+e I and add the translation it would insert this into my file:

/Library/Ruby/Gems/1.8/gems/i18n-0.3.2/lib/i18n/backend/base.rb:238:in /bin/bash: -c: line 0: unexpected EOF while looking for matching `''
/bin/bash: -c: line 2: syntax error: unexpected end of fileload_yml'
  from /Library/Ruby/Gems/1.8/gems/i18n-0.3.2/lib/i18n/backend/base.rb:225:in /bin/bash: -c: line 0: unexpected EOF while looking for matching `''
/bin/bash: -c: line 2: syntax error: unexpected end of fileload_file'
  from /Library/Ruby/Gems/1.8/gems/i18n-0.3.2/lib/i18n/backend/base.rb:17:in /bin/bash: -c: line 0: unexpected EOF while looking for matching `''
/bin/bash: -c: line 2: syntax error: unexpected end of fileeach'
  from /Library/Ruby/Gems/1.8/gems/i18n-0.3.2/lib/i18n/backend/base.rb:17:in /bin/bash: -c: line 0: unexpected EOF while looking for matching `''
/bin/bash: -c: line 2: syntax error: unexpected end of fileinit_translations'
  from /Library/Ruby/Gems/1.8/gems/i18n-0.3.2/lib/i18n/backend/base.rb:107:in /bin/bash: -c: line 0: unexpected EOF while looking for matching `''
/bin/bash: -c: line 2: syntax error: unexpected end of filetranslate'
  from /Library/Ruby/Gems/1.8/gems/i18n-0.3.2/lib/i18n.rb:208:in /bin/bash: -c: line 0: unexpected EOF while looking for matching `''
/bin/bash: -c: line 2: syntax error: unexpected end of file[]'
  from /Users/jbasdf/Library/Application Support/TextMate/Pristine Copy/Bundles/Rails I18n.tmbundle/Support/lib/extensions.rb:121:in /bin/bash: -c: line 0: unexpected EOF while looking for matching `''
/bin/bash: -c: line 2: syntax error: unexpected end of fileadd_translation'
  from /tmp/temp_textmate.CUUYuC:4

That sucked until I realized that by default the bundle assumes the locale file is in 'config/locales/en.yml'. That is the default for most projects and so most of the time you're fine. However, in my gems I put the locales at the root. Since the bundle couldn't find the file it barfed. Lucky for me you can change this value by going to Bundles -> Rails I18n -> Edit Settings

I changed my settings to look like this so that I could easily change back and forth between locations.

CONFIG = {}
CONFIG[:locale] = :en

#CONFIG[:locale_file_path] = "#{ENV['TM_PROJECT_DIRECTORY']}/config/locales/en.yml"
CONFIG[:locale_file_path] = "#{ENV['TM_PROJECT_DIRECTORY']}/locales/en.yml"

CONFIG[:bundle_preferences_path] = "~/Library/Preferences/com.macromates.textmate.rails_i18n_translation_helper.pstore"
CONFIG[:project_directory] = ENV['TM_PROJECT_DIRECTORY']
CONFIG[:method_style] = :long   # :long => I18n.translate() and translate()
                                # :short => I18n.t() and t()
CONFIG[:log_changes] = false
#CONFIG[:log_file_path] = "#{ENV['TM_PROJECT_DIRECTORY']}/config/locales/en"
CONFIG[:log_file_path] = "#{ENV['TM_PROJECT_DIRECTORY']}/locales/en"

One other tip. Be sure to install the i18n gem. I didn't see it in the readme, but I might have read over it.

 sudo gem install i18n

This is an awesome plugin. It will save me quite a bit of time. I do wish it would support multiple locale directories but I can live with it as is.

On a side note the rails-i18n project is a great piece of code if you do any internationalization work. Check out all the locale files for Rails.