For example, on page 128 of Metaprogramming in Ruby, we get a simple little example class that tells us when a loan on a book was originated. The code looks something like:

class Loan 
   def initialize(book)
      @book = book
      @time = Time.now
   end
   def to_s 
      "#{@book.upcase} loaned on #{@time}"
   end
end

Simple enough, right? Except you can’t test to_s because then we would have to know the exact time the object was created. The solution?

class Loan
   def initialize(book)
      @book = book
      @time = Loan.time_class.now
   end
   def self.time_class 
      @time_class || Time
   end
   def to_s
      ...

Wait, wait, wait. Let me get this straight … we introduce a class method that encapsulates the class we are using to tell time? Well, that sure seems … obscure. To test it, we then write,

class FakeTime 
   def self.now; 'Mon Apr 06 12:15:50'; end
end
require 'test/unit'
class TestLoan < Test::Unit::TestCase 
   def test_conversion_to_string
      Loan.instance_eval { @time_class = FakeTime } 
      loan = Loan.new('War and Peace') 
      assert_equal 'WAR AND PEACE loaned on Mon Apr 06 12:15:50', loan.to_s
   end
end

Okay, this has just gone too far. We’ve convoluted our code to make it easier to test? Let’s take a step back here. What is to_s supposed to do? It is supposed to return a stringified Loan object. What sort of details do we want in it? How about the book in all upper-case, a template string, and the time it was loaned at. So now let’s roll back our definition of the class to the first one — the simple, intuitive implementation. Now, given our GOAL of the to_s method, wouldn’t it make more sense to quite simply implement our test as:

require 'test/unit'
class TestLoan < Test::Unit::TestCase 
   def test_conversion_to_string
      loan = Loan.new('War and Peace')
      assert loan.to_s ~= /[A-Z][[A-Z]*|\s*]* loaned at [A-Z][a-z]{2} [A-z][a-z]{2} \d{2} \d{2}:\d{2}:\d{2}/
   end 
end

Now we capture the essence of what to_s should be doing. Arguably, you also should now be testing that the regexp does what you want … but I will assume you are fluent enough with regular expressions you don’t really need to do that. To extend this, we could match on the book title and the time and check whether the book-title matches what we passed in and the all that jazz — but most importantly, we want to make sure that to_s is doing the job we asked it to do.

The point being — we are testing the intention of to_s, not some obscure instance of it. And now we don’t have to bastardize our code to make it testable. The way the book recommended (using Metaprogramming), we would have to actually look at the test-suite (or expect some damn-good comments) to even understand what the point of the class method was. In my opinion, that isn’t good programming.

A similar situation came up when I was perusing StackOverflow. A user was asking how to load specific files from a relative path. A solution was given, but it didn’t fit in well with the ‘testing methodology’ because the OP doesn’t load the full stack during his unit tests. The solution? “Wrap it in an object!”

In my opinion, trading in code-clarity for ease of code-testability is a bad thing. The first test you should ever perform on code is to simply check if it is legible. If not — I don’t care if it works — tear it down and start again.

class WeightedRandomArray < Array
      def initialize(other_array, weights)
        total_weights = weights.inject(0.0) { |t,e| t+e }
        proportions = weights.map { |e| e / total_weights }
 
        elements = other_array.zip(proportions)
 
        # construct an alias table for faster access
        @table = []
 
        n = elements.size
        elements.map! { |a,w| [a, w*(n-1)] }
        elements.sort! { |e1,e2| e1[1] <=> e2[1] }
 
        while elements.size > 2
          p = elements[0][1]
          elements[-1][1] -= (1.0 - p)
          @table << [p, elements[0][0], elements[-1][0]]
          elements.delete_at(0)
          elements.sort! { |a,b| a[1] <=> b[1] }
        end
 
        p = elements[0][1]
        elements[-1][1] -= p
        @table << [p, elements[0][0], elements[-1][0]]
      end
 
      def random_element
        entry = @table[(Kernel.rand * @table.size).floor]
        if Kernel.rand < entry[0]
          return entry[1]
        else
          return entry[2]
        end
      end
    end

So now the work is all up-front — and while it is considerable, so long as you will be doing enough random draws, the O(1) time to get a random entry should trump…

def inner(*args)
   yield args[0], args[1]*args[2]
end
 
def wrapper
   inner(3,4,5)
end

The question is, how do I pass a block to wrapper and have it get passed to inner? Google wasn’t much help here. My solution looks like:

def call_block
   yield 4, 5, 6
end
 
def wrap_block(&blk)
   call_block { |*args| blk.call(*args) }
end
 
wrap_block { |x,y,z| puts x+y+z }

