Article RSS Feed

DataMapper Migrations

Sun, 05 Oct 2008 21:20:20 GMT

I’ve been working on some merb related things of late, and I’m planning on writing a more detailed article on creating a merb application from scratch as so many of the tutorials out there kind of leave you hanging. In the interim though, I’m just going to touch on a little nugget of information that isn’t very well publicised regarding DataMapper, one of the ORMs that gets used with merb.

ActiveRecord Style Migrations with DataMapper

That’s right, you aren’t left having to wrestle with the command line and ALTER TABLE statements just because you’ve left ActiveRecord behind. All the migration joy you’ve come to love with ruby on rails can come and live with you happily with merb and DataMapper.

First things first, you’ll want to generate a new migration:

merb-gen migration my_migration

We should now have a file named 001_my_migration.rb and if we look at it, it won’t be too foreign based on our ActiveRecord experiences:

migration 2, :my_migration do
  up do
  end

  down do
  end
end

To pad it out with some code that is actually useful, add in the definitions for what you want done:

migration 2, :my_migration do
  up do
    create_table(:posts) do
      column(:id, Integer, :serial => true)
      column(:title, String, :size => 255)
      column(:description, Text)
      column(:published, Boolean)
      column(:created_at, DateTime)
      column(:updated_at, DateTime)
    end
  end

  down do
    drop_table(:posts)
  end
end

Running the DataMapper Migration

And now that we’ve got the migration we are happy with, applying it to our underlying database is just a matter of the following:

rake dm:db:migrate

Introducing Map.ly, collaborative mapping

Tue, 12 Aug 2008 09:00:00 GMT

From the necessity is the mother of all invention category, I introduce a new product I’ve hastily cobbled together over the past week or so. Map.ly is a means of “sharing directions, locations, and maps” with other people.

It is still very much in development, I’m loathe to call it beta as it’s probably closer to alpha but still… So what is it’s purpose? My girlfriend is forever having to plan meetings and trips for the people in her team, and trying to herd these sheep ahem I meant orientate her colleagues in foreign cities can be tricky. She needed something to accompany their printed itinerary showing all the various locations they’d need to be during their stay, and where they were in relation to each other. And print out a google map for each location seemed needlessly difficult and not that helpful, we wanted to plot everything on the one map if possible.

Enter Map.ly. Double click where you want to place a marker, enter in the name and some details, and save. You’ll get a nice short URL back to the map that you can pass around and you can all add your own markers to it. I think support in IE might currently be a little bit flaky, I’ll check later today. And there are a number of features still in the pipeline (getting directions between points, entering in addresses, etc.) but I’m hoping it will prove to be something useful. So go give someone some directions to somewhere

And most useful to the geeks out there, is that it’s forced me to resurrect a long since dead gem I once wrote for mapping as I felt YM4R and the other Map API gems just weren’t ruby enough. Once the feature set is locked in, I’ll release an updated version allowing you to do all the cool things that get implemented on Map.ly.

Nginx Intermediary SSL Certificates and Passphrases

Mon, 11 Aug 2008 09:00:00 GMT

I’ve had to do this 3 or 4 times in the past 12 months, and each time I waste a good chunk of time trying to re-discover how to do it. So this post is as much for my own documentation sake as it is sharing the love. If you’ve ever bought an SSL certificate from GoDaddy or a similar provider that provides and intermediary certificate to include, you might have run into a bit of a problem trying to work out how to include it in your nginx config. Well it’s actually pretty straight-forward, provided you remember the steps.

Merging the site and intermediary SSL certificates

First thing you’ll need to do is create a new certificate, which is just the one for your site and the intermediary merged together. In Apache you’d specify them both individually. Nginx only allows you to specify one, so lets put them in the same file:


cat rubypond.com.crt >> rubypond.com.crt.merged
cat intermediate_bundle.crt >> rubypond.com.crt.merged

Removing SSL Passphrase

