The code being tested related to users being emailed upon registration on the site.

def User < ActiveRecord::Base
  after_create :send_welcome_email
 
  def send_welcome_email
    UserMailer.welcome(email).deliver
  end
  handle_asynchronously :send_welcome_email
end

The test’s original implementation compared the number of delayed jobs being created to the number of expected delayed job entries. The unit test code essentially looked like this.

class UserTest < Test::Unit::TestCase
  context "when creating a new user" do
    setup do
      @user = Factory.create(:user)
    end
 
    should "send new user a welcome email" do
      assert_equal 1, Delayed::Job.count
    end
  end
end

Since the email is sent via a delayed job, its implementation for success is to compare the number of delayed jobs to the number of expected delayed jobs (in this case, just one). Everything works, and the test passes successfully. That’s great for this particular instance.

But what happens if we change the User model’s code to the following?

def User < ActiveRecord::Base
  after_create :send_notification_to_referring_user
 
  def send_notification_to_referring_user
    UserMailer.referral(referrer.email).deliver if referrer
  end
  handle_asynchronously :send_notification_to_referring_user
end

When we run our unit test again, it still passes. However, the unit test is supposed to be ensuring the user receives a welcome email, given the line of code reading should "send new user a welcome email". Clearly given the updated model code, that is no longer happening.

An improvement for our test would be to check that the correct method is being called via Delayed Job.

assert_delayed_method :send_notifications

There is no assert_delayed_method supplied by default, but that doesn’t mean we can’t create one. Within test/test_helper.rb, let’s go ahead and add the following code.

def assert_delayed_method(method_name, msg = nil)
  method_name = method_name.to_sym
  full_message = build_message(msg, "Delayed Job should exist for ?.", method_name)
 
  assert_block(full_message) do
    match = false
    Delayed::Job.find_each do |job|
      match = true and break if job.payload_object.method == method_name
    end
    match
  end
end

Now, let’s change our unit test to take advantage of this new assertion method.

class UserTest < Test::Unit::TestCase
  context "when creating a new user" do
    setup do
      @user = Factory.create(:user)
    end
 
    should "send new user a welcome email" do
      assert_delayed_method :send_notification_to_referring_user
    end
  end
end

The unit test still passes, and we can rest assured that if a different delayed job is created in the future, our test will fail.

My first approach was not at all elegant, although it achieved the goal. Depending on whether this is a new or existing record, I conditionally display the input differently.

<%= form.inputs do %>
    <% if form.object.new_record? -%>
        <%= form.input :image, :required => true, :hint => 'Maximum size of 3MB. JPG, GIF, PNG.' %>
    <% else -%>
        <li class="file input required" id="profile_image_input">
            <label class="label" for="profile_image">Image</label>
            <%= image_tag form.object.image.url(:thumb), :class => 'attachment' %>
            <%= form.file_field :image %>
            <p class="inline-hints">Maximum size of 3MB. JPG, GIF, PNG.</p>
        </li>
    <% end -%>
<% end %>

There are a few problems with this. For one, I have repeated code between the two conditions. For example, the “hint” string is repeated, as well as the required setting. If I ever change the value in one spot, I have to remember to change it in the other. The other bigger problem is that my code is based upon the internal rendering performed by Formtastic. That means that if I ever update Formtastic, I need to make sure my custom HTML is updated to match as well.

Being somewhat of a perfectionist (well, at least as close as I can get) when it comes to my code, I wanted to address these issues right away rather than putting it on a “to do” list that would always take second place to other more important tasks.

After doing a bit of digging, I was reminded about Formtastic’s ability to utilize custom inputs. This can be seen on the “Creating New Inputs Based on Existing Ones” section of Formtastic’s README. In only 5-10 minutes of coding, I was able to completely refactor my original approach. First, I created my custom input class.

class AttachmentInput < Formtastic::Inputs::FileInput
  def image_html_options
    {:class => 'attachment'}.merge(options[:image_html] || {})
  end
 
  def to_html
    input_wrapping do
      label_html <<
      image_html <<
      builder.file_field(method, input_html_options)
    end
  end
 
protected
 
  def image_html
    return "".html_safe if builder.object.new_record?
 
    url = case options[:image]
    when Symbol
      builder.object.send(options[:image])
    when Proc
      options[:image].call(builder.object)
    else
      options[:image].to_s
    end
 
    builder.template.image_tag(url, image_html_options).html_safe
  end
end

Now, with my input class created, I could simply specify the type of input as :attachment instead of using the default of :file.

