#burtcorp

Gotcha! Ruby things that will come back to bite you, by David

Gotcha! Ruby things that will come back to bite you. from David Tollmyr

Concurrency and Distributed Systems using JRuby, by Theo

Idempotency as the Holy Grail of Scaling, by Srdan

Enter Tivoli.

What better than a DSL to explain the functionality.

https://gist.github.com/2647673#file_tivoli.rb

There are a few gems already providing this functionality and much more for Ruby http://aquarium.rubyforge.org/ and a few more https://www.google.com/search?btnG=1&pws=0&q=gem+aspect+oriented. 

My core thoughts on Tivoli are: It should be dead simple, not pollute any object and provide a way of doing AOP in an adhoc manner. (Meaning existing code should not be concerned that we are logging or measuring performance). 

About this time a year ago I started my deep dive into JavaScript, a language that I had no previous intimate knowledge about. I knew only the parts i had previously needed to get around jQuery and all was good. Throughout the past year of studying the language I came around to find the elegance and horrible extremities of it.

Let me guide you through the thoughts that led me to Tivoli.

Disclaimer: We are about to tread into meta programming, please choose cautiously what you would use in your production code. Methods in Ruby are quite different from the functions we see in JavaScript. To recap: In JavaScript functions are like any other object. They can be passed around, assigned attributes and so on. This is one of the core features of JavaScript and we should be quite happy that such an old (17 years) dynamic language lets us create highly dynamic code with functions as first class citizens. In Ruby we clearly distinct methods from blocks, which are the two tools we as developers have to mix in a dynamic control flow. Methods are always defined on a class, even though this might be the eigenclass or the global main object. Methods can only be called in context with an object and a class. In contrast to JavaScript, where it is possible to pass null through a #call or #apply call. Blocks, namely procs and lambdas, on the other hand can be passed around in the same way as JavaScript functions and are often passed in a method through the normal block syntax, but also as normal parameters with the flip side of missing out on nicer syntax.

https://gist.github.com/2647673#file_blocks.rb

In JavaScript the only way to imitate Ruby blocks would be by passing in the function as an argument which reminds us of the above syntax. Maybe changing the minimal way of defining a function could make the below more appealing but for now i find myself not using anonymous functions/procs/lambdas and instead naming them for cleaner syntax.

https://gist.github.com/2647673#file_named_callbacks.js

A word on syntax: In JavaScript we have to use parentheses when calling a function which feels nice and cosy like any "c-like" language. This has the benefit of letting us treat references to the function without any arguments or parenthesis as a reference and not as a call which in turn brings us the lazy feature of passing functions around in JavaScript and evaluating them when we choose in the context we see fit. In Ruby, things are quite different for methods but similar for procs/lambdas. Ruby methods are in fact called when referred without parentheses and arguments which makes for nice short and clean syntax and compensates by using blocks when functionality needs to be passed around.

https://gist.github.com/2647673#file_passing_procs.rb

I think the design choices in Ruby are quite solid and bring the nice flexibility that we come to expect when expressing ourselves in Ruby. I encourage reuse of blocks in this manner as it is often a feature people tend to overlook as a way of DRYing up their code. Even the block syntax feels clumsy at times for simple cases. Which got us the Symbol#to_proc and encourages some to work outside of the simple cases. The short syntax that you see above unfortunately only captures the cases when the methods are in fact defined on the object. So given a class method in this example JSON#parse we could create a proc that proxies the call and reuse it.

https://gist.github.com/2647673#file_json_parse.rb

But would it not be cleaner to actually pass JSON#parse much like we would have done in javascript? Turns out we can - with #method. Reading the docs on the Method Class confirms that a Ruby method is defined in the context of a object, meaning that there is a #reciever and an #owner method on a Method. This got me thinking...  There's got to be a way of reusing a method's definition for multiple class and at the same time satisfying my needy DRY addiction while removing the overhead of having a separate block for proxying every call.

We define a method #twice on Numeric

https://gist.github.com/2647673#file_twice.rb

Now lets say we want to reuse this method. How do we get around so that a method is bound to a reciever? We want a piece of functionality that we could pass around like any other object just as in JavaScript. One could always call 1.method(:twice) but that would return an object that is bound to 1.

Enter at Method#unbind 

“Dissociates method from its current receiver. The resulting UnboundMethod can subsequently be bound to a new object of the same class (see UnboundMethod).”.

UnboundMethod says

“Unbound methods can only be called after they are bound to an object. That object must be be a kind_of? the method’s original class.”

Ok, but what if I don’t have an instance of the class that I am copying the method from? Module#instance_method provides what we need. Please note that it does not in fact return a Method as one would expect at a first glance but an UnboundMethod since it would actually not be bound to an object. Let’s try to bind the Numeric#twice that we defined above to String

https://gist.github.com/2647673#file_twice_unbind.rb

This turns out to be a limitation in Ruby, at least MRI. Since Ruby is slightly evil, not letting us jailbreak twice, let’s bring in the heavy artillery ourselves: evil-ruby. Unfortunately this does not work with the latest MRI (1.9.3) atm, but highlights what lengths one would need to go, to achieve a solution to our problem. This makes me think that this is probably not a good idea out of a design or performance perspective. Ok, but what CAN we do? If we start off defining our functionality in a proc, it turns out to be quite simple to share it among classes.

https://gist.github.com/2647673#file_twice_proc.rb

But when you come to think about it, you could have an abstraction layer on top of this piece of functionality which included defining multiple methods that should be included and Voila! You have reinvented Module.

I have hopefully teased you enough to have a look at the implementation:

https://github.com/Fonsan/tivoli/blob/master/lib/tivoli.rb

In his own words (that we regulars non-developers might not quite understand)…

"Tools like Express and NoSQL-databases have made it easy to write web applications using Node.js. But what if we don’t need to serve HTML? What if we don’t need to do templating, CSS and pretty animations? What if we only want to provide an HTTP-interface to our data?

This talk will be about tips and tricks for building RESTful web services using Node.js. It’ll discuss challenges, pitfalls and shortcuts. It will deal with authentication, declarative ways to describe your data structures and validation.

If you’re serious about building a backend able to serve any kind of application or provide a public API for your users, and doing it without pain, this is a talk for you."

Not only are display ads placed out of the way, one single site can easily offer 20 different basic products (not counting options for rich media, targeting etc) and none of these products can be easily compared with one another or with other properties. 

Not only does this make the online media consumer experience borderline horrific, it's also one of the main reasons online media properties are making pennies on the dollar compared to other channels.

It doesn't have to be that way. 

We can make online advertising a natural part of every user experience, more zen, less chaos and create consistency across campaigns and properties. It's well possible for great media companies to have advertising revenues per reader on par, even beyond traditional media.

What's interesting is that we need nothing more than just getting our act together. Content, consumers, infrastructure. It's already there. As some smart people rightly point out, there are no silver bullets, and tweaked targeting, automated overhead or yet another performance metric will have little or no impact in the greater scheme of things.

However, the rules still apply. 

Before going into how, I figured I'll explain each rule more in detail over the next week or two. After all, we've got it wrong for the last 15 years, so what's another couple of days?