A bedbug sundae

I’m still trying to figure out who would download this iPhone app to get grossed out by bedbugs. To think they thought it was so compelling that it is coming to Android and Blackberry soon too.

R/Finance 2011

I will be speaking at R/Finance 2011 in Chicago at the end of April regarding the futile.paradigm, my R language extension for functional dispatching. The focus of the talk will be on why analytical applications are particularly suited to functional programming and how to leverage the futile.paradigm to achieve declarative code in R. My presentation aside, it is shaping up to be a good conference.

Jigs and charting libs

I’ve been thinking a lot about the parallels between software development and carpentry as I’ve been doing quite a bit of both recently. The traditional parallel is between software development and building construction, of which I used to be an ardent believer. However, building out my own woodworking shop has led me to realize that carpentry is also an apt analogy, where tools can be considered languages and jigs are libraries. The amazing thing about jigs is how much repeatability and consistency you get out of a simple apparatus. Unlike bits in a computer (ignoring the tolerance of semi-conductors themselves), each piece of wood is unique and somewhat unruly with warps, bends and knots. Yet with a good jig,  each board is transformed into a well-behaved component.

Libraries and frameworks can be viewed in a similar manner as a jig: they should yield a consistent, predictable outcome without being overly complex to use. Like a bad jig that messes up your work piece, a bad library introduces bugs in a system. The key is to build/buy a good jig and use it every time it is appropriate. So long as the jig works well and is kept in good shape, it doesn’t need replacement. For example, once you find yourself a good dovetail jig or mortise jig you can stop looking and focus on other things.

With software the analogy breaks down as innovations are constantly challenging the status quo. Just because a library was good a year ago, it doesn’t mean it will be the best choice this year. Charting is a good example, as there always seems to be a new charting library that knocks the socks off the previous generation. This time around it appears that Highcharts is such a library. A few years ago, the go-to library was JFreeChart. Regardless of how good the library is, the question nagging at me is when do you have to switch? Unlike with jigs, where you build it once and use it forever, with software you have to replace it and relearn a new methodology each time. Somehow the relationship between the irascibility of wood tempered by a consistent and permanent jig has been inverted with software. Now the medium is consistent and the jigs irascible.

Some would argue that the medium is constantly changing, and it can certainly be viewed that way. But the question for me is whether it is possible to create universal jigs that do not need to be replaced?

Bunny Farm – an AMQP wrapper in Erlang

A useful library for connecting to RabbitMQ via Erlang is gen_bunny. There are a lot of good things about it, but it is really designed for simple pub/sub applications in a modified gen_server paradigm. I had a need for connecting a gen_fsm instance to RabbitMQ. So rather than using gen_bunny for certain modules and a bespoke library for the others, I decided to write a simple wrapper library that can integrate into any Erlang module. I couldn’t resist the bunny meme, so welcome to the bunny_farm.

The point of bunny_farm is to make the wiring easy in custom applications. Note that the messages will still arrive via handle_info in a gen_server or gen_fsm.

Consuming Messages from a Topic Exchange

BusHandle = bunny_farm:open(ExchangeName, RoutingKey)
bunny_farm:consume(BusHandle)

Publishing Messages to a Topic Exchange

BusHandle = bunny_farm:open(ExchangeName)
bunny_farm:publish(Message, RoutingKey, BusHandle)

Support for RPC messages

BusHandle = bunny_farm:open(ExchangeName, RoutingKey)
bunny_farm:rpc({Procedure,Arguments}, ReplyTo, BusHandle)

The library is still in its infancy but should still be useful in simplifying integration of existing Erlang modules with RabbitMQ.

Duck typing with quantmod

This is a short example of using duck typing in a guard statement in the futile.paradigm. We are implementing a simple function to calculate the daily volatility of the returns with the help of quantmod.

vol.symbol %when% (has.Cl(symbol))
vol.symbol <- function(symbol, window)
{
  r <- Delt(Cl(symbol))
  v <- rollapply(r, window, function(x) sd(x, na.rm=TRUE), align='right')
}

A working example is below. The function is called whenever the symbol object satisfies the has.Cl assertion. Quantmod comes with the has.Cl function to check if a particular symbol contains a series representing the closing price. This is necessary since all names in the symbol object are prefixed by the literal string symbol. Hence the close series for GLD is GLD.Close. This makes direct access a bit cumbersome but since accessor and inspection functions are provided it isn’t so bad.

getSymbols("GLD")
v <- vol(GLD,30)

Getting back to the point, to accomplish the same task in any of the class systems in R would require conditional statements in the body of the method, since only the class of the arguments can be tested. In S3, the function would be implemented like this:

vol <- function(symbol, window) UseMethod("vol")
vol.xts <- function(symbol, window)
{
  if (! has.Cl(symbol)) stop("No close series in symbol")
  r <- Delt(Cl(symbol))
  v <- rollapply(r, window, function(x) sd(x, na.rm=TRUE), align='right')
}

While this example is trivial, it illustrates two important concepts:

1. The fine granularity that guards provide for function dispatching
2. The removal of control flow in functions, leaving only the essential logic

On a larger scale, these improvements add up yielding cleaner code that is easier to maintain and modify.

Required Packages

require(futile.paradigm)
require(quantmod)