Conditional branches are like a piece of meat in the source code; as the software ages, the meat starts to rot.  Before you know it, maggots (bugs) will start to feast on the meat.

One of the main reasons bugs tend to hide around conditional branches is because it increases the complexity of the software.  The more conditional branching exists, the more difficult it is to fit all the logic into one’s head.  This is obvious, and I can probably talk all day on how bugs can be introduced with conditional branching, but let’s not dwell on that.  Instead let’s talk about how we can solve the problem in a simple way.

The dispatch table pattern is not new, but I feel like it is not widely adopted.  It is not a traditional design pattern one will find in a typical design pattern book, but in my opinion this pattern will give you the most bang for the buck.  With a dispatch table, branching statements can be eliminated completely, and the “shape” of the code can be seen.  In the simplest form, a dispatch table is a hash table where all the keys represent all possible actions, and the value of each key contains a call back function that does the actual work.

This is best explained with a simple example.  I am going to use JavaScript in the example, but the idea is language independent.

Let’s say, you are building a Tivo’ish program that surfs all the channels and figures out what it should record.  Assuming an external data feed look like following:

var channels = {
    1: { station:   "NBC",
         showTitle: "Saturday Night Live",
         genre:     "comedy",
         repeat:    true },
 
    2: { station:   "FOX",
         showTitle: "Cops",
         genre:     "crime",
         repeat:    true },
 
    3: { station:   "ESPN",
         showTitle: "College Football",
         genre:     "football",
         repeat:    false },
 
    4: { station:   "HBO",
         showTitle: "Curb Your Enthusiasm",
         genre:     "comedy",
         repeat:    false },
};

The key for the channels hash table is a channel number.  In this case, there are only 4 channels, one through four.  Let’s move on to the core logic:

function record(channel) {
    // do some work here...
    console.log("recording " + channel.showTitle);
}
 
function surf(channels) {
    var genre, repeat, showTitle;
    for(var number in channels) {
        genre      = channels[number].genre;
        repeat     = channels[number].repeat;
        showTitle = channels[number].showTitle;
 
        if (genre === "football") {
            record(channels[number]);
        }
        else if (genre === "comedy" && !repeat) {
            record(channels[number]);
        }
        else if (genre === "crime" && showTitle !== "Cops") {
            record(channels[number]);
        }
    }
}

The code above is making decisions on the genre of the show with a couple of ugly else-if statements.  As one can imagine, the else-if statement will continue to grow when additional functionality is required and eventually becomes unmanageable.  Imagine what the unit test for this function looks like. Yuck!

Now let’s switch to the dispatch table version:

var actions = {
    "football":  function (channel) { record(channel); },
    "comedy"  :  function (channel) { if (!channel.repeat) { record(channel); } },
    "crime"   :  function (channel) { if (channel.showTitle !== "Cops") { record(channel); } },
};
 
function surf_dispatch(channels, actions) {
    var genre;
    for(var number in channels) {
        genre = channels[number].genre;
        actions[genre](channels[number]);
    }
}

An actions dispatch table has been added as a parameter, and all the conditional branch logic has been completely removed.  Notice how simple the new surf function has become.  Now this version is very easy to extend because the application logic has been decoupled from structural logic.  To make things even better, the actions dispatch table is essentially a configuration point for the application.  There is an anonymous function with one parameter associated with each key, that is the interface each dispatch item must implement.  The application will start to behave differently when the table has been updated.  New behavior can be injected without changing any core code.  Now, that’s flexibility!

Skeptics may say, that problem has been solved in the Object Oriented world by polymorphism.  There are known refactoring steps to deal with this: Extract Method, Move Method, Replace Type Code with Subclasses then finally Replace Conditional with Polymorphism.  Wow, that is a lot of work, and think about the number of classes and lines of code you will end up with!  I will take the dispatch table pattern any day.

Dispatch table is one of those hidden gem design patterns, that will allow the software to be extended in ways never imagined.  The application behavior can be completely changed by supplying new anonymous functions to the dispatch table.  If you are working in a dynamic language, the dispatch table can live in a separate “configuration” file, and be read during run-time.

I have only scratched the surface on what you can do with a dispatch table. Chapter 2 of Higher-Order Perl by Mark Jason Dominus has a much more comprehensive overview of dispatch tables.  The book is currently available as a free download, so there is no reason not to check it out.  Don’t be afraid if you are not familiar or a fan of Perl, the book is readable with very little Perl knowledge.

I would also like to give a special thanks to my friend, and colleague, Kyle Burton, for recommending the book.  It forever changed how I think.

Before I explain the suggestion I made, it is useful to walk through a simple example.

(defn awesome [a b c] a)
(defn what-is [] (awesome 1 2 3))
 
(deftest should-be-awesome
  (expect [awesome (has-args [#(= 1 %) #(= 2 %) #(= 3 %)])] (what-is)))

what-is calls awesome function internally.  We don’t care about what awesome function does, but we need to ensure that it does get called inside what-is with expected arguments passed to it.  The vector after has-args contains functions does exactly that.  Let’s say you accidentally deleted a parameter to awesome function call witin what-is:

(defn awesome [a b c] a)
(defn what-is [] (awesome 1 2))
 
(deftest should-be-awesome
  (expect [awesome (has-args [#(= 1 %)#(= 2 %) #(= 3 %)])] (what-is)))

If you run the test above you should see the following result:

FAIL in (should-be-awesome) (NO_SOURCE_FILE:11)
Unexpected number of arguments. Function name: awesome
expected: 3
actual: 2

The test failed because test-expect internally noticed the argument count is different, so it couldn’t verify all the arguments expected. Let’s say you decided to refactor awesome function to take one less parameter, and you forgot to update all the calling locations.

(defn awesome [a b] a)
(defn what-is [] (awesome 1 2 3))
 
(deftest should-be-awesome
  (expect [awesome (has-args [#(= 1 %) #(= 2 %) #(= 3 %)])] (what-is)))

Ran 1 tests containing 0 assertions.
0 failures, 0 errors

No matter how many times you run your test, nothing will fail.  test-expect only checks if the calling function (what-is) is calling the mocked function with same number of parameters.  It doesn’t actually check with the original awesome function to see how many arguments it is actually expecting.  This is very annoying because you might not know there is a problem until run-time.

It would be nice if test-expect verified that the REAL function has the correct number of parameters. This is a fairly common problem in mock frameworks in dynamic languages. Lucky this functionality is very simple to implement in Clojure.  Every function definition is attached with meta data such as function name, namespace, and expected arguments, etc… For example:

user=>; (meta (resolve ‘awesome))
{:ns #<;Namespace user>;, :name awesome, :file “NO_SOURCE_PATH”, :line 7, :arglists ([a b])}

meta returns a map which contains arguments of the function via :arglists key.  You get the idea.

Originally I submitted a patch to Matt Clark which provided an implementation to fix the problem I described above. Since then Matt has added this feature to test-expect with better error reporting than my original implementation.

Thanks Matt!

More information can be found in the project README file on github.

project url:

http://github.com/aaronfeng/trixx

git clone url:

git://github.com/aaronfeng/trixx.git

In the last few days I have been working on a web management console for RabbitMQ.  I basically need to emulate all the features provided by rabbitmqctl, but I don’t want to shell out to the command line.  So I have two choices: build the web console in Erlang or talk to Erlang nodes via JInterface¹.  I chose the latter.  JInterface ships with Erlang Otp, so if you already have RabbitMQ running you should be able to locate the OtpErlang.jar some where on your system.

To extract the information via JInterface is mostly painless, but tedious.  I’ll provide basic instructions here and maybe someone will find this information helpful.  I’ll assume the basics of Java programming are known.

The basic program structure looks like the following:

OtpSelf self = new OtpSelf(”monitor”, “YOUR-ERLANG-COOKIE-VALUE-HERE”);
OtpPeer peer = new OtpPeer(”rabbit@server”);
// Be sure to close the connection!
OtpConnection conn = self.connect(peer);
OtpErlangList arguments = new OtpErlangList();
conn.sendRPC(module, function, arguments);
OtpErlangObject result = conn.receiveRPC();

OtpSelf creates a node from Java that has the capability to interact with other Erlang nodes.  The first argument is the name of the node which can be called anything.  The second argument is the most important.  In order for Erlang nodes to communicate with each other, all the nodes must use the same magic cookie.  If the cookie value isn’t supplied properly, you will receive an OtpAuthException when trying to connect.  The RabbitMQ cookie file on my Macbook is located in /opt/local/var/lib/rabbitmq/.erlang.cookie.  Depending on your platform it might be stored in a different location.  I actually ran into a couple problems with the Erlang cookie file, but I’ll discuss it at the end of the article.

OtpPeer is the rabbit node you are connecting to.  Replace the “server” with the host name (hostname -s) of your machine that is running RabbitMQ.

In order for RabbitMQ to return any information, the correct function within a module must be invoked.  For example if you want to list all the virtual hosts in a broker:

conn.sendRPC(”rabbit_access_control”, “list_vhosts”, new OtpErlangList());

So how did I know it’s in module “rabbit_access_control” under a function with no arguments called “list_vhosts”?  Remember I said in the beginning that rabbitmqctl does this already?  If you look in rabbit_control.erl you can figure out pretty much anything you need to know.  Search for list_vhosts within the file and you will come across the following code:

action(list_vhosts, Node, [], Inform) ->
Inform(”Listing vhosts”, []),
display_list(call(Node, {rabbit_access_control, list_vhosts, []}));

The second parameter of the call function is what one is after.  The first value of the tuple (surrounded by curly braces) is the module name followed by the function and arguments.  Going back to the list_vhosts example, let see what receivedRPC returns when requesting all the virtual hosts.  The easiest way is just output the toString on the OtpErlangObject.

System.out.println(result); -> [#Bin<1>]

As one can see in this example the result is actually a collection of Erlang binary (#Bin) objects.  Since there’s only one virtual host on my broker, only one binary value is returned.  Let’s extract the value of the binary.  We’ll cheat since we know there are only one virtual host in this case.

OtpErlangBinary binary = (OtpErlangBinary)((OtpErlangList)result).elementAt(0);
System.out.println(new String(binary.binaryValue()));

The code above is making a lot of assumptions.  I did this on purpose in order to focus on the important concepts, so don’t write the code like that in a production system.  Everything should be pretty self explanatory, maybe except for why I wrapped binaryValue with a new String.  binaryValue returns a byte array, passing it to a new String will convert it to human readable format.  Pretty easy right?

I have shown the simplest case, but for the more complicated return values all the concepts remain the same.  Remember I said it gets pretty tedious?  Most of the time it doesn’t just return a binary value in a collection, but it’s usually wrapped in a tuple.  It gets worse, sometimes tuples are wrapped in tuples and so on.  Like I said before, it’s not hard, just time consuming.

On my Macbook a ran into a couple issues with Erlang cookie file.  For whatever reason I had to copy the .erlang.cookie into my home directory.  I also had to map my hostname (hostname -s) to 127.0.0.1 in my /etc/hosts file.  Before attempting writing any monitoring code, make sure you can actually connect to the Erlang instance cleanly.  Once the connection is made, make sure you close the connection, otherwise you won’t be able to make subsequent connections without bouncing the server.

I have successfully emulated all the features of rabbitmqctl in Clojure.  I plan to throw JRuby on top of it for the frontend whenever I get a chance.

All these tedious parsing may go away after the management capability is a first class citizen in the AMQP protocol.  Until then, this is what you have to do if you want to monitor RabbitMQ.

If you get stuck, the Java doc for JInterface is pretty helpful.  I can illustrate a more complicated example in detail if someone finds this information helpful.  Please feel free to drop me a comment or email.

I called this utility SchemaRunner. It was originally written in C# to match our code base.

Click to enlarge. Original C# version.

Earlier this year I decided to play around with F#, so I figured the best way to learn it is to actually use it.  I’ll be rewriting SchemaRunner using F#.  I’ll be posting bits and pieces while I’m doing the rewrite.  When I’m finished I’ll make the source code freely available.  Maybe people will find the tool useful in their development environment.  Most important of all, this can serve as an example for anyone who wants to learn about F#.

Time to hack!

What is F#? I’ll let Wikipedia do the explaining:

F# (pronounced F Sharp) is a multi-paradigm programming language, targeting the .NET Framework, that encompasses functional programming as well as imperative object-oriented programming disciplines. It is a variant of ML and is largely compatible with the OCaml implementation.

Why did I pick F#?  In my day job, I work on a C# financial application that targets .NET Framework 3.5.  I hope that after learning F# I might be able to inject some functional goodness in our application since it will compile down to the same IL.  Even though F# is backed by Microsoft, it does run on multiple platforms via Mono, which is very important to me since I don’t use Windows at home.  F# is compatible with OCaml, I figure I’ll kill two birds with one stone.

Like many people, I first encountered FP in my college days, and stayed far away from it since then. I re-discovered FP when I heard about Erlang a couple years ago.  Now I’m hooked.  Since Erlang, I have moved on to playing around with Lisp, Haskell, and F#.

Why functional programming? I’m sure there are endless reasons why one should learn about functional programming. At the end of the day, even if you never use any FP languages/techniques it will make you a better programmer. The reason is simple: It will forever change the way you think and see the world. You don’t have to take my word for it, you can read Why Functional Programming Matters by John Hughes.

Enjoy!