Duck Typing

I learnt how to program in Ruby, and as we all know it's a very flexible language. Recently I've been doing a lot of stuff in C# on windows, and a lot more stuff in Objective-C on the iPhone. Something finally clicked for me, when I was using these languages, and that was Duck Typing.

Ruby, unlike the C style languages, couldn't care less about what type of object it is dealing with. Now before you start, I will repeat, it couldn't care less about what type of object it is dealing with.

What Ruby cares about is if object responds to the method you're sending it. In Ruby there is even a respond_to? method to assert this. i.e.

1.respond_to?(:to_s) #=> true
1.respond_to?(:foo_bar) #=> false

So you can have two objects, of totally differing types, and instead of asserting type like you might in say C#, you can instead check that the object responds to a method. The great thing about this, is that if it doesn't and you want it to, you can use Ruby's meta programming to dynamically inject that method into that object. For instance

unless 1.respond_to?(:foo_bar)<br />   1.class.class_eval do<br />      def foo_bar<br />         self * 100<br />      end<br />   end<br />end

1.foo_bar #=> 100
2.foo_bar #=> 200
30.foo_bar #=> 30000

12.2.foo_bar
#=> NoMethodError: undefined method `foo_bar' for 12.2:Float

So we've used class_eval to dynamically inject the method foo_bar in the class of 1(Fixnum), and so now all instances of Fixnum will respond to that method. We've never even checked it's type, we don't care, all we know is that we want it to respond to the method foo_bar and now it does. Obviously our Float class doesn't have this method hence the reason that 12.2 has raised the undefined method error. Any guesses on how to make this work :D, yeah that's right, class_eval and respond_to? will do it, just like we did with Fixnum.

So in summary what is the point of Duck Typing? Why not just check the class, and respond with what we as coders know it can and cannot do(or think we know it can do)?

Well, seriously why do you care what class it is? When what you really wanted to know is, whether it's going to respond to a method? Sometimes class and type is important, and obviously those features are there and should be used when class is important, but sometimes you just need to stop and ask yourself.

Do I can about type or do I just want to know if I can execute a method on this object?

Functional Ruby methods

Ruby is a great language and normally I'd roll it in a object oriented fashion, however I've just started looking at Haskell, and thought that lambda could give me something similar to Haskell functions in Ruby. albeit without a ton of Haskell's features.

So here are two examples, the first is normal OOP Ruby

b = Time.now
class Integer
  def main
    self * self
  end
end
1000000.times{ |i| i.main }
puts "Time: #{Time.now - b}"

On my machine this returns "Time: 1.115471"

Here is a functional style version.

b = Time.now
main = lambda { |x| x * x }
1000000.times &main
puts "Time: #{Time.now - b}"

First thing to note is that it's only 4 lines of code, not 8. Second thing is that it returns the following to the terminal:
"Time: 0.960359"

That's 0.155112 faster, just over 15% faster in computing a simple algorithm like this. Of course this is where functional programming is meant to shine, this is simply an experiment to see if I could do this is Ruby, it is hardly a well tested benchmark, and the results are not all together unexpected, but it's cool in any case.

Rending your XML as HTML with XSLT in Rails

I had a need to convert XML services that my rails app was providing into customizable html widgets tht could then be in-jested by some sort of server side includes(like NGINX's SSI). So I needed to use XSLT.

When the W3C wrote the XML specification they also developed the Extensible Stylesheet Language for Transformations. XSLT provides a powerful, flexible language for transforming XML documents into something else. In this case, we're going to use it to create HTML documents.

So to quickly look at how we're rendering xml currently.

def show
  @event = Event.find(params[:id])
  render :xml => @event
end

OK so we are simply rendering only xml back from this request. Now of course we can react to any registered mime-type we want, obviously HTML is one of those. So we do something like....

def show
  @event = Event.find(params[:id])
  responds_to do |format|
    format.html  
    format.xml { render :xml => @event }
  end
end

So, I'm going to assume that you've seen this responds to block before and you know that it's just going to render the show.html.erb template in our views, when html is requested.

Installing Ruby's XSLT Library

I'm on Mac OS-X 10.5.2 and haven't tested this install on anything else, but it's pretty simple really, unfortunately it's not a gem, but hey, it's not that hard

First you'll need to download the library, you can get it from here

Unzip that guy and in your terminal navigate to that directory, then execute the following commands(You'll need Make installed so ensure you've XCode installed on OS-X, or some sort of GCC/Make):
ruby extconf.rb
make
make test
make doc
sudo make install

Fire up irb and ensure you return true from require 'xml/xslt' if you get a false, the library hasn't installed properly, you can probably find help at http://greg.rubyfr.net/pub/packages/ruby-xslt/files/README.html

Getting Rails to render:

Firstly, include your new friend in environment.rb
require 'xml/xslt'

In my application controller I've added a private method

def xslt(_xml, _xslt)
  xlt = XML::XSLT.new
  xlt.xml = render_to_string :xml => _xml
  xlt.xsl = _xslt
  xlt.serve
end

Now in your controller method(I'll use the example from above)

def show
  @event = Event.find(params[:id])
  respond_to do |format|
    format.html { render :inline => xslt(@event, "#{RAILS_ROOT}/xslt_template/show.xslt") } 
    format.xml { render :xml => @event }
  end
end

Create an XSLT Style

You're of course going to need XSLT styles to apply to pages.
I'll start with the XML I'm using. It's just rendered by the show method from above:

<event>
  <created-at type="datetime">2008-04-23T18:36:28+10:00</created-at>
  <date type="date">2008-04-23</date>
  <id type="integer">1</id>
  <location>Camperdown Park</location>
  <title>Cardboard Tube Fighting</title>
  <updated-at type="datetime">2008-04-23T18:36:28+10:00</updated-at>
</event>

And this is the XSLT template I'll use to style this.

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="html" />

  <xsl:template match="/">
    <xsl:apply-templates select="event/location" />
    <xsl:apply-templates select="event/title" />
  </xsl:template>

  <xsl:template match="title">
    <h4>
      <xsl:value-of select="." />
    </h4>
  </xsl:template><br />
  <xsl:template match="location">
    <h1>
      <xsl:value-of select="." />
    </h1>
  </xsl:template>
</xsl:stylesheet>

Smile like a bandit!

terminal: script/server
Navigate to the path of your method and voila you've just applied an XSLT style to your XML stream dynamically.

Next is for me to roll this into a Rail templating language... But that's another post.

Mocking and Stubbing in rSpec

I program in Ruby. A lot. I've recently found myself writing applications to provide simple web services to flash applications. We've pretty well standardized on using JSON as our preferred format at Snepo, so I've found it useless attempting to build and delivery anything without using some sort of TDD.

Welcome rSpec to my world, and it adds in a level of communication between myself and the involved parties about what a service should do, that I'm not sure any other framework does. For instance, we can begin specifying behaviors that the controller should return.
I might have a service that finds me all users who've been active in the last 24 hours. So I'd specify, like follows.

describe "Users Controller", "find_recent action" do
 it "should find all users who've been active in the last 24 hours" do
   c, r = request("/users/find_recent/24")
   c.body.should eql(["some json array of elements"])
 end
end

But! Here is our first problem with outside in development, we don't have a any methods in a User model yet! Now we could go off and build some, but this behavior might change as we move forward and in any case, we should test those methods with their own tests, this is testing the controller class after all. So why not try to get as much of this working how we want now. Well we can.

Hello Mocks and Stubs!

Mocks and Stubs confused me for a long time. The official definition in rSpec says: Mock objects are imitation objects that give you declarative control over their behaviour in the course of the execution of an example

I found this really confusing so I'll try to explain it, in my own words.
A mock allows you to send a message to an object(including a class, a class is an object after all) that does not yet exist( that is the message/method does not yet exist ). The rSpec framework looks out for the method that your test to call this object, and then returns what you specified in your test. If it is never called it considers that the test has failed. That is, a mock is a test in itself, a stub is not. A stub simply substitutes itself for the real object. So to flesh out the above example with a mock.

describe "Users Controller", "find_recent action" do
  it "should find all users who've been active in the last 24 hours" do
    @users = mock("A list of users")
    User.should_receive(:find_all).with(24).and_return(@users)
    c, r = request("/users/find_recent/24")
    c.body.should eql(@users.to_json)
  end
end

What we are doing here is creating a new mock object(@users) so we have something to return from our mock of the static method find_all. That happens in the line below, we tell rspec that it should_receive a message (:find_all) for a class called User, and when it does receive that message to return the mock object that we created above for the controller to keep on using it.
If we just wanted to stub that, i.e. if we didn't care if it got called, but if it does we'd better return something, we'd use: User.stub!(:find_all).and_return(@users).

There is one small misnomer in that whole mocking stubbing framework in rSpec, and that is @users = mock("A list of users"). This is not a mock, if it's not used rSpec doesn't care, there is no expectation placed on this object, to me this should be something like stub_object, in any case, that's a little gottcha albeit a linguistic one.
Now you see, you can get to it from the outside in this time and you can get all the model method's that you'll need sorted before your write a scrap of code in your models.
Oh and just so you know, your controller method might look something like this( in Merb ).

def find_recent
  users = User.find_recent(params[:duration].to_i)
  render_text users.to_json
end

Ruby's Method Missing

I love programming in Ruby. Sometimes I need to do stuff in other languages, and for all intensive purposes, it's fine. I've no problem firing up Visual Studio and hacking out a bit of C#. But curly braces and brackets around every function aside and I think Ruby offers something that is often overlooked in lots of other languages. Smalltalk introduced the idea some time ago with doesNotUnderstand, but I'll explain it in the context of Ruby.

In Ruby everything is an object:

"A String".class => String

1.class => Fixnum.

Let me repeat everything is an object

1.class.class => Class

And from the wonderful Programming Ruby book by Dave Thomas in reference to Ruby's class Object:

"Object is the parent class of all classes in Ruby . Its methods are therefore available to all objects unless explicitly overridden." -- GetItHere

One of the Object methods(functions are called methods in Ruby) which are automatically inferred to all objects is method_missing. Method missing is where your method request will end up if the method you called cannot be found.

Here is a really simple trivial example:

-----------------------------------------------------

class Fixnum

def method_missing(method, arg)

puts "Called: #{method}"

return self * arg

end

end

puts 10.mutiply_by(100)

----------------------------------------------------

--------------------------

OUTPUT:

Called: multiply_by

1000

-------------------------

Let's just explain this quickly. It's trivial and you'd never bother doing this but it does explain the concept. We're essentially re-writing the method_missing method for the Fixnum class. This will not effect the method_missing class in any other class, including most importantly object.

You can prove this to yourself by changing the 10 to a 10.2, you'll now throw an error explain that multiply_by is not a method of the Float class, since 10.2 is a float not a Fixnum.

Anyhow we digress, back to the code. method_missing takes at least 2 args, the first one is always the method that was attempting to be called, in the case of our Fixnum method_missing it's called method, and I'm also only assuming one argument from the caller. But is could easily take an array of args even a proc object.

So we write to stdout using puts to log what method was being called, and then simply take the args and multiply it by self, in this scope that is 10. Hence we get 1000 since 10*100 == 1000

But of course this is stupid, you'd never do this. The real power of method_missing comes in when you want to dynamically deal with methods. Creating API's for instance. You can now dynamically catch(rescue is Ruby land) anything that isn't a method. You can log it and return a proper message. All in 5 lines of code.

---------------------------------------------

class User

....accessors and methods

private

def method_missing(method, *args)

puts "Unavailable method called on #{self.class}: #{method}

puts "With args: #{args.inspect}"

return "Method: #{method} does not exist"

end

end

---------------------------------------------

This will allow methods called on the user object that do not exist to simply return you a text string, rather than raising an error.

But I want to raise an error you say, I want to log it and then raise the error. Fine, no problems, change the return line to:

super(method, args)

You'll now call the original method_missing from the object class after you've executed puts. In essence you get to do stuff before your error is raised. Cool ehh.

You'll see method_missing splattered all over Ruby code, and there are some outstanding uses of it out there.

Here's an example from Rails:

Check out routing.rb in Rails core for example. method_missing is used to generate all those named routes.

So in your routes table when you name a route like so:

map.manage_user "some/nicely_formated_url", :controller => "blah", :action => "blah"

What actually happens is method_missing grabs that, and calls a method add_named_route, which in turn adds your route with the custom name to the hash called named_routes and also to an array called routes which is later used to determine where URLs are to be routed to.... Wicked!