<%= form.input :image, :as => :attachment,
                       :required => true,
                       :hint => 'Maximum size of 3MB. JPG, GIF, PNG.',
                       :image => proc { |o| o.image.url(:thumb) } %>

Note the additional :image option. In order to know what URL to render for the image, this option must be supplied. In the example above, I utilized a Proc object to generate the URL string. The Proc receives the object that the form is currently working with. In this case, it is the instance of my model.

Alternatively, I set up my AttachmentInput class to accept a Symbol representing the name of a method on the object to call, as well as any other object type that is simply cast to a String. Examples of these implementations can be seen below.

<%= form.input :image, :as => :attachment, :image => :to_s %>
<%= form.input :image, :as => :attachment, :image => "profile.png" %>

Formtastic inputs also accepts custom HTML options via :input_html, :wrapper_html, and :button_html Hash options depending on what is currently being generated. Similarly, a new :image_html Hash option can be provided when building an AttachmentInput.

<%= form.input :image, :as => :attachment,
                       :image => :to_s,
                       :image_html => {:class => 'thumbnail', :alt => 'Profile Photo'} %>

All that’s left now is to style the rendered HTML. Nothing fancy here.

form img.attachment {
    float: left;
    padding: 4px;
    margin: 0 10px 0 0;
    border: 1px solid #ccc;
    background-color: #fff;
}

And there you have it! With just a few extra minutes of research and coding, I was able to clean up my code significantly.

Imagine you have an application that needs to maintain a list of employees. You’ll probably start out with a few columns including first name, last name, address, city, state, phone number, social security number, salary, and so on. However, as you start to work on defining the structure, you might find that certain roles need to track pieces of information that other roles don’t. For example, a manager might have a yearly bonus. Similarly, a programmer might have a list of languages they’re familiar with.

With the Multiple Table Inheritance gem, you’ll be able to implement this concept easily. All that is required is some special treatment with your migrations, and a method call in each ActiveRecord model that extends or inherits from another model. For example:

class Employee < ActiveRecord::Base
  acts_as_superclass
  attr_accessible :first_name, :last_name
  validates :first_name, :presence => true
  validates :last_name, :presence => true
  validates :salary, :presence => true, :numericality => { :min => 0 }
end
 
class Programmer < ActiveRecord::Base
  inherits_from :employee
  has_many :known_languages
  has_many :languages, :through => :known_languages, :dependent => :destroy
end
 
class Manager < ActiveRecord::Base
  inherits_from :employee
  validates :bonus, :presence => true, :numericality => true
end

Now, whenever you perform any kind of find on your Employee model, you’ll receive instances of Programmer and Manager as a result.

Employee.first
# yields: <Programmer employee_id: 1>
#     or: <Manager: employee_id: 1 bonus: 5000>

It even works with named scoped.

Employee.where(['created_at >= ?', 3.weeks.ago]).limit(5)
# yields: [<Programmer employee_id: 1>,
#          <Programmer employee_id: 2>,
#          <Manager employee_id: 5 bonus: 4500>,
#          <Programmer employee_id: 12>,
#          <Manager employee_id: 14 bonus: 3500>]

To get started, check out the Multiple Table Inheritance homepage on Github. Please keep in mind that it’s a work in progress. Feel free to submit a new issue or create a pull request if you encounter any problems, fix an issue, or add a new feature.

My initial solution was to convert the city input into an autocomplete field via jQuery UI’s autocomplete plugin. However, I found that a simple autocomplete wasn’t working as well as I’d hoped. After reviewing my first implementation of the autocomplete field, I came to the following conclusion:

1. The autocomplete field is visually styled the same as other text input fields on the page. There’s nothing indicating to users that they’re going to have to do anything other than type into the field and proceed to the next step.
2. The jQuery UI autocomplete plugin defaults to a 250ms delay prior to fetching the list of possible values. This can be overridden via the delay option, but setting it to 0 (i.e.: immediately search) is not viable since it will result in extra unnecessary requests to the server while the user is still typing most of the time.
3. There’s an additional request/response delay after the built-in 250ms delay.

The solution I came up with was to provide hints similar to what the jQuery Tokeninput plugin does:

1. Immediately show a hint such as “Type in a search term” when the user focuses on the input field.
2. Immediately update the hint to read “Searching…” when the plugin starts searching for matching values.

So if jQuery Tokeninput already has these features, why not just use that? The problem is that plugin is intended to replace a multiple select input; for my purpose, I’m looking for a substitute for a single select input.