The next step, is to remove the passphrase off the key for the site. I’d love to keep it on, but it means nginx can’t be restarted without an operator at the console to enter in the passphrase every time which is definitely less than ideal. So to remove the passphrase from your key, I’ll first back it up and then take it off with openssl:


mv rubypond.key rubypond.key.passphrased
openssl rsa -in rubypond.key.passphrased -out rubypond.key

Configuring Nginx to use your new SSL certificate

This config is taken straight from my earlier article on setting up nginx, ssl, and virtual hosts, but I’ll include it here just for good measure too:


server {
  listen 443;
  server_name myserver.com;  

  ssl on;
  ssl_certificate /etc/nginx/certs/rubypond.com.crt.merged; 
  ssl_certificate_key /etc/nginx/certs/rubypond.key; 

  # put the rest of your server configuration here.

  location / {
     proxy_set_header X-FORWARDED_PROTO https;

     # put your config here
  }
}

Just be sure to point the certificate entry to the new merged certificate, the key at the now un-passphrased key, and restart nginx. Done.

The complete guide to setting up Starling

Thu, 17 Jul 2008 09:00:00 GMT

We wanted to push some long running tasks off to the background so that we didn’t tie up a mongrel needlessly. I’ve wrestled (and won!) with backgroundrb in the past, but it just seemed like a chore. And they’ve since changed the API enough to mean it would be back to the drawing board, so we may as well assess some of the other options. So without too much further ado, the complete guide to installing, using, and monitoring starling.

For those that haven’t heard Starling is the back-end queuing system that Twitter use. And despite the stability issues Twitter have, if initial impressions are anything to go by I don’t think Starling is the reason. It’s fairly light, sits on top of MemCache, and is very quick. The initial lure to Starling though was via the Workling plug-in. We could get a prototype out the door using just the Spawn workling, and then when a queue became important switch over.

Installing Workling

We’re going to take the same approach I did, and get a prototype background process happening with Spawn first. So let’s install Workling and Spawn:


script/plugin install http://svn.playtype.net/plugins/workling/
script/plugin install http://spawn.rubyforge.org/svn/spawn/

Now in your environment (environment.rb? an initializer? you decide) add the following:


Workling::Remote.dispatcher = Workling::Remote::Runners::SpawnRunner.new

Done!

Creating A Workling Background Worker

Now it’s time to create a worker, basically to define what it is exactly that should be executed in the background. For the same of illustration, I’m just going to loop and create some records. I create the follow app/workers/example_worker.rb file:

class ExampleWorker < Workling::Base

  def create_new_records
    1000.times do
      Item.create :some_name => options[:some_name]
    end
  end 

end

Calling Your New Workling Background Worker

Now in whichever controller would normally need to start this task, you can place a call to the workling worker:

ExampleWorker.async_create_new_records(:some_name => "This Person")

Workling will create a new method for us to call, by prefixing out method name with async_ to allow us to call it asynchronously. Pass in a hash of values you want to use into the method, workling will add a key named :uid containing the unique identifier assigned to this task.

And now we’re done here too! This will use Spawn to fork the job, take it out of the mongrel process, and let your rails stack continue and not hold up your other users.

Installing Starling

Install Starling by grabbing the gem and the MemCache Client (which strangely has a dependency on ZenTest which I need to investigate…):

sudo gem install memcache-client starling

Now the dependencies are installed, we need to start up the required services. You’re going to need the Starling daemon running, as well as the workling client. I’d rather not have Starling run as root so first I create a user, and then give it somewhere to create it’s pid and spool files (you can probably skip this and run as root on your local dev box):

sudo /usr/sbin/adduser -s /sbin/nologin starling
sudo mkdir -p /var/spool/starling
sudo mkdir -p /var/run/starling
sudo chown starling:starling /var/spool/starling
sudo chown starling:starling /var/run/starling

And now time to start up the services:

sudo -u starling starling -P /var/run/starling/starling.pid -d
script/workling_starling_client start

