Wayne Robinson

Most fonts are designed for readability of words, not complicated codes and recently, we've had to provide referreral codes to our partners so that we can track the applications that come from them. Instead of sufferring through referral codes being incorrectly provided because someone has confused an O for an 0 or a 1 for a l or even an I (see what I mean!), I created a plugin that turns any string into it's spoken version using the NATO phonetic alphabet.

To install this plugin in Ruby on Rails, just type the following from your application's root directory:

script/plugin install _
https://svn01.allmyfunds.com.au/svn/public/plugins/phonetic_alphabet

To use, see this except from the README file:

You can get the phonetic equivalent of a single character with PhoneticAlphabet[single_character]

or

You can convert a string to it's phonetic equivalent using the String#to_phonetic overridden method.

  Example:

    puts "hello world".to_phonetic

  Outputs:

    hotel echo lima lima oscar SPACE whiskey oscar romeo lima delta

You can also pass in a different separator:

  Example:

    puts "hello world".to_phonetic("-")

  Outputs:

    hotel-echo-lima-lima-oscar-SPACE-whiskey-oscar-romeo-lima-delta

I have had the opportunity to recently get my hands on an iPod Touch specifically to do web-development to work with it's fully-featured Safari web browser.

These applications need specialised formatting for these devices (both have the same resolution screens). The easiest way to identify these phones is using the User-Agent header passed in a HTTP GET/POST request.

The iPod Touch's (firmware version 1.1.1) User-Agent field (found by writing a simple PHP page to return the $_SERVER['HTTP_USER_AGENT']) is:

Mozilla/5.0 (iPod; U; CPU like Mac OS X; en)
    AppleWebKit/420.1 (KHTML, like Gecko)
    Version/3.0 (Mobile/3A110a Safari/419.3

The iPhone's User-Agent field (found at note19.com's blog) is:

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en)
    AppleWebKit/420+ (KHTML, like Gecko)
    Version/3.0 Mobile/1C28 Safari/419.3 

 The above User-Agent fields have been split over multiple lines to aid legibility.

Ruby on Rails is great. Partially because of all the ORM stuff and partially because Ruby is infitely extendable and overrideable (yes, I just made that word up).

On my current project, I have a lot of extended attributes in models that modify other attributes or even other models entirely. So, when I create new objects and assign their attributes, I would prefer the mass assignments to go through these custom mutators.

Now in Ruby, this is relatively simple. When you want to call a method within an object programmatically, you can use the #send method:

    str = "Hello world!"
    puts str.send(:size)

    Displays: 12

However, when you are performing property setting, you have to do some manipulation to the attribute name first before you can assign a value to it. For example, the code for sending the values of a hash to the corresponding mutator methods in a Person object would be the following:

    hash = {
        :first_name => "Wayne", 
        :last_name => "Robinson", 
        :date_of_birth => "1982-02-15"
    }

    hash.each do | key, value |
      person.send("#{key}=", value)
    end

As you can see, there is a little bit of repetition there if you have to use that in more than one place. So, I've DRYed this code into the following ActiveRecord extension. Just pop this active_record_getters_and_setters.rb file in your lib/ directory and require it in your environment.rb file with:

    require 'active_record_getters_and_setters.rb' 

You will now have three extra methods accessible to you in all your ActiveRecord objects.

ActiveRecord::Base#set(attribute, value)
    Assigns value to the mutator (setter) for attribute.

ActiveRecord::Base#get(attribute)
    Gets the value from the accessor (getter) for attribute.

ActiveRecord::Base#set_attributes(attribute_hash)
   Does an ActiveRecord::Base#set for each key/value pair in attribute_hash.

Just wrote a small one-liner to add all non-version controlled files in the current path and down to a subversion repository without any unecessary warning messages or errors.

svn st | \
  grep -E "^\?" | \
  sed -e s/^\?\\s*//g | \
  sed -e s/\\s/\\\\\ /g | \
  xargs -I{} svn add {}

I have only tested this on Cygwin so far, but it should work fine on Linux and Mac OS X.

With all the work I've been doing with Ruby on Rails recently, I haven't given much thought to the advancements being made for web-based application development. However, yesterday I stumbled across TIBCO's General Interface.

General Interface is an AJAX GUI design framework, with it's IDE also published as a web application. It communicates with the N-tier via XML-based web services and has a very good selection of well written controls (lists, matrices, charts, etc) for embedding in your application.

I've played a little with General Interface and I'm generally blown-away by it's power and ease of use. The only two things stopping me from jumping in and doing some serious development, is the fact that it is only a GUI interaction tool and not a complete development stack. I would still need to write the N-tier somewhere (yes, I know I could publish Ruby on Rails applications as web-services only).

If you're developing web-based content for an existing application (say, Salesforce or NetSuite) and are looking for an easy to use, powerful, web-based GUI framework. I would suggest evaluating TIBCO's General Interface. Or at leaset having a look at some of their screencasts.