Would love to see a smarter solution…

But wait!  How is it that I have somehow always overlooked Rubinius?  JIT compilation on LLVM?  Future multi-VM implementation (hello sandbox!)?  Holy cow!  That is AWESOME.  Rubinius is definitely my VM of choice from now on.

P.S. Totally unrelated, but check out Ruby Processing — it is pretty damn cool.

Main: Quit re-writing your main program structure for all those flags and options. Use this gem to do the heavy lifting.

rq: rq is a great little gem for clustering Linux boxes via a job system running on an sqlite database on an NFS. Check out a nice little article on it here.

As a simple example, one can examine the solutions that Ruby programmers come up with when given the power of meta-programming. Some are clean and extremely beneficial to the end user. If we look at ActiveRecord, we find that all sorts of instance and class level methods and values are inherited dynamically, by looking up values of columns in a database table! All transparent to the user.

While some solutions provided by Ruby’s dynamic and meta-programming ways are extremely elegant, other times it just leads to a heap of spaghetti code. Speaking from experience, with the lack of type constraints built in, open classes, and meta-programming abilities, I often find that I get objects in some places that I don’t expect. Twitter had the same problem. They blamed Ruby. Others blamed bad programmers.

I blame both. Personally, I know that my ‘programming hygiene’ has greatly suffered in my ‘Time of Ruby.’ While it has allowed me to code with blazing speed and agility, I find that my code smells quite a bit worse than it used to. It was great for writing one-off programs, but my code readability and reusability has faltered greatly. Quite simply, in the absence of static languages, or even functional languages, I failed to shoulder the responsibility of ensuring that my programs were well constructed and well tested.

Having picked up Scala lately, I have found the switch back to a static, semi-functional language refreshing. In fact, I feel almost the same way I did when I switched to Ruby. Now, writing simple one-off programs has taken me more time — but it also tends to lead me to writing reusable libraries. I tend to break up my code more naturally, instead of hacking together solutions that work at the time. Instead of just restarting a project, I find myself refactoring.

So that brings us back to the Twitter case. I know it is old news, but I think it is a good case study. Twitter chose Ruby because it allowed them to rapidly develop their product. But when it came to scalability, they found that it just didn’t suit their needs. That isn’t to say that Ruby couldn’t suit their needs — they just didn’t find it to be the appropriate solution. Certainly, I know I have trouble maintaining a large Ruby code base (except for maybe a well constructed Rails project). On the other hand, most of the larger Scala projects I have written have naturally fallen into proper software engineering constructs on their own. I put that on the language.

You see, I know I am a bad programmer. Not in the sense that I can’t write efficient algorithms, or design systems well. I can. But under the time constraints of business projects, I don’t. And Ruby let me do that better than any other language I have used. So I guess I will use Scala for now, not just for my own sake, but for the sake of everyone who has to read me code one day.

Being a fan of Ruby, I wanted to see if anyone had implemented the Actor pattern yet. It wasn’t a hard concept — you just provide the class with a mail-box and a way to check and parse messages. The issue falls in Ruby’s threads — namely, they are big and bulky. To have lots of actors, we need a light-weight implementation. What is worse is that Ruby suffers the same problem as Python when it comes to concurrency — the global interpreter lock (GIL) prevents the virtual machine from executing more than one instruction at a time. So even though you might be running separate OS threads on multiple cores, the speed is limited by a single core. So basically, using 1.8, the Actor pattern is a waste of time.

The stable release of Ruby 1.9 seems to tackle the issue head on, by providing Fibers. With 1.9, I was able to find the (now defunct) revactor gem, which seemed like a fairly good (though poorly documented) implementation of the Actor pattern. I also found journeta (which works on 1.8), which was a system that performed network auto-discovery. With the power of these two combined, and some horrible spaghetti code, I whipped together a little gem called ‘curtaincall’, which allows end-users to spawn actors on other machines.

Unfortunately, not everything turned out as well as I would have liked. Revactor seems to break down … or at least, its dependency Rev does, in signaling the mailbox that it has a new message. I can’t quite seem to figure out why this occurs, so as it stands, curtaincall actors never end up receiving the messages passed to them. Furthermore, the method I used of identifying actors is horrible — though it gets the job done. Finally, Erlang niceties like ‘spawn_link’ are poorly implemented and untested.

Ultimately, once I hit the road-block with Revactor, I just gave up. Revactor is undocumented and discontinued. I just wanted to see if I could do this for fun.

The pros? Journeta is a delight to work with. Easy to figure out from the examples provided, and it works just as promised out of the box.

Cons? Just about everything else.

curtaincall-0.0.1