Given this, there are several possible solutions to my problem:

1. Find a jQuery (or raw JavaScript) autocomplete plugin that already does something similar.
2. Create a custom autocomplete plugin from scratch that includes this functionality.
3. Extend jQuery UI’s autocomplete plugin to include this missing functionality.

After spending a good amount of time searching for an existing plugin that does this, I was surprised to find myself empty-handed. It seems as though there’s no good open-source solution that provides this.

Moving onto the second option, I could build my own autocomplete plugin from scratch. This approach seemed fruitless considering the number of tried and true solutions already available for free. Similarly, I briefly considered branching from jQuery UI’s autocomplete plugin, customizing it as a new plugin by editing and adding only what was needed. I tossed this idea aside as well, as it resulted in too much code duplication, and I would miss out on the benefit of updates to jQuery UI.

Finally, I considered the possibility of extending jQuery UI’s autocomplete, only touching the parts that need to be changed and adding the missing pieces from there. This seemed like the best option among the three. A simple search on extending jQuery plugins led to an answer on StackOverflow that explained the basic premise. The raw boilerplate code looks like this:

(function($) {
    $.extend(true, $["ui"]["autocomplete"].prototype, {
        myCustomFunctionA: function() {
            // TODO
        },
 
        myCustomFunctionB: function() {
            // TODO
        },
 
        // etc...
    });
})(jQuery);

This is a great start. From this, I can assume that I’ll want to create a few methods for showing and hiding a hint text DOM element, as well as binding to some user events to have these methods called. However, I would need to make all this happen through the existing initialization happening within jQuery UI autocomplete.

To do this, I needed to replace jQuery UI autocomplete’s _create function with my own, while still allowing the the original version to execute as intended. I recognized, however, that I would have to do this for multiple functions in the plugin; as such, I wanted a solution that would handle all of these cases. My solution was to make backup copies of the original function definitions, referencing them from my replacement definitions. (I’m open to suggestions for improvement on this approach.)

(function($) {
    var plugin = $["ui"]["autocomplete"].prototype;
 
    // store copies of the original plugin functions before overwriting
    var functions = {};
    for (var i in plugin) {
        if (typeof(plugin[i]) === "function") {
            functions[i] = plugin[i];
        }
    }
 
    // extend existing functionality of the autocomplete plugin
    $.extend(true, plugin, {
        _create: function() {
            // call the original plugin _create code
            functions["_create"].call(this);
 
            // TODO create the hint DOM element, and bind
            //      to events for showing/hiding the hint
        }
    }
})(jQuery);

With this, I can take the code to completion by filling in the missing pieces of functionality I originally set out to implement.

(function($) {
    var plugin = $["ui"]["autocomplete"].prototype;
 
    // store copies of the original plugin functions before overwriting
    var functions = {};
    for (var i in plugin) {
        if (typeof(plugin[i]) === "function") {
            functions[i] = plugin[i];
        }
    }
 
    // extend existing functionality of the autocomplete plugin
    $.extend(true, plugin, {
        _create: function() {
            var self = this;
 
            // call the original plugin _create code
            functions["_create"].call(this);
 
            // capture the data-hint string on the input element
            this.hintText = this.element.data("hint");
 
            // set up the hint object
            this.hint = $("<div></div>");
                .addClass("ui-autocomplete-hint")
                .appendTo($(this.options.appendTo || "body", this.element[0].ownerDocument)[0]);
 
            // show/hide hint text on focus/blur
            this.element
                .bind("focus.autocomplete", function(event) {
                    self._showHint(self.hintText);
                })
                .bind("blur.autocomplete", function(event) {
                    self._hideHint();
                });
        },
 
        destroy: function() {
            this.hint.remove();
            functions["destroy"].call(this);
        },
 
        _search: function(value) {
            this._hideHint();
            functions["_search"].call(this, value);
        },
 
        _showHint: function(text) {
            if (text !== "") {
                this.hint.text(text).show();
                this._resizeHint();
            }
        },
 
        _hideHint: function() {
            this.hint.hide();
        },
 
        _resizeHint: function() {
            this.hint
                .outerWidth(this.element.outerWidth())
                .position($.extend({
                    of: this.element
                }, this.options.position));
        }
    }
})(jQuery);

The above example is not the full implementation, as it doesn’t include some cleanup I’ve included as well as the “Searching…” hint functionality I mentioned previously. However, it still demonstrates how to cleanly extend the jQuery UI autocomplete plugin, the basis of which can easily be reused on other jQuery plugins.

To view the full code, visit my jQuery UI Autocomplete Hints extension on Github. Feel free to use the code in your projects, and if you see any opportunities for improvement, send me a pull request to include your changes.

Most of the backend for this was already implemented from our company working on other tasks. The newest piece to get this working was the voice recognition itself. Fortunately, Android 2.1+ comes with speech recognition capabilities via the RecognizerIntent.

The basic logic is as follows:

1. Create an Intent that calls the speech recognizer action,
2. Pass various parameters, such as the user prompt string and max number of desired results,
3. Accept the response in the form of an array of strings, where the first array item is most likely to correctly match what the user said.

Because we’re using Appcelerator Titanium for our mobile development, this means all our code is built using JavaScript with wrappers and proxies that act as interfaces to the raw Java Android code. This also means that some of the work is simplified, such as a callback method being directly passed to an intent that returns a result, as opposed to defining a special method that handles all results as is typically done on Android.

Unfortunately, at times it becomes clear that working with Titanium is going to take a bit of extra work compared to coding natively for Android.

As I mentioned above, when Android’s speech recognition Intent is successful, it returns an array of text strings that are most likely to match what the user said. To access this array of strings, there is a method on the Intent class named getStringArrayListExtra. The problem is that Titanium’s IntentProxy does not provide a wrapper for this method. As such, the temporary solution until it is included in Titanium Mobile core is to create a custom module that acts as a middleman between the JavaScript and Android layers.

Implementing this took some time, as it was my first time working with Titanium modules, but it turned out to be relatively simple. Since extending Titanium’s core implementation of IntentProxy into a subclass won’t work, I had to essentially create a helper class that accepts the IntentProxy and the parameters required for the method, calling the actual method on the Intent given those parameters.

@Kroll.method
public String[] getStringArrayListExtra(final IntentProxy intentProxy, final String name) {
	if (DBG) {
		Log.d(LCAT, "getStringArrayListExtra called with name:" + name);
	}
 
	final ArrayList<String> list = intentProxy.getIntent().getStringArrayListExtra(name);
	return list != null ? list.toArray(new String[list.size()]) : null;
}

Let’s break down what’s happening here. First, the @Kroll.method is a simple annotation used by Titanium to say “this method should be available when accessed through the JavaScript.” If the annotation weren’t included, then the method would only be accessible by other Java classes.

Next, the DGB and Log.d lines simply create an entry in the Android log for debugging purposes. This doesn’t effect the outcome of the function at all, and is simply useful for anyone attempting to debug their code. Removing these lines would have no effect on the actual implementation of the core functionality.

On the next line, where I define list, I first get the actual Android Intent object from the IntentProxy. Once I have the Intent object, I can call the method I’ve been trying to reach in the first place — getStringArrayListExtra — passing the name parameter provided to the proxy. This method returns an ArrayList of String objects.

Finally, we want to turn a simple array of String objects from our new method. The reason I chose a string array is that Titanium already has the built-in logic to convert a Java array into an array object that JavaScript understands. To return a string array, we need to convert the ArrayList into an array. Fortunately, this can easily be done by calling the toArray method on the ArrayList object that we already have. (If the object is null, then we simply return that instead.)

Great! So now it’s time to compile, implement, and test out our module. Throwing a little speech recognition code together, it quickly becomes clear that there’s another problem. As it turns out, Titanium does not properly handle putExtra for integer values. As such, we’ll need to add a new method called putIntExtra to our custom Intent module to perform this task.

@Kroll.method
public void putIntExtra(final IntentProxy intentProxy, final String key, final Object value) {
	if (DBG) {
		Log.d(LCAT, "putIntExtra called with key:" + key + "\", value:" + value);
	}
 
	if (value instanceof Integer) {
		intentProxy.getIntent().putExtra(key, (Integer) value);
	} else {
		intentProxy.getIntent().putExtra(key, (int) Double.parseDouble(value.toString()));
	}
}

Breaking this down, you can see that it behaves similar in structure to the original module method I described. First, we accept the IntentProxy object along with the desired key and value for the extra data. Note that we accept the value as an Object though since JavaScript uses loose variable types.

Next, we provide the same basic debug logging as mentioned before.

Now we get to the actual heart of what’s happening. Even though I don’t do so myself, this code can technically be called from the Java itself. As such, I perform a preliminary check to see if the value is already an Integer instance. If so, then we don’t perform any magic, and simply call putExtra on the intent. (Java’s automatic unboxing handles the Integer to int conversion.) However, if the object is not already an Integer, then we need to convert it to one.

At first, I tried to utilize the Integer.parseInt method to convert the string representation of the object. However, it turns out that the object was being passed in as “1.0″, and the decimal point was causing an exception to be thrown when this method was called. As such, the solution was to parse the string as a Double, then case that to an integer. This simply removes anything after the decimal, meaning that a value of 1.9999 would become 1. I decided this is acceptable since the method is intended to only be receiving integer representations in the first place.

Finally, after recompiling, reimplementing, and retesting the code, we find that speech recognition now works. The Titanium JavaScript code is returned an array of strings when our RecognizerIntent finishes successfully, and we can use this string to populate our grocery list items for the user.

Here’s an example of the Titanium code used to perform the speech recognition through our new module.

var intentModule = require("com.foodonthetable.intent");
 
var intent = Ti.Android.createIntent({
  action: "android.speech.action.RECOGNIZE_SPEECH"
});
 
intent.putExtra("calling_package", "com.foodonthetable.mobile");
intent.putExtra("android.speech.extra.PROMPT", "Start speaking...");
intent.putExtra("android.speech.extra.LANGUAGE_MODEL", "free_form");
intentModule.putIntExtra(intent, "android.speech.extra.MAX_RESULTS", 5);
 
// For retrieving the array list 
Ti.Android.currentActivity.startActivityForResult(intent, function(event) {
  if (event.resultCode == Ti.Android.RESULT_OK) {
    var intent = event.intent;
    var results = intentModule.getStringArrayListExtra(intent, "android.speech.extra.RESULTS");
 
    if (results && results.length) {
      console.log("There were " + results.length + " results");
      for (var i in results) {
        console.log("Result " + i + " = " + results[i]);
      }
    } else {
      console.log("No results");
    }
  }
});

Feel free to view or modify the full source code on Github. If you have any suggestions for improvement or actual code changes, feel free to contact me or fork my code and submit a pull request. Also, check out the Android meal planning app that’s using this feature for a full demonstration.

Doing a precursory search resulted in a bit of helpful code to get me started. Thanks to tekn0t for sharing his example in this gist.

Unfortunately, I came to the conclusion that this example has three main issues:

1. It doesn’t follow Paperclip convention of passing a set of option key/value pairs into the Processor class to enable the processing.
2. It assumes any class that implements it also implements both rotating? and rotation methods or attributes, with no flexibility on the naming.
3. The base class of the implemented Rotator class is Thumbnail. Because Thumbnail is included by default when the geometry option is used, this means the geometry commands will unnecessarily be executed twice.

With these things in mind, I set out to rewrite the example code into a more robust implementation.

First, we’re going to need an attribute on our model that keeps track of the current angle of rotation. This is necessary so that future rotations will be based upon the current angle in degrees. To do this, create a migration that adds an integer column named rotation to whichever Paperclip model you’re working with.

class AddRotationToPhotos < ActiveRecord::Migration
  def self.up
    add_column :photos, :rotation, :integer, :null => false, :default => 0
  end
 
  def self.down
    remove_column :photos, :rotation
  end
end

Next, we’ll want a simple way to update the rotation value on a model. Since Paperclip needs to be explicitly told when to reprocess an image, we’ll need to tell it to do so whenever this value changes. Also, keep in mind that basic math tells us that the only degrees we should worry about are between 0-360, meaning we can perform a simple modulus operation on our rotation to keep it in this range.

class Photo < ActiveRecord::Base
  before_save :adjust_rotation
  before_update :reprocess_image
 
protected
 
  def adjust_rotation
    self.rotation = self.rotation.to_i
    self.rotation = self.rotation % 360 if (self.rotation >= 360 || self.rotation <= -360)
  end
 
  def reprocess_image
    self.image.reprocess! if self.rotation_changed?
  end
end

Now we can set the rotation value when creating a record (defaulting to 0) or when updating an existing record.

# new record example to rotate 90 degrees clockwise
photo = Photo.new(params[:photo])
photo.rotation = 90
photo.save
 
# update record example to rotate 90 degrees counter-clockwise
photo = Photo.find(params[:id])
photo.update_attribute(:rotation, -90)

So far, our code has’t done anything to tell Paperclip what to do. The first step in notifying Paperclip is to update the hash passed into has_attached_file. Notably, we’ll want to include :rotator (which will be the name of our processor class) into the array of processors. Also, we’ll need to pass a :rotation key/value pair in with each attachment style we wish to process as such. Since this call is being made at the model level, we can’t simply use self.rotation to access the value of the record’s rotation angle. Fortunately, Paperclip allows us to use a lambda function to return a styles hash, which includes the Attachment object. Knowing this, we can access this current record’s rotation via attachment.instance.rotation.

class Photo < ActiveRecord::Base
  has_attached_file :image,
    :processors => [:rotator],
    :styles => lambda { |a| {
      :thumb => {
        :geometry => '50x50#',
        :rotation => a.instance.rotation,
      },
      :full => {
        :geometry => '640x640>',
        :rotation => a.instance.rotation,
      },
    } }
end

Finally, now that we’re passing the rotation value to Paperclip, we need to create the processor to handle it. Much of the basis of this code is taken from the Thumbnail processor included with Paperclip, which I won’t be delving into. The main thing to pay attention to is any code pertaining to the rotation attribute being set and used, most notably in the transformation_command method.

module Paperclip
  class Rotator < Processor
    attr_accessor :file, :rotation, :source_file_options, :convert_options, :whiny, :current_format, :basename
 
    def initialize(file, options = {}, attachment = nil)
      super
      @file                = file
      @rotation            = options[:rotation].to_i
      @source_file_options = options[:source_file_options]
      @convert_options     = options[:convert_options]
      @whiny               = options[:whiny].nil? ? true : options[:whiny]
      @current_format      = File.extname(@file.path)
      @basename            = File.basename(@file.path, @current_format)
    end
 
    def make
      if @rotation != 0
        dst = Tempfile.new([@basename, @format ? ".#{@format}" : ''])
        dst.binmode
 
        begin
          parameters = []
          parameters << source_file_options
          parameters << ":source"
          parameters << transformation_command
          parameters << convert_options
          parameters << ":dest"
 
          parameters = parameters.flatten.compact.join(" ").strip.squeeze(" ")
          success = Paperclip.run("convert", parameters, :source => File.expand_path(@file.path), :dest => File.expand_path(dst.path))
        rescue Cocaine::ExitStatusError => e
          raise PaperclipError, "There was an error processing the image rotation for #{@basename}" if @whiny
        rescue Cocaine::CommandNotFoundError => e
          raise Paperclip::CommandNotFoundError.new("Could not run the `convert` command. Please install ImageMagick.")
        end
 
        dst
      else
        @file
      end
    end
 
  private
 
    def transformation_command
      "-rotate #{@rotation}"
    end
  end
end

And there you have it! An easy-to-use rotation processor for use with your Paperclip enabled model in Rails.

Upload Multipart Image Using Android’s HttpPost

Most of my searches about how to upload images to a web server via Java led to information on classes not directly pertaining to Android’s built-in HttpClient and HttpRequestBase classes. However, since the entirety of my JSON HTTP requests in my Android app is based upon these classes, I wanted to utilize them if possible. Finally, I came across Vikas’ post that led me along the correct path. The key is to download and include Apache’s HttpMime library, which is a part of HttpClient 4.1. Because Android is using HttpClient 3.0, this class isn’t available by default on Android. Read Vikas’ post for more info.

Mimicking HTML Drop-downs with Android Spinners

Part of my registration process when for my Android app is to utilize numeric IDs that represent the visible text for various drop-down options (known as Spinners in Android). Simply utilizing the zero-based index of a standard ArrayAdapter wasn’t suitable, however, since the IDs should match up with database values on my server, and will not necessarily be numerically ordered. The solution, as outlined by user385674 on StackOverflow was to utilize a custom Object that includes a custom key and text value, with the toString method returning what the spinner should display.

Loading List Item Images Asynchronously on Android

This is definitely one of the more complex issues I’ve come across in my early development for Android, and it makes me wish there was a built-in method for ImageViews to download remote images. Tim Bray’s post on the official Android blog helps to find a way to handle this situation. However, between his blog post and the sample project on Google Code, I’m sure you’ll see the great level of complexity involved here. The main issue revolves around the race condition between Android’s reuse of views while scrolling through lists and the HTTP response containing the image data for one of these reusable views. The result is that an ImageView could load with the correct image, being replaced moments later by a slower-loading image that shouldn’t even be on the screen anymore.

Integer Out of Range with ThinkingSphinx in Rails

One of the most fun (read: teeth-grindingly frustrating) things about coding is that sometimes things don’t work right out of the box. And not in a “oh, I just need to add a configuration line” kind of way. No, I’m talking about the “I’m using a specific version of [this], and it doesn’t work with a specific version of [that], and there’s no way of knowing it until digging deep into the code…and my soul.” The integer out of range issue I was running into with ThinkingSphinx is exactly the type of thing I’m talking about here. Specifically, it was only happening because I’m using ThinkingSphinx with PostgreSQL, and I needed to set the use_64_bit flag on Sphinx v2.0.1. Since I was using a 1.X version of Sphinx, this meant I had to upgrade.

After attempting to upgrade, I quickly learned that Sphinx 2.0.1 doesn’t work with OS X. User pat on StackOverflow posted a solution: upgrade Sphinx to 2.0.2-dev. This, of course, did not fix the problem for me, resulting in a new “missing pthread_mutex_timedlock” error. After much more digging, I found that at the time pat posted his solution, Sphinx was at revision 2887. However, when I tried to update, the code was at revision 2888, which is where the new error was introduced. The solution was to install revision 2887 from the SVN repository.

According to the official bug report, this issue is now fixed as of revision 2913, although I have not tested personally.

After finding nothing on my own and not getting any help from StackOverflow, I resigned to the fact that I’m going to have to implement my own solution. The solution I came up with is relatively easy, though I would ultimately like to refactor it so it doesn’t seem quite as spread out between the controller and model layers.

First, I created a migration to add new columns to my user model to capture the data I want.

class AddTrafficSourceToUsers < ActiveRecord::Migration
  def self.up
    add_column :users, :referrer, :text
    add_column :users, :traffic_source, :string
    add_column :users, :traffic_keywords, :string
  end
 
  def self.down
    remove_column :users, :referrer
    remove_column :users, :traffic_source
    remove_column :users, :traffic_keywords
  end
end

Next, I updated my ApplicationController to capture the referrer on a user’s first visit. (Non sequitur: the grammar Nazi in me can’t stand that “referer” is misspelled in the HTTP spec.)

class ApplicationController < ActionController::Base
  before_filter :capture_referrer
 
protected
 
  def capture_referrer
    session[:referrer] = request.env['HTTP_REFERER'] if !session[:referrer]
  end
end

Since it’s bad practice in the MVC methodology for the model to talk directly to the session (since models can be used outside the scope of a web request), I had to then manually set the referrer value on the model via the signup controller action.

class UsersController < ApplicationController
  def create
    @user = User.new(params[:user])
    @user.referrer = session[:referrer]
 
    if @user.save
      redirect_to home_path
    else
      render :new
    end
  end
end

By this point, you’re probably wondering why I’ve only set the referrer attribute on the model when we also need to worry about the traffic_source and traffic_keywords. Since the latter two attributes are based upon the value of the referrer attribute, that means we can set them in a model callback at the point when the record is created.

class User < ActiveModel::Base
  # NOTE: Ensure that referrer, traffic_source, and traffic_keywords
  # are NOT included in the call to attr_accessible since we don't
  # want the user to pass faux values.
  attr_accessible :username, :email, :password
 
  before_create :set_traffic_source
 
private
 
  def set_traffic_source
    if self.referrer
      uri = URI.parse(self.referrer)
      self.traffic_source ||= uri.host.downcase.gsub(/^www\./, '')
      self.traffic_keywords ||= search_terms(uri)
    end
  end
 
  def search_terms(uri)
    return nil if uri.nil?
    return nil if uri.query.nil?
 
    host = uri.host.downcase.gsub(/^www\./, '')
    params = CGI.parse(uri.query)
 
    result = host.match(/yahoo\.com$/) ? params['p'] : (params['q'] || params['query'])
    result ? result.join : nil
  end
end

There’s definitely a bit of explaining I need to do here. First, when setting traffic_source, I’m only interested in the domain (sans leading “www.”). The gsub call is used to strip out any leading “www.” so that, for example, “www.google.com” and “google.com” both end up being saved as “google.com”. Similarly, I converted all domain names to lowercase to ensure all capitalization variations are treated the same since they ultimately are.

Second, I made an assumption that any search string is going to be passed in under a query parameter named either “q” or “query”. When testing the major search engines along with a few of the lesser used ones, I found this to be true for all of them with the exception of Yahoo, which uses “p” for some reason. This is why you’ll see in my code that there is a specific check for the domain name ending in “yahoo.com” that is used to determine which query string parameter to check before defaulting to “q” or “query”.

There you have it! Now I’m able to perform simple queries on where my users are coming from and how they’re finding me. This alone isn’t much more useful than what a free service like Google Analytics offers, but obviously with greater data-mining, truly insightful information can be learned about each of your users and their behaviors’ depending upon where they’re from and how they found you.

In Rails 3, creating new validators is relatively painless. Create a new validator class in a folder defined by you. For my project, I decided to place all validators within app/validators.

The class should extend the ActiveModel::EachValidator class found within Rails 3 core, in which you’ll generally override two methods: check_validity! and validate_each.

1. check_validity! is called by the class’ initializer to verify that the validator’s arguments supplied are valid. If they are not, throw an exception that will be seen by the developer using your validator.
2. validate_each is where the actual validation occurs on the values set for each attribute implementing this validator at runtime.

The code for the validator is included in the code snippet below.

class SpamValidator < ActiveModel::EachValidator
  DEFAULTS = {:level => 1, :timeout => 5}.freeze
  MESSAGES = {:block => "is blacklisted", :no_domain => "includes invalid domain", :ip_not_recognized => nil, :over_limit => nil}.freeze
  RESERVED_OPTIONS = [:level, :timeout, :block, :no_domain, :ip_not_recognized, :over_limit].freeze
 
  def initialize(options)
    DEFAULTS.each do |key, value|
      options[key] ||= value
    end
 
    super(options)
  end
 
  def check_validity!
    unless options[:level].is_a?(Integer) && (1..5).include?(options[:level])
      raise ArgumentError, ":level must be an Integer between 1-5"
    end
 
    unless options[:timeout].is_a?(Integer) && options[:timeout] > 0
      raise ArgumentError, ":timeout must be an Integer greater than 0"
    end
  end
 
  def validate_each(record, attribute, value)
    return if value.nil?
    raise ArgumentError, "#{attribute} must be a String." unless value.is_a?(String)
 
    begin
      # API REF: http://www.stop-registration-spam.org/api
      url = "http://www.stop-registration-spam.org/api/level#{options[:level]}/json?email=#{CGI.escape(value)}"
      result = JSON.parse(open(url, :read_timeout => options[:timeout]).read)
    rescue
      # TODO log error
    end
 
    if result && result['request_status']
      error_key = result['request_status'].to_s.downcase.to_sym
      error_message = MESSAGES[error_key]
 
      if error_message
        errors_options = options.except(*RESERVED_OPTIONS)
        errors_options[:message] ||= options[error_key] if options[error_key]
 
        record.errors.add(attribute, error_message, errors_options)
      end
    end
  end
end

Using this validator is incredibly easy. In your model, just add a :spam key with whatever values you require passed as a hash within the validates call for your email-formatted attributes.

class User < ActiveRecord::Base
  validates :email, :spam => { :level => 5 }
end

The hash accepts the following parameters:

• :level – integer from 1-5 (default 1) – The level of spam prevention to utilize as defined by the Stop-Registration-Spam.org API.
• :timeout – integer greater than 0 (default 5) – The number of seconds to timeout when unable to connect with, or receive a response from, the API.
• :block – string (default “is blacklisted”) – The message to use for response code BLOCK, meaning this email address did not meet the checks at the level requested.
• :no_domain – string (default “includes invalid domain”) – The message to use for response code NO_DOMAIN, meaning the domain provided is not valid.
• :ip_not_recognized – string (default nil) – The message to use for response code IP_NOT_RECOGNISED, meaning the requesting IP is not valid for high volume commercial use.
• :over_limit – string (default nil) – The message to use for response code OVER_LIMIT, meaning you have reached your daily request limit.

My decision to leave :ip_not_recognized and :over_limit as nil values with no error messages is due to my not wanting to prevent users from registering when the service is not responding as expected. Similarly, the validator passes when a timeout occurs. This could easily be modified to allow for further customizations through additional hash values, but this is suitable for my needs, and it demonstrates the simplicity behind implementing a custom Rails 3 validator.

The presentation itself covers beginner level material. It describes my personal reasons for moving from CakePHP to Rails, and why I now prefer the latter. Although it does not delve into any of the finer details, it does cover a few key points about both Rails and Ruby in general:

• A comparison of the overall structure of each framework
• Some general Ruby language benefits not found in PHP
• The simplicity of plugin (gem) integration in Rails compared to CakePHP
• Deployment strategies available in Rails

Again, the topics here only scratch the surface. There is a lot of information not included that make the Rails framework superior to my own experiences with CakePHP.

If you’re currently developing with PHP, I definitely encourage you to consider giving Rails a try. Feel free to download the PDF version of my presentation: Baker to Builder: CakePHP to Rails.