Barking Iguana

My main concern about returning explicitly is readability. It's a very subjective thing, but in general whenever I see an unnecessary return statement my internal WTF counter increments.

Less subjective though, it has been pointed out that returning explicitly is slower.

Benchmarking in Ruby is easy. Here's how:

require 'benchmark'

def explicit
  return "TEST"
end

def implicit
  "TEST"
end

n = 100_000_000
Benchmark.bmbm do |x|
  x.report("Explicit return") { n.times { explicit } }
  x.report("Implicit return") { n.times { implicit } }
end

And here are the results of this particular benchmark:

Rehearsal ---------------------------------------------------
Explicit return  50.380000   0.210000  50.590000 ( 51.000510)
Implicit return  36.200000   0.100000  36.300000 ( 36.454038)
----------------------------------------- total: 86.890000sec

                      user     system      total        real
Explicit return  47.650000   0.070000  47.720000 ( 47.744167)
Implicit return  35.900000   0.070000  35.970000 ( 35.985493)

This shows that while returning explicitly is slower, like the to_proc hack it's not slow enough to matter. You need to return a huge number of times to see any significant difference.

Does this change my mind? No. Returning explicitly is still ugly.

Update: The above benchmark was run on Ruby 1.8.6. Tom Ward has provided similar benchmarks for Ruby 1.8.7, 1.9 and jRuby 1.1.6 (using n = 10,000,000) which show that the cost of explicitly returning on these platforms in negligible. Still ugly though.

The stack trace is one of the most valuable pieces of information you can have when trying to debug a problem. It tells you what line of code was being run when an error was thrown and gives you an idea of the execution path that lead to that line of code being run.

Quick plea then. Please don't do this:

def foo
  do_something
rescue => e
  puts "Problem: #{e}"
  raise e
end

This will start a new stack trace at raise e. If I rescue this further up the stack there's no indication of where the problem was originally encountered - I just get pointed at your error handling code. Precious information, gone.

Do this instead:

def foo
  do_something
rescue => e
  puts "Problem: #{e}"
  raise
end

Note the lack of argument in the call to raise. This tells Ruby to re-raise the last exception. The stack trace remains intact and debugging can continue unhindered. Glory be!

Not just for Ruby this time. This applies to pretty much every programming language under the sun.

Don't use unnecessary control statements to determine whether you want to return true or false.

def foo
  if some_boolean && other_boolean
    return true
  else
    return false
  end
end

You should do this instead:

def foo
  return some_boolean && other_boolean
end

It's very very rare that I ever have to return an explicit true or false. This should be a warning sign.

Of course, in Ruby you don't need to return explicitly so you should do this:

def foo
  some_boolean && other_boolean
end

Ruby returns the value of the last line executed.

Don't do this:

def foo
  value = Foo.first(:conditions => { :label => "bar" })
  return value
end

Do this instead:

def foo
  Foo.first(:conditions => { :label => "bar" })
end

Here are the steps involved in using Twitter to authenticate using OAuth... because I wanted this post a few days ago and couldn't find it.

Install the required gems.

sudo gem install json oauth

Set up your application at http://twitter.com/apps. Make sure you choose Browser as your application type and check the box saying that you want to use Twitter for login.

Note that if you make a mistake on the new application form it will default to Client for that application type and uncheck the login box. Make sure you set these correctly!

Here comes the magic. Despite the hugely complicated examples found elsewhere only two actions are required. One sets up the authentication request (the login action) and one handles the authentication being completed (the callback action). If you've used OpenID for authentication before this setup should be pretty familiar.

Your login action will look something like this:

# consumer_key and consumer_secret are from Twitter.
# You'll get them on your application details page.
oauth = OAuth::Consumer.new(consumer_key, consumer_secret,
                             { :site => "http://twitter.com" })

# Ask for a token to make a request
url = "http://whatever.com/login/complete"
request_token = oauth.get_request_token(:oauth_callback => url)

# Take a note of the token and the secret. You'll need these later
session[:token] = request_token.token
session[:secret] = request_token.secret

# Send the user to Twitter to be authenticated
redirect_to request_token.authorize_url

Your callback action will look something like this:

# Your callback action will look something like
# this:
#
# Your callback URL will now get a request that contains an 
# oauth_verifier. Use this and the request token from earlier to 
# construct an access request.
request_token = OAuth::RequestToken.new(oauth, session[:request_token],
                                        session[:request_token_secret])
access_token = request_token.get_access_token(
                 :oauth_verifier => params[:oauth_verifier])

# consumer_key and consumer_secret are from Twitter.
# You'll get them on your application details page.
oauth = OAuth::Consumer.new(consumer_key, consumer_secret,
                             { :site => "http://twitter.com" })

# Get account details from Twitter
response = oauth.request(:get, '/account/verify_credentials.json',
                         access_token, { :scheme => :query_string })

# Then do stuff with the details
user_info = JSON.parse(response.body)
# Like find the person that logged in...
Person.find_by_twitter_id(user_info["id"])

If after implementing this you keep getting 401 Unauthorized errors, check that your application is set to browser mode in the Twitter configuration options.

Working with arrays in Ruby. Don't do this:

index = 0
for item in array
  index += 1
  puts "Item #{index}: #{item.inspect}"
end

Do this instead:

array.each_with_index do |item, index|
  puts "Item #{index}: #{item.inspect}"
end

There are a bunch of handy methods like this. Read the Enumerable documentation and make your code that little bit more readable.

ActiveRecord provides a bunch of useful callbacks which will be run at various stages during the lifecycle of an ActiveRecord object. There are lots of ways to define these callbacks, and the easiest way is something like this.

class Widget < ActiveRecord::Base
  def after_save
    # What did this code do again?
  end
end

Seems harmless enough, right? Sure, as long as you're writing a throwaway prototype. Try adding another after_save callback, or implementing the callback in a subclass. Try coming back to the callback after 6 months and trying to work out what it's meant to be doing. That way insanity lies.

Name your callbacks expressively and you'll reap the immediate benefits of more readable code and easier implementation. You'll also have a decent indication - the method name - of what the callback was meant to do when you come back to the code in 6 months.

class Widget < ActiveRecord::Base
  after_save :add_widget_to_bill_of_materials
  def add_widget_to_bill_of_materials
    # No need to guess what this method does,
    # it's right there in the name!
  end
end

Sometimes a function behaves differently based on it's inputs. Consider, for example, calculating the absolute value of a number. If the number is less than 0 then the result is -1 * INPUT. If the number is greater than or equal to zero then the number is the same as the input.

This can be accomplished in Erlang using predicate guards: conditions on the inputs which are defined just after the argument list of a predicate.

-module(maths).
-export([abs/1]).

abs(X) when X < 0 -> -1 * X;
abs(X) -> X.

Of course Erlang does already provide a math module which exports abs. This is just a simple example of how to implement guards. It's also the reason that my module is called maths instead of math. Ick.

At RailsConf Europe it quickly became obvious that while there's a bunch of really cool things happening in the Ruby and Rails worlds just now, the current hotness is all about Erlang. I decided to give it a whirl so I bought a few screencasts and the Programming Erlang book and played for a few hours.

I very quickly found out that Erlang is incredibly similar to Prolog and when I commented on this it turned out that Erlang was originally a Prolog descendent intended for high-availability, high-performance distributed applications. That's great for me - I spent the best part of three years working with Prolog as part of my AI course!

To see if I could remember how to reason with Prolog I decided to implement some fairly trivial predicates - the sort of thing that you'd use at the start of a degree course to introduce Prolog, for example.

A brief introduction to graphs

Also know as "here comes the maths bit..."

For those who haven't covered graph theory as part of mathematics, graphs aren't bar charts or pie charts. The clue's in the name: those are charts. A graph is a collection of vertices and edges that join them. Every played join the dots? That's a close enough comparison.

There are two kinds of graphs: directed and undirected. For directed graphs the direction of the edges matters while for undirected graphs it doesn't.

If we have an directed graph with two vertices A and B, and an edge A → B, there is no edge between B and A (above). In an undirected graph there is one (below).

To play with Erlang, I'll make an arbitrary choice and use a simple undirected graph like the last of the two graphs above. I'll ask Erlang to check if there's a connection between two vertices in the graph.

Less Mathematics, More Erlang