Ever wanted to extract multiple values from a Script.aculo.us Google Suggest-like autocomplete text field? I recently did and here's how.

If you aren't aware of how to use autocomplete text fields, please read over the simple and customised demos available at Script.aculo.us. Also, a warning, this demo utilises Ruby on Rails however, with a little bit of modification, this should work using the Script.aculo.us library without Ruby on Rails.

This example will auto-populate a state and postcode based on the user's selected suburb (yes, I'm Australian).

The first step is to create a view for the page containing the autocomplete field and for the autocomplete field itself.

Controller:

def new
  # This is the main controller that will 
  # contain the autocomplete field
  @contact = Contact.new 
end

def auto_complete_for_suburb
  suburb = params[:suburb]
  @surburbs = Suburb.find_by_name(suburb, 
      :order => "name", :limit => 20)
  render :partial => "auto_complete_suburb"
end

View for the new action (assume an application.rhtml template has been created, this template must include the Prototype and Script.aculo.us javascript libraries):

<%= form_tag({:action => :create}, {:method => :post}) %>
<table>
<tr>
  <th>Name:</th>
  <td><%= text_field(:contact, :name) %></td>
</tr>
<tr>
  <th>Suburb:</th>
  <td><%= text_field_with_autcomplete(:contact, :suburb, 
    :select => "value", 
    :after_update_element => 
      "function (ele, value) {
        $("contact_state").value = 
          Ajax.Autocompleter.extract_value(value, 
            'STATE');
        $("contact_postcode").value =
          Ajax.Autocompleter.extract_value(value, 
            'POSTCODE'); }
     ") %>
  </td>
</tr>
<tr>
  <th>State:</th>
  <td><%= text_field(:contact, :state, :size => 10) %></td>
</tr>
<tr>
  <th>Postcode:</th>
  <td><%= text_field(:contact, :postcode, 
            :size => 10) %></td>
</tr>
</table>
<%= end_form_tag %>

Before we continue any further, it is worth-while defining the _auto_complete_suburb.rhtml partial.

<ul class="suburbs">
<% unless @suburbs.nil? -%>
<% @suburbs.each do | suburb | -%>
  <li>
    <%= h("#{suburb[:name]}, #{suburb[:state]}" + 
          "#{suburb[:postcode]}") %>
    <div class="value" style="display: none;">
      <%= h(suburb[:name]) %>
    </div>
    <div class="STATE" style="display: none;">
      <%= h(suburb[:state]) %>
    </div>
    <div class="POSTCODE" style="display: none;">
      <%= h(suburb[:postcode]) %>
    </div>
  </li>
<% end -%>
<% end -%>
</ul> 

The autocompleter view has three (3) hidden <div> tags which contain the extra data used by the base Autocompleter Javascript methods as well as the new one (extract_value) that will be defined below. 

You may also want to cast your eye over the suburb field definition in the new contact view as this is where most of the action is. There are two options to note:

• the :value option which specifies the class name of the element which contains the value to place in attribute (the default would be whatever is within the rendered <li> field which, as we will find out below, will contain more than just the selected suburb)
• the :after_update_element option which specifies a piece of Javascript to execute when the item is selected. You will see that this Javascript executes the Ajax.Autocompleter.extract_value function twice. This function does not exist in Script.aculo.us but is provides an easy way to extract extra values from an autocomplete list.

The Script.aculo.us Autocompleter methods conviently pass the complete contents of the <li> field to the method specified in the :after_update_element option. This allows us to extract any additional values from this data. I have created a simple addition to the Ajax.Autocompleter class below that speeds this extraction:

Additional method for Ajax.Autocompleter class. This can be declared anywhere after the inital Script.aculo.us script inclusion. For my purposes I put this at the top of my application.js file. 

Ajax.Autocompleter.extract_value = 
  function (value, className) {
    var result;

    var elements = 
      document.getElementsByClassName(className, value);
    if (elements && elements.length == 1) {
      result = elements[0].innerHTML.unescapeHTML();
    }

    return result;
  };

 So that's all there is to it. If anyone would like me to create a demo of the above code, ask me and, if I get enough requests, I'll put something together.

I recently had a requirement to create a proof-of-concept "what-if" calculator for a new product I'm involved in which will launch in the first quarter of next year.

Now, I prefer to write web-based applications because I hate supporting multiple operating systems and client versions (yes, I'm aware that different browsers behave differently, but there are a number of toolkits out there that solve most of those problems). However, this calculator required some pretty graphs (for non-techie types) and I didn't want to go to the effort of writing and deploying a server-based application for a simple calculator.

I went searching and I found there has been some work recently in the realm of browser-based graphics (either SVG or the Canvas tag) but, as with most new things, different browsers handled different things, well, differently. So I searched a little more and found a library called PlotKit which not only wrapped up the different graphics libraries (through a Google's ExplorerCanvas), but it also provides a ready-to-use graphing library.

Web-based development is becoming increasingly more powerful and I think we will continue to see the trend towards web-based applications continuing. Long live the browser!