A note of particular importance here. The workling_starling_client will run in whatever environment RAILS_ENV is set to, and is not passed in via a command line option. It also does some fruity things with loading up your workers at run time, so if you’re running development and test on the one box you’ll need to stop the workling client and restart it each time you want to change environments (or best yet, set your rake:spec/rake:test task to do it for you).

Switching Over To Starling For Background Processing

Switching between background processing systems is pretty simple, we just update the environment setting we made earlier to:

Workling::Remote.dispatcher = Workling::Remote::Runners::StarlingRunner.new

And that’s it, business as usual!

Monitoring the sucker

It is all fine and dandy having it up and running now, but it’d be nice to keep it that way. That’s where god comes in and some tomfoolery with our app.god config. If you’ve not already done so, I suggest you read my previous article on monitoring rails with god which talks about creating a generic config file in your rails app so you don’t need to manage god configs for each instance.

I’m going to change the example app.god in that article to look like:

class Rubypond
  attr_reader :ports, :server_names, :workling_client

  def initialize
    @ports = [5000, 5001]
    @server_names = "www.rubypond.com rubypond.com" 
    @workling_client = true
  end
end

@apps << Rubypond.new

And within the god.conf on the server I’ll add the following methods:

def configure_workling_client(w, rails_root,  app_name)
  w.uid = "mongrel" 
  w.gid = "webserver" 
  w.name = "#{app_name}-workling" 
  w.group = "#{app_name}" 
  w.interval = 30.seconds
  w.start = "RAILS_ENV=production #{rails_root}/script/workling_starling_client start" 
  w.stop = "#{rails_root}/script/workling_starling_client stop" 
  w.restart = "#{rails_root}/script/workling_starling_client restart" 
  w.pid_file = "#{rails_root}/log/workling.pid" 

  w.behavior(:clean_pid_file)
end

def monitor_app(w)
  start_if_not_running(w)
  restart_if_resource_hog(w)
  monitor_lifecycle(w)
end

Okay, so monitor_app is actually just renaming monitor_rails_app to be more generic. Make sure you change references everywhere though. Elsewhere in the god.conf file we had a block similar to the following:

@apps.each do |app|
  app_name = app.class.name.downcase
  rails_root = "/var/www/apps/#{app_name}/current" 

  app.ports.each do |port|
    God.watch do |w|
      configure_mongrel(w, rails_root, app_name, port)
      monitor_rails_app(w)
    end
  end

  God.watch do |w|
    configure_workling_client(w, rails_root, app_name)
    monitor_app(w)
  end if app.respond_to? :workling_client
end

The last God.watch there is where the magic happens. It will look at the app we’ve defined in app.god, and if we’ve provided an attribute called :workling_client then it will automatically monitor a workling client for this app. We’re not quite done yet though. We also need Starling to be running, but that’s not on a per app basis we just have one for the server. So I’m just going to insert this directly into god.conf:

God.watch do |w|
  w.name = "starling" 
  w.group = "starlings" 
  w.uid = "starling" 
  w.gid = "starling" 
  w.interval = 30.seconds # default
  w.start = "/usr/bin/starling -P /var/run/starling/starling.pid -d" 
  w.start_grace = 20.seconds
  w.restart_grace = 20.seconds
  w.pid_file = "/var/run/starling/starling.pid" 
  w.behavior(:clean_pid_file)

  monitor_app(w)
end

Now restart god to take the new config, deploy you changes to your rails app, and cross your fingers ;)

Sexy Forms in Rails

Wed, 16 Jul 2008 09:00:00 GMT

I’ve been meaning to release this for quite a while now, I’ve finally got around to packaging it up for some form of public consumption. Basically, I got sick of having to manually create label tags for each of my form inputs. They should be there by default so that users with visual or other impairments have enough additional information to use the site. I’m also lazy, and would have a tendency to forget to put them in otherwise. I also wanted a consistent way to display any additional contextual information, so here it is.

I’ll go through the code in detail here, but I’ll keep it updated with any changes and available for download at the semantic form builder git repo. So now on to the code.

It started with a custom FormBuilder.

class SemanticFormBuilder < ActionView::Helpers::FormBuilder
  include SemanticFormHelper

  def field_settings(method, options = {}, tag_value = nil)
    field_name = "#{@object_name}_#{method.to_s}" 
    default_label = tag_value.nil? ? "#{method.to_s.gsub(/\_/, " ")}" : "#{tag_value.to_s.gsub(/\_/, " ")}" 
    label = options[:label] ? options.delete(:label) : default_label
    options[:class] ||= "" 
    options[:class] += options[:required] ? " required" : "" 
    label += "^*" if options[:required]
    [field_name, label, options]
  end

  def text_field(method, options = {})
    field_name, label, options = field_settings(method, options)
    wrapping("text", field_name, label, super, options)
  end

  def file_field(method, options = {})
    field_name, label, options = field_settings(method, options)
    wrapping("file", field_name, label, super, options)
  end

  def datetime_select(method, options = {})
    field_name, label, options = field_settings(method, options)
    wrapping("datetime", field_name, label, super, options)
  end

  def date_select(method, options = {})
    field_name, label, options = field_settings(method, options)
    wrapping("date", field_name, label, super, options)
  end

  def radio_button(method, tag_value, options = {})
    field_name, label, options = field_settings(method, options)
    wrapping("radio", field_name, label, super, options)
  end

  def check_box(method, options = {}, checked_value = "1", unchecked_value = "0")
    field_name, label, options = field_settings(method, options)
    wrapping("check-box", field_name, label, super, options)
  end

  def select(method, choices, options = {}, html_options = {})
    field_name, label, options = field_settings(method, options)
    wrapping("select", field_name, label, super, options)
  end

  def time_zone_select(method, choices, options = {}, html_options = {})
    field_name, label, options = field_settings(method, options)
    # wrapping("time-zone-select", field_name, label, super, options)
    select_box = this_check_box = @template.select(@object_name, method, choices, options.merge(:object => @object), html_options)
    wrapping("time-zone-select", field_name, label, select_box, options)    
  end

  def password_field(method, options = {})
    field_name, label, options = field_settings(method, options)
    wrapping("password", field_name, label, super, options)
  end

  def text_area(method, options = {})
    field_name, label, options = field_settings(method, options)
    wrapping("textarea", field_name, label, super, options)
  end

  def submit(method, options = {})
    field_name, label, options = field_settings(method, options.merge( :label => "&nbsp;"))
    wrapping("submit", field_name, label, super, options)
  end

  def submit_and_cancel(submit_name, cancel_name, options = {})
    submit_button = @template.submit_tag(submit_name, options)
    cancel_button = @template.submit_tag(cancel_name, options)
    wrapping("submit", nil, "", submit_button+cancel_button, options)
  end

  def radio_button_group(method, values, options = {})
    selections = []
    values.each do |value|
      if value.is_a?(Hash)
        tag_value = value[:value]
        label = value[:label]
        help = value.delete(:help)
      else
        tag_value = value
        value_text = value
      end
      radio_button = @template.radio_button(@object_name, method, tag_value, options.merge(:object => @object, :help => help))
      selections << boolean_field_wrapper(
                        radio_button, "#{@object_name}_#{method.to_s}",
                        tag_value, value_text)
    end
    selections    
    field_name, label, options = field_settings(method, options)
    semantic_group("radio", field_name, label, selections, options)    
  end

  def check_box_group(method, values, options = {})
    selections = []
    values.each do |value|
      if value.is_a?(Hash)
        checked_value = value[:checked_value]
        unchecked_value = value[:unchecked_value]
        value_text = value[:label]
        help = value.delete(:help)
      else
        checked_value = 1
        unchecked_value = 0
        value_text = value
      end
      check_box = @template.check_box(@object_name, method, options.merge(:object => @object), checked_value, unchecked_value)
      selections << boolean_field_wrapper(
                        check_box, "#{@object_name}_#{method.to_s}",
                        checked_value, value_text)
    end
    field_name, label, options = field_settings(method, options)
    semantic_group("check-box", field_name, label, selections, options)    
  end
