Wildfalcon

In short: This book is good, go buy it.

In “Design Patterns in Ruby” Russ Olsen sets out to cover two distinct goals. First he introduces the idea of design patterns, and secondly he explores how the dynamic nature of Ruby allows patterns to be used with less effort than languages such as Java and C#.

The overview of design patterns is pretty comprehensive, though not a substitute for the GoF book, which is referenced regularly thoughout. Russ does a good job of covering the reasons why patterns are good, and the generaly coding philosophy that lead to them. It’s here that we get a first glimps of one of my favourite things about this book. Not only does Russ clearly present the original GoF ideas and concepts (with due credit given to them) but he add his own ideas, which I think are just as valid.

This is followed by a list of 16 patterns. 13 are from the GoF book, and 3 are new for Ruby. For each pattern he follows the same structure. First a bit of context to explain the general concept, then an reasonably in depth discussion of how to implement the pattern, with code examples. Its in this section that we really get to look at what Ruby adds. Next comes a look at how to use, and not to use the pattern, before finally looking at some examples of where the pattern is used in real world Ruby projects.

The descriptions of the patterns are accurate, and comprehensive, and certainly cover the information you would find in the GoF book, although not all patterns are covered, and the structure he follows is not quite strict enough for this to be a good quick reference book. It’s in the discussions of how Ruby (and dynamic programming in general) adapt the use of the patterns that this book really shines. Always the “tradational” use of the patterns is presented first, and then we get to see how we can adapt this. In some cases the language itself almost renders the pattern unnecessary, the command pattern springs to mind here, which can almost completly be replaced with Procs, lambdas or code blocks. I was very impressed at how Russ clearly explains the advantage of the tradational format too though.

The final 3 patterns (DSLs, Meta-Programming, and Convention over Configuration) were a very interesting addition. I don’t feel its really fair to call them patterns though. They more cover general techniques and are too general to accuratly be called patterns in my opinion. That’s not to say they are not useful, and an strong addition to anyone’s skill set.

The other aspect that shines though this book, is as an essay in teaching programmers used to static languages (Java etc) that Ruby is a fully fledged language, and capable of serious application work. Having been through this process I have finally decided I agree with this thesis, and in fact it was this book that finally helped me make up my mind. Pattern usage (and miss-usage) has long formed the basis of “enterprise” application development, and there is an underlying theme showing that Ruby not only supports patterns, but can make developing enterprise applications (with or without patterns) easier. However this is a double edged sword (isn’t everything) and I would have liked to have seen a bit more attention paid to how Ruby can make things harder, especially if it included some advice on how to mitigate the problems.

I also feel the need to point out that there are a too many errors in the book for my liking. Not big errors, but the occasional two line code example that contains the wrong code. If you have a general idea of what the section is about, it’s easy enough to see whats going on, but if your learning patterns and/or ruby for the first time from this book, it could cause a problem. Having said that I do have an early printing of the first version, and I am sure these issues will be picked up very fast.

Overall I was very impressed by this book, it covered a lot of things I already knew, fixed a few misconceptions I had, and taught me a few new things too.

Bookmark to:

I have been using a lot of polymorphic associations in rails recently. If you don’t know what they are, bear with me and I will explain in a moment. To really use a polymorphic association properly it’s vital to understand interfaces, which should be part of your daily bread and butter toolkit, but in a dynamic language like Ruby they are a conceptual construct, rather than a language enforceable construct, like in Java or C#.

So before I go on about interfaces, let me give you a quick overview of polymorphic associations.

A polymorphic association lets you associate your model to another object, model, entity etc (pick your word, they all mean the same thing really) without knowing its type. Think about a user holding a number of subscriptions, one might be an RSS feed, another a stream of Twitter message (via some fancy new API), and a third a binary feed representing your CPU usage for the last 20 minutes.

If you want to use polymorphic associations with this, you could do it like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class User < ActiveRecord::Base
  has_many :subscriptions
end
 
class Subscription < ActiveRecord::Base
  belongs_to :producer, :polymorphic => true
end
 
class RSSFeed < ActiveRecord::Base
  has_many :subscribers, :as => :producer, :class_name => "subscription"
end
 
class TwitterFeed < ActiveRecord::Base
  has_many :subscribers, :as => :producer, :class_name => "subscription"
end
 
class CPUMonitor < ActiveRecord::Base
  has_many :subscribers, :as => :producer, :class_name => "subscription"
end