First, let's decide how to represent the graph. In English I'd describe the graph like this:

1. There's an edge between vertex A and vertex B
2. There's an edge between vertex B and vertex C
3. There's an edge between vertex C and vertex A
so I should do the same in Erlang to keep it clear.

Graph = [
  { edge, 
    { vertex, a },
    { vertex, b }},
  { edge, 
    { vertex, b },
    { vertex, c }},
  { edge, 
    { vertex, c },
    { vertex, a }}
].

With a graph to reason about, how do I decide if two vertices, N and M, are connected? I look at the first edge in the graph and ask "does this edge connect N to M?"

% If there's an edge from A -> B then A and B are connected.
% 
connected([ { edge, { vertex, A }, { vertex, B } } | _ ], { vertex, A }, { vertex, B }) -> yes;

Since I'm considering an undirected graph edges that connect N to M can also be defined as edges that connect M to N, so I also have to ask "does this edge connect M to N?"

% If there's an edge from B -> A then A and B are connected (since we're 
% considering only undirected graphs).
%
connected([ { edge, { vertex, B }, { vertex, A } } | _ ], { vertex, A }, { vertex, B }) -> yes;

If the edge I'm considering meets neither of the above two conditions than possibly the next edge in the graph will match them so discard the first edge and repeat the above with the next vertex.

% If the edge currently being examined doesn't join the vertices, try 
% looking through the rest of the graph searching for a matching edge.
% 
connected([ _ | Graph], { vertex, A }, { vertex, B }) ->
  connected(Graph, { vertex, A }, { vertex, B });

If we've looked through the entire graph in this manner and there are no edges left to consider, the nodes aren't joined.

% If there are no edges to consider then the nodes aren't joined.
% 
connected([], _, _) -> no.

There are no other cases I can think of so I finish the predicate definition with a period (.) - note that the previous cases had a semi-colon at the end.

Organising Erlang code

Erlang code is organised in modules. I suspect that these act sort of like namespaces, but I haven't dug that deep yet so can't say for sure. In any case, the module name and the name of the file that the Erlang code is stored in should be the same. Since I'm dealing with undirected graphs I've called the module unigraph which makes the filename unigraph.erl. I have to tell Erlang which module this is, and which predicates I want to make available to the outside world so the following code goes at the top of that file.

-module(unigraph).
-export([connected/3]).

Running the code

Change into the directory containing the Erlang file and Launch the Erlang shell by typing erl.

webstc09@MC-S001877 graphs $ erl
Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.5.5  (abort with ^G)

Once in the shell compile the module, setup the graph given above and ask Erlang if some of the nodes are connected.

1> c(unigraph).
{ok,unigraph}
2> Graph = [
2>   { edge, 
2>     { vertex, a },
2>     { vertex, b }},
2>   { edge, 
2>     { vertex, b },
2>     { vertex, c }},
2>   { edge, 
2>     { vertex, c },
2>     { vertex, a }}
2> ].
[{edge,{vertex,a},{vertex,b}},
 {edge,{vertex,b},{vertex,c}},
 {edge,{vertex,c},{vertex,a}}]
3> unigraph:connected(Graph, { vertex, a }, { vertex, b }).
yes
4> unigraph:connected(Graph, { vertex, a }, { vertex, c }).
yes

That's great, but what happens if we ask about a vertex that doesn't exist? Let's ask if { vertex, a } is connected to an imaginary { vertex, z }.

5> unigraph:connected(Graph, { vertex, a }, { vertex, z }).
no

Get the code

The code to the module I've described is available at http://barkingiguana.com/file_download/2.

Confusing tangent

I'm not really sure how to finish up since this post was mainly to help me get to grips with a Prolog-like language again. I look forward to seeing what else I can make Erlang do, and I'll probably post that here too. Prolog just got a lot prettier and a bunch more fun.

If you found this article useful, give me some love over at Working With Rails... because obviously, Erlang has so much to do with Rails.

I've interfaced one of my xmpp4r bots with the Xeriom Networks control panel. I had intended to write a post about it to show how easy it is, but I've been beaten to it. I can, however, offer one piece of advice that will stop the bot dying after a few hours of idling: periodically verify your database connections.

RAILS_DEFAULT_LOGGER.debug "Launching database connection verifier"
Thread.new do
  loop do
    sleep 1800 # Half an hour
    RAILS_DEFAULT_LOGGER.debug "Verifying database connections"
    ActiveRecord::Base.verify_active_connections!
  end
end

Adding the above code to a script will stop database connections getting dropped (or, at least, will reconnect them if it happens).

Love me!

If you've found this article useful I'd appreciate beer and recommendations at Working With Rails.

There's been quite a lot of chat recently about various job scheduling systems and process managers for offlining expensive tasks on the LRUG list. BackgrounDRb, Beanstalk, Starling, BackgroundJob and other similar solutions have been discussed. These systems can be useful, but most of the time they're just adding unnecessary complexity.

One instance where I feel these solutions are unnecessary is where you need to strip data from an external service in a way that's totally disconnected from the HTTP request-response cycle.

Say you want to pull the most recent article from this blog every 15 minutes and create a file that could then be served statically to your visitors. A naive implementation of that functionality would look something like this:

require 'net/http'
require 'hpricot'

barking_iguana = URI.parse('http://barkingiguana.com/')
loop do
  articles = Hpricot(Net::HTTP.get(barking_iguana))
  title = (articles / "div.article a[@rel=bookmark] text()").first
  link = (articles / "div.article a[@rel=bookmark]").first['href']

  # Of course, this should have a real file path in it.
  File.open("/.../.../.../barking_iguana.ssi", "w+") do |f|
    f.write("#{title}: #{link}")
    f.flush
  end

  sleep 900 # 15 minutes
end

Doesn't that look nice? No screwing around with complex tools to handle the scheduling - just run it and it'll go forever.

"Ah," I hear you say, "but what if it crashes?" Well, in the unlikely event that such a simple script does crash I'd have something like God monitoring the processes so it would be restarted. You've got something monitoring your processes anyway (right?) so it should be pretty simple to add another process to that list.

Love me!

If you've found this article useful I'd appreciate recommendations at Working With Rails.

I thought it might be cool to have a control interface that you could talk to using IM, something like the IM client for Twitter.

Initially I was looking at XMPP4R but a little reading pointed out that there's a gem called XMPP4R-Simple. Well, simple is always good so one gem install and 45 minutes later I had a Ruby script that could log in to an XMPP server, listen to (and log) what people said, and respond with a simple message.

#!/usr/bin/env ruby

require 'rubygems'
require 'xmpp4r-simple'

logfile = File.join('..', 'log', "#{File.basename(__FILE__)}.log")
logger = Hodel3000CompliantLogger.new(logfile)

jabber = Jabber::Simple.new "username@domain.com", "password"
sleep 1
jabber.status(:away, "No one here but us mice.")
sleep 1

jabber.deliver("craig@xeriom.net", "I woke up at #{Time.now}.")

loop do  
  begin
    jabber.received_messages do |msg|
      jid = msg.from.strip.to_s
      logger.info "%s said: %s" % [ jid, msg.body ]
      jabber.add(jid) if !jabber.subscribed_to?(jid)
      jabber.deliver(jid, "Nom nom nom.")
    end

    jabber.presence_updates do |update|
      jid, status, message = *update
      logger.info "#{jid} is #{status} (#{message})"
    end

    jabber.new_subscriptions do |friend, presence|
      logger.info "#{friend.jid} #{presence.type}"
      jabber.add(friend.jid) if !jabber.subscribed_to?(friend.jid)
    end
  rescue Exception => e
    logger.error e.to_s
  end
  sleep 1
end

Our own little pet XMPP client. How cute is that?

Quit yo jibba jabba, sucka!

If you've found this article useful I'd appreciate recommendations at Working With Rails.

There are three types of methods in Ruby and I always get them confused. Here, for my future reference, is what I currently think they mean.

Class methods

Methods which can be called directly on a class.

Time.now
Monkey.find(:all)

Instance methods

Methods which can be called on any instance of that class.

@widget.to_s
Time.now.to_f

Singleton methods

Methods which can be called only on a specific instance of that class.

chicken = Chicken.new
class << chicken
  def hide
    # ...
  end
end
chicken.hide