end

Personally I think they are a terribly underused aspect of the Rails framework. Anyway, stepping through what we’ve got here. We inherit from ActionView::Helpers::FormBuilder and then begin overriding the various tags that will be called within a form_for. All we do for most methods is call field_settings followed by wrapping. In the method field_settings we set the name of the field to the standard rails convention like person_first_name (@object is created for us automatically by form_for so we don’t need to worry about it here). Next we set the label text to display for this form input, it will default to something sensible (generally the name of the field you are generating the input for) or you can override it per input by passing :label in as an option. And finally, we check if you have passed :required => true in and if so we set a required class so we can style it differently. All the relevant info gets returned, so we can pass it into the wrapping method.

So where exactly is wrapping? I’ve moved it out into a helper, as I wanted to use this functionality in regular form_tag calls as well as form_for. So take a look in semantic_form_helper:

module SemanticFormHelper

  def wrapping(type, field_name, label, field, options = {})
    help = %Q{#{options[:help]}} if options[:help]
    to_return = []
    to_return << %Q{ }
    to_return << %Q{#{label}#{help}} unless ["radio","check", "submit"].include?(type)
    to_return << %Q{}
    to_return << field
    to_return << %Q{#{label}} if ["radio","check"].include?(type)    
    to_return << %Q{}
  end

  def semantic_group(type, field_name, label, fields, options = {})
    help = %Q{#{options[:help]}} if options[:help]
    to_return = []
    to_return << %Q{}
    to_return << %Q{#{label}#{help}}
    to_return << %Q{}    
    to_return << fields.join
    to_return << %Q{}
  end

  def boolean_field_wrapper(input, name, value, text, help = nil)
    field = []
    field << %Q{#{input} #{text}}
    field << %Q{#{help}} if help
    field
  end

  def check_box_tag_group(name, values, options = {})
    selections = []
    values.each do |item|
      if item.is_a?(Hash)
        value = item[:value]
        text = item[:label]
        help = item.delete(:help)
      else
        value = item
        text = item
      end
      box = check_box_tag(name, value)
      selections << boolean_field_wrapper(box, name, value, text)
    end
    label = options[:label]
    semantic_group("check-box", name, label, selections, options)    
  end      

end

There are 3 cases to look at initially. Wrapping a normal input, wrapping a boolean input (like a check box), and wrapping a group of check boxes. For wrapping a normal input, we create a label on the left and insert the field into a div on the right. I’ve got the boolean one there for the “remember me?” type of scenario on a login page, where it looked to make more sense to have the label to the right of the checkbox rather than the left. And finally, wrapping a group of elements which isn’t handled at all well in the current Rails setup. Overwhelmed yet? Let’s just look at how you use it then:

<% form_for @document do |f|
  field_set_tag "Form Details" do %>
    <%= f.date_select :date, :required => true, :help => "date the something happened" %>
    <%= f.text_field :number, :required => true, :help => "the reference number for this thing" %>
    <%= f.select :external_id, [["Choose an option...",""]] + @externals.map{|c| [c.name, c.id]}, :required => true, :label => "options", :help => "select something from the list" %>
    <%= check_box_tag_group "document[other_items][]", @others.map{|u| { :value => u.id, :label => u.description }}, :label => "including these?", :help => "tick the whatever boxes are appropriate for this&nbsp;thing" %>
    <%= f.text_field :name, :help => "what was Willis talkin' about?" %>
    <%= f.check_box :list, :label => "mailing list", :help => "can we send you a bunch of spam?" %>
    <%= f.submit_and_cancel("save", "cancel") %>
<% end %>

You’ll see we can pass in :required => true to visually identify required fields to the user. If we don’t like the form name (like the generic “list” attribute, then we can override with :label =>. And if there is additional contextual help to provide, we’ve got :help =>. We’ve also got a pretty way of showing a selection of check boxes with check_box_tag_group, but you’ll have to specify the field name yourself. I’ve also put a convenience method in called submit_and_cancel that takes the text for a submit, and cancel button respectively. Catching the cancel action is up to you though.

And voila! The finished product. Any problems with it, please let me know or fork and fix/pull request on github. I’ve tested it on Safari 3, Firefox 2/3, and IE7. No idea what it looks like on IE6 just yet.

UPDATE: It’s now a plugin, sexy and semantic forms are now available as a plugin

Useful Flash Messages in Rails

Fri, 11 Jul 2008 09:00:00 GMT

Inevitably somewhere in your rails app you display flash messages to your users to inform them that an action has (or hasn’t) taken place. Sometimes they need to provide more info, maybe you’ve just created some new information for them. Why make them sit around, or wonder where they need to go next when you can take them straight to it in the message itself?

I’ve ripped this code out of a project I’ve been working on and made it a little more generic. Initially I was going to just insert a link in the flash message, but as I was rightly pointed out by my pair and elegant coder extraordinaire, that would mean I’d be polluting my controller with logic and content that should be handled by the view. How do we solve a problem like pollution?

First, we updated the controller so that the flash message now looked something like this:

flash[:error] = "Username and password do not match. If you have 
                   forgotten your password you can %s"

The %s is there to use a string substitution later. If you wanted to insert your link somewhere else, move the %s. Next, we created a new key in flash to hold our additional information (the link path and text):

flash[:error_item] = ["reset it&nbsp;here", forgot_path]

Quite simply, it’s an array with the first item being the text and the second the path. Now for handling it within our view, here’s what I’ve got in application_helper.rb:

FLASH_NOTICE_KEYS = [:error, :notice, :warning]

  def flash_messages
    return unless messages = flash.keys.select{|k| FLASH_NOTICE_KEYS.include?(k)}
    formatted_messages = messages.map do |type|      
      content_tag :div, :class => type.to_s do
        message_for_item(flash[type], flash["#{type}_item".to_sym])
      end
    end
    formatted_messages.join
  end

  def message_for_item(message, item = nil)
    if item.is_a?(Array)
      message % link_to(*item)
    else
      message % item
    end
  end

The reason for the constant is that I don’t use just :error and :notice, I’ve also got :warning for times when something needs action but not because of something the user has done wrong (I don’t want to make them feel bad when they’ve not had the opportunity to be good!). In flash messages I exit out on the first line if we don’t have content to process for the flashes I expect to output (:error, :notice, and :warning) otherwise I loop over each and create a div to contain the message. The class on the div will be either error, notice or warning so you can style it properly. We defer working out the content to message_for_item

In message_for_item I check if the input is an Array, and if so I use the build in string substitution method to insert the link in the relevant place. As you may notice, I’ve called splat on item by putting an asterisk in front of it. That means your array can essentially just be the parameters you’d pass in to link_to, allowing you to add additional classes or options if you wish. If it’s not an array, I skip the link to and just to the substitution. This will handle traditional flash messages as well as some that might want substitution of a string or other object. Wherever you’d previously inserted your flash messages, now you call:

<%= flash_messages%>

and the end result is something like this:

So what else could you do with this? Well we extended it to be a little more intelligent based on the object that was passed in. You could also use it as part of a before filter if you’ve got flash messages that are relatively similar across actions on controllers. Just put %s in the bit to substitute, and then at the relevant part of your action you can insert the a string into flash[:error_item] or the appropriate key, and have it displayed. Like this:

before_filter :set_message, :only => [:create, :update]

  def create
    @order = Order.create!(params[:order])
    flash[:notice_item] = "#{@order.items} items" 
  end

  def update
    @order = Order.find(params[:id])
    @order.update_attributes(params[:order])
    flash[:notice_item] = "#{@order.items} items" 
  end

  private
    def set_message

      flash[:notice] = "Thank you, we have updated your order with %s" 
    end

I hope it helps. Coming up next, my sexy form builder!

Make your own IM bot in Ruby, and interface it with your Rails app

Thu, 26 Jun 2008 09:00:00 GMT

In a super secret project I’m currently working on, I’ve been looking for ways of making it easier for people to interact with the system without the need to log in to the website. That’s included the obvious things like having a RESTful API so they can put their own services and interfaces on top, but that only works for developers or 3rd party application providers. What about your average Joe on the street, how come they get forced into having to log in to the site to update their data, etc.? Why not provide a means of carrying out simple tasks in an application they probably already have? And so an Instant Messaging interface was designed to send a instruction to a robot, and it’s relatively simple to get setup.

The best thing about it is that we help give more control and time back to the user, hopefully making the system more appealing to use. No more breaking your train of thought while you go log into a site to check something, just a quick message to a bot and you can forget about it. Or conversely, you wont defer the task because the overhead in writing a reminder is possibly more than the time it would take to just do it. And for those fans of the Getting Things Done (GTD) approach to task management, it means a whole range of tasks can be suddenly just “get done” in the process phase

So how do we give such amazing power and flexibility to our users? First you’re going to need to install the xmpp4r gem which at the time of writing doesn’t seem to play nice with the new version of rubygems (I think it’s to do with the way new rubygems preserves permissions). The problem appears to be fixed in version 0.3.2.99, but only 0.3.2 is available as a gem. So in the interim, we are going to have to download it directly from the git repository and build it ourselves:

git clone git://github.com/ln/xmpp4r.git xmpp4r
cd xmpp4r
rake gem:install
sudo gem install xmpp4r-simple

And now some ruby code. Connecting is straight-forward:

require 'rubygems'  
require 'xmpp4r-simple'
messenger = Jabber::Simple.new('my-bot@gmail.com', "bot-password")

As is sending a message:

messenger.deliver("a-real-person@gmail.com", "Why hello there Mr. Person, your bot is here now!")

If you wish to have your service sit around and respond to messages, then something you’ll need something like the following:

while true
  messenger.received_messages do |msg|  
    puts msg.body  
    messenger.deliver("a-real-person@gmail.com", "Got your message, thanks!")  
  end  
  sleep 2  
end

Now just to point out for those that aren’t paying close attention, the above code does the following:

Creates a loop that we will continually go over
Call received_messages and pass any messages into a block, iterating over each one at a time
Stop processing for 2 seconds so the system can take a break and we don’t use up all of the resources

Of particular importance once again, I’ve created an infinite loop here to listen to incoming messages. DO NOT put this code in a rails app, this is the kind of process that needs to be handled outside of rails as a supporting but background task. If you try and kick it off via rails it will process indefinitely and tie up one of your mongrel instances until it dies and likely degrade the performance of your site in the process.

That’s all well and good, but wasn’t the whole point of this to give our users a more convenient way to interface with our site and their data? Let us have a look a a slightly more useful implementation:

require 'rubygems'  
require 'xmpp4r-simple'
messenger = Jabber::Simple.new('my-bot@gmail.com', "bot-password")
while true
  messenger.received_messages do |msg|
    user = User.find_by_im_name(msg.from)
    if user
      case msg.body
      when /^help /i
        messenger.deliver(msg.from, "Valid commands are......")  
      when /^status /i
        user.status = msg.body.sub(/^status /i)
        user.save
        messenger.deliver(msg.from, "Thanks #{user.first_name}, your status has been updated")  
      when /^balance\?/i
        messenger.deliver(msg.from, "#{user.first_name}, your current remaining balance is #{user.remaining_balance}")  
      else
        messenger.deliver(msg.from, "Sorry #{user.first_name}, I didn't understand that. Message me with 'help' for a list of commands")  
      end
    else
      messenger.deliver(msg.from, "Sorry, but we've not got this account registered on our system. Sign-up or update your details at http://www.mysite.com/")  
    end    
  end  
  sleep 2  
end

The easiest way to have this run now is to call it via script/runner so that we can get access to our ActiveRecord models and interface with the underlying data. All you need to do is kick this off with an init script, setup something like god for process monitoring to ensure it stays alive and keeps within some same memory and CPU constraints.

Ruby and Microformats

Thu, 19 Jun 2008 09:00:00 GMT

Heard about microformats ? Want to know how to consume them within your rails app? It’s a suprisingly simple task. But why would you bother? Well lets take a somewhat practical example. What if on your site you wanted to include a list of upcoming events that you were either attending or might be of use to your users? Say for example, events in the UK for the next 30 days

The first thing you need to do, is go grab mofo

sudo gem install mofo

And now include it in your ruby/ruby on rails application:

require 'mofo'

Next, find the URL of the page you want to consume that is exposing it’s data as a microformat (read the microformats website for various formats that are available and details on how they are implemented). And within our controller method, we will go and fetch the appropriate information from Upcoming

@events = hCalendar.find 'http://upcoming.yahoo.com/search/?quick_date=next_7_days&search_placeid=DevLebebApj4RVbtaQ&rt=0'

And within our view we could do something like the following (ignore the lack of partials and other useful things, this is just for demonstration purposes):


<% @events.each do |event| %>
  
    <%=event.summary%>
    <%=event.location%>
    <%=event.dtstart.strftime("%d %B")%>
  
<% end %>

Of course, being good little net citizens we should probably also make the list into a microformat too just in case someone else wants to try and consume it from our site, so the addition of a few class attributes and a title tag or two will sort that out:


<% @events.each do |event| %>
  
    <%=event.summary%>
    <%=event.location%>
    "><%=event.dtstart.strftime("%d %B")%>
  
<% end %>

Keep in mind, the current implementation will send off a request to upcoming.yahoo.com every time someone loads your page and could seriously harm performance, I’d recommend caching the results either to file or directly into a model/table and then having a process that regularly checks and updates the data at a certain interval.

The possibilities here and endless, and you don’t have to consume and re-display but you could create your own mashup for your personal use. Many shopping sites now include review information as a microformat, TripIt makes all of my itineraries available the same way. My recent interest has been spurred on by a site I’m working on where most of the data will be available as a microformat, hopefully letting 3rd parties develop uses for the site that I’d never imagined.

Bulk insertion of data with ActiveRecord

Wed, 18 Jun 2008 09:00:00 GMT

Apologies to all for the extended hiatus, I was in the US for a month on holiday… and then I just got lazy. Anyway, I’m back and plugging someone else’s extension. I came across ActiveRecord Extension last night, and was quite frankly dumbfounded that 1) I hadn’t come across it before, and 2) More people weren’t using it. In short, it will let you use ActiveRecord to batch insert multiple rows in a single query, rather than looping over the Model#create method and getting all the overhead that comes with it (and the hundred insert statements).

Zach Dennis has written a great little plugin called ActiveRecord::Extensions which makes the bulk inserts almost as painless as your regular create.

First, install the gem:

sudo gem install ar-extensions

Include it in your app (you could put it in environment.rb if you’re going to use it a lot, for now I’ll place it in my model definition in user.rb:

require 'ar-extensions'
class User
end

Then to use it, it really couldn’t be more straightforward. Use the following in your controller or rake task to import your data:

fields = [:first_name, :last_name, :email]
data = [["glenn", "gillen", "foo@bar.com"],
        ["john", "jones", "jim@bar.com"],
        ["steve", "smith", "bar@foo.com"]]

User.import fields, data

And we’re done, 3 new rows have been inserted into the users table, with just the single query. Any more questions, the RDocs are here

Monitoring Backgroundrb with God

Wed, 09 Apr 2008 09:00:00 GMT

I mentioned yesterday that I’d elaborate on how to extend our app.god config so that god process monitoring automatically becomes aware of our changes. Well for those that can’t wait, Graham who I pair with on the majority of my work beat me to the punch with with his post on Monitoring BackgroundRB with God. And at the end of the day English is his native language, so it’s probably an easier read (I speak Australian).