At the database level, the subscriptions table will have two columns for the association: producer_type and producer_id. A composite foreign key. A row in the subscriptions table will show something like producer_type = “CPUMoniter” and producer_id = 3. When you call the producer method in subscription it will load the row in the CPUMoniters table with ID 3.

So the polymorphic bit means that the type of thing you’re going to get back when you ask a subscription for its producer is unknown. It might be an RSSFeed, it might be a TwitterFeed, or it might be a CPUMoniter, or possibly anything else you can think of.

More formally, according to Wikipedia (which knows all) polymorphism “is the ability of objects belonging to different types to respond to method calls of the same name, each one according to an appropriate type-specific behaviour.”.

Put in dynamic, Ruby terms, this means I don’t care what I sort of model I get when I ask a subscription for its producer, as long as it goes quack I can treat it like it’s a duck.

This is where interfaces come in. Interfaces specify what I want the returned object to behave like, it could be a duck, or it could be a spaceship or maybe, just maybe, it could be a producer. In fact if you read though the ActiveRecord docs on polymorphic associations, you will find that “interface” is exactly what they call the parameter passed in the :as key of the params hash, and the first parameter to a polymorphic belongs_to association, and even the xxx_type and xxx_id columns in the database. This threw me quite a bit when I first looked at polymorphic associations, you have to declare that the association uses the producer interface, but you don’t have a producers model, or a producers table, or a producers anything for that matter. To my mind, “producers” is the name of the interface that RSSFeed, TwitterFeed and CPUMonitor all have to implement. It could specify that all of them must have a “next_message” method, which will give me (surprise surprise) the next message they produce. If I don’t have something like this, then my code is going to get messy:

1
2
3
4
5
6
7
8
9
10
11
12
13

class Subscription < ActiveRecord::Base
  belongs_to :producer, :polymorphic => true
 
  def print_next_message
    if producer.is_a?(RSSFeed)
      puts producer.rss_message
    elsif producer.is_a?(TwitterFeed)
      puts producer.twitter_messsage
    else
      puts producer.cpu_message
    end
  end
end

Which is just really butt ugly. Its slow to grok to figure out what’s going on, and I don’t even want to think about maintaining that code when I add a CriticalNuclearReactor class that people can subscribe to. If on the other hand, I say that every thing which implements the producer interface must define a next_message method I can push the ugliness into the classes that implement the interfaces.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

class Subscription < ActiveRecord::Base
  belongs_to :producer, :polymorphic => true
 
  def print_next_message
    puts producer.next_message
  end
end
 
class RSSFeed < ActiveRecord::Base
  has_many :subscribers, :as => :producer, :class_name => "subscription"
 
  def next_message
    rss_message
  end
end
 
class TwitterFeed < ActiveRecord::Base
  has_many :subscribers, :as => :producer, :class_name => "subscription"
 
  def next_message
    twitter_message
  end
end
 
class CPUMonitor < ActiveRecord::Base
  has_many :subscribers, :as => :producer, :class_name => "subscription"
 
  def next_message
    cpu_message
  end
end
 
class CriticalNuclearReactor < ActiveRecord::Base
  has_many :subscribers, :as => :producer, :class_name => "subscription"
 
  def next_message
    get_the_bloody_hell_out_of_here_message
  end
end

Just look at how much easier the print_next_message method in subscription is to read. This is good. Also notice how the only time I need to care what the technique for getting a message from a nuclear reactor is when I’m inside the nuclear reactor class, which means I’m already thinking about nuclear stuff. I no longer need to hold that in my stack when I’m working on how subscriptions work. Finally, my subscription model does not need to be changed when I add another producer type. This is important. Very important! As soon as anyone with even a mild case of featuritus gets near your code they are going to want to add stuff, and more often that not, that will mean adding new classes. If adding new classes means adding new branches to all your conditional logic, your stuffed. In that case write me a big cheque and I might come and fix your design for you.

So this is how interfaces work. In a static language (Java, C#) you can get the language to enforce this:

1
2
3

public interface Producer {
  public message next_message();
}

and your subscription class can (is required to) state its the type it expects for producer

1
2
3

public class Subscription{
  public Producer _producer;
}

and your compiler checks all this for you. If you get it wrong you get nice early TypeMismatchError. Now I’ve finally decided I prefer dynamic languages to static, so I’m not going to claim Ruby is crap for not allowing this. But it is a big stinking black hole you can fall into if your not expecting it.

In fact it’s not really a problem at all. All you have to do is write down, somewhere obvious, somewhere where anyone in your team is going to find it, what methods you expect producer to implement. If you can find a way to check what types could have been assigned to the producers association (analysing the code is too hard, but you could get a good idea by peeking into the database) you can even get your unit tests to check that all the classes that are going to be returned from producer respond to the next_method message. You could even write a module that you import into your producer classes that provides either a decent default implementation or raises “Interface Not Implemented Properly, shoot the coder” exceptions.

So that’s interfaces. Hopefully you know have a good idea of why they are very important when using polymorphic associations, even though you can’t code them (in Ruby), you should be thinking about them. Really.

Bookmark to:

On Thursday 30th of August I will be presenting a talk as part of the LRUG BOF (Birds of a Feather) session at NFJS, No Fluff Just Stuff. It will be my first time presenting outside of an academic conference and I am really looking forward to it. I’m going to be talking about how JRuby can be used to rapidly prototype new features into a Java application.

I must admit, the biggest concern I have is about estimating the audience. It’s quite a varied conference, mainly Java and Agile, and it’s not clear what proportion of the audience will know anything about Ruby, and what proportion will be experts. Figuring out what level of understanding in each language to pitch the talk at is going to be an open question. It won’t be until I start the talk that I will really know if I have got it right.

The BOF session is free, but you need to pay if you wish to attend the rest of the conference. On the plus side, as valued readers of this blog you get a discount. Simply quote NFJS-BLO182 when you register and you get £100 off the registration fee.

Bookmark to:

Today, as an exercise, I coded up a simple piece of java and ruby integration, via JRuby.

The task I set myself was simple. Start with a java only application, and then use JRuby to rapidly prototype adding a new feature to it. I used my favourite sample application: A library with three entities, books, borrowers and loans (the first application design I was ever taught – way back in A-levels). The design is pretty simple; a borrower is associated to a number of loans, each of which is associated to a book. There is also a link from each book to all the loans it’s refereced in.

I intentionally made a limiting design decision however. Each book’s author is saved as a string, and the meaning is lost when someone tries to enter several authors to a book

public class Book {
<snip>
private String author;
<snip>
}

Book jrubyBook = new Book(”JRuby for beginners”,
“Ruby Guy, Java Guy”, //second argument is author
“12365437890″,
LoanType.ONE_MONTH);

The feature I wanted to add was the ability to look at a book, and see what books influenced its authors. The logic used is:

1. use the book.author property to find out the author(s) of the book
2. look at the loans associated with the author(s)
3. get the books for those loans

Not a very complex piece of logic, but good enough to demonstrate the point. Ideally the author field of book should be refactored to be a collection of people which would be created as a new super-class of borrowers. But before I go and do some refactoring, (which in a real project would mean quite a bit of changing the persistence mapping too) I want to get the functionality working to see if it really is useful. JRuby’s ability to load up some java classes and quickly change them allowed me to simulate doing these changes.

require ‘java’

include_class ‘com.wildfalcon.library.model.Book
include_class ‘com.wildfalcon.library.model.Borrower’
include_class ‘com.wildfalcon.library.persistance.Books’
include_class ‘com.wildfalcon.library.persistance.Borrowers

class Book
def authors
author_names=[]
getAuthor.split(”, “).each { |author| author_names << Borrowers.findByName(author)}
author_names
end

def inspirations
list = []
authors.each {|author| author.books.each{|book| list << book}}
list
end
end

I can then call the inspirations method:

book = Books.findByName(”JRuby for beginners”)
book.inspirations.each {|a| puts a.title}

all of which I put in a prototype.rb file an execute as follows:

ScriptEngineManager factory = new ScriptEngineManager();
ScriptEngine engine = factory.getEngineByName(”jruby”);
InputStream is = new FileInputStream(new File(”prototype.rb”));
try {
Reader reader = new InputStreamReader(is);
engine.eval(reader);
} catch (ScriptException ex) {
ex.printStackTrace();
}

Indeed when I execute it I find out what books have been read by the two different authors of “JRuby for Beginners”:

• Java for beginners
• Ruby for beginners
• How to tie a tie
• History of fairy tales
• Cooking Italian Food for Large Groups

This quickly allows me to realise that looking at the books read by the author isn’t good enough, before I can deliver the feature I need to find some way to tell which books are relevant and which are not. But I found that out with a very small amount of coding, and without having to make any changes to the existing java application. I can happily go back to the drawing board without worrying that I broke something in the meantime.

Bookmark to: