View part 1 of this series: Design Patterns.

Software metrics don’t get their dues. A lot of us use metrics often, but we often don’t pay attention and realize why or how we’re using them. This means we’re missing a great opportunity to learn about the metrics we use, why, when and where they apply, and potentially even discover some new metrics that might be more helpful for keeping track of our code. Hopefully this article can shed some light on these metrics we use and explain when and where they’re best applied as well as when and where they aren’t. I’d also like to cover some other metrics that aren’t as popular but might be interesting to know about, especially for dynamic languages such as Python or Ruby.

Granted, all of my personal projects benefit others, whether it’s my documentation tool, my OpenCL Ruby bindings or my apparently well received compiler design tutorial I’ve recently written. The dirty little secret is: I do it for myself. I wrote the compiler tutorial because I wanted to learn compiler design. I wrote OpenCL bindings because I wanted to learn OpenCL. I suppose I could even say that my willingness to help others to has a slightly selfish motivation; the joy I get out of being the one to help somebody else is certainly a factor in what motivates me to do the things I do.

Lately, however, I’ve been losing steam on a lot of these projects. I’ve been realizing that my lack of recent motivation is due in part to this looking inwardness that I’ve been guilty of for a while now. Rather than take somebody else’s problem and help them for the sake of their problem, I take my problems and apply them to others. This is hardly a sustainable way to live life. The problem lies in focusing too much on either end of the spectrum. I came to my own problems after being bombarded with contract work and clients looking for solutions to their own problems. That life was equally unsustainable, and likely drove me to the need to focus on myself. The conclusion? It’s just as bad to focus exclusively on my problems as it is to focus exclusively on somebody else’s.

The good thing is I’ve also been remembering another dirty little secret: I like to solve other people’s problems too. In fact, I’ve realized I get just as much joy out of solving someone else’s problem as my own. I write this in part as a confession, but also in hopes of being a footnote to somebody else. Solving your own problems is great, and anyone who has that opportunity should apply it often. But a skill like that should be shared with others as often as it is applied to oneself. The important part is balance. If you’re focusing exclusively on your client or boss’s problems, you need to change that and start writing some code for you. Something perhaps completely selfish. Just don’t quit your day job while doing it; variety is what keeps us fresh and motivated to solve problems, all problems.

Most blogs and articles I’ve seen that try to explain continuations get it wrong. They bore you with low level details that confuse you in the first place, or scare you by starting with the premise that “it’s complicated, but I’ll try to make you understand”. I’m not going to do either, I’m actually going to explain continuations in two words, and I want you not to laugh, cry, or vomit on yourself when you read them:

GLORIFIED GOTOs

Oh no, I just said a dirty word, didn’t I. You may have your own irrational fears of the goto statement, but you probably know what they are and how they work:

#include <stdio.h>
int main() {
  int i = 0;
  printf("%d\n", i);
  goto some_label;
  i = 1;
  some_label:
  printf("%d\n", i);
  return 0;
}

The above snippet of working C shows how we can jump to different points in a function. It prints 0 twice instead of 0 followed by 1, as you would expect. Language evolution has mostly deprecated this form of programming through method calls and, more intricately, exception handling. These new practices are really just syntactic sugar on the old goto concept. Hopefully all those who scoff at any mention of goto will one day sit down and realize that they’re a central part of how computers work, but I’m getting off topic. The point is, whether you use gotos or not, they’re extremely simple to understand. In fact, they’re exactly as simple as continuations; let’s re-write the above using those “scary” guys:

def main
  i = 0
  callcc do |label| # callcc gives us ‘label’, a continuation object
    puts i
    label.call # this is our "goto" statement
    i = 1      # we skip this completely
  end          # this is where our "label" would otherwise sit
  puts i
end

To those in the know, this doesn’t really show off the full-extent of callcc’s powers (that comes later), but you can look at "label.call" as the equivalent of "goto label", and the end of the callcc block is where the label would be. That’s basically how continuations work.

If you’re having trouble parsing the above: the little trick to understanding the code is simply realizing that the block that callcc yields is executed immediately, once, and only once. It’s simply there so you can do any one-time initialization with the continuation you’re creating. The end of the block is where any subsequent calls to the yielded continuation object will go, not the block itself.

NOW YOU KNOW.

So what, is it really that simple? Continuations are another way to write gotos? The answer is: pretty much. There are actually only two functional difference that makes them even more powerful than the above C-style gotos, but one that makes them a little less-so.

More Powerful, How?

1. They’re not local to your method. Simply put, we can’t do the following in C:

// a() is called by main()
void a() {
  printf("hello world\n");
  label1:
  printf("then you say...\n");
  b();
}
void b() {
  printf("then I say...\n");
  goto label1;
}

This should print "hello world" followed by "then you say", "then I say", in a never-ending loop. Problem is, it won’t compile. Without getting into the nitty-gritty of why C can’t do this, I’ll just simply show how we can actually get away with it using continuations:

def a
  puts "hello world"
  callcc {|cc| $label1 = cc } # pretend this says "label1:"
  puts "then you say..."
  b
end

def b
  puts "then I say"
  $label1.call # pretend this says "goto label1"
end

As the comments indicate, this is almost a one-to-one translation of the C code above. Our continuation object is set to a global variable, essentially making it a “global label” that can be goto’d by running the method #call (picture it as “label.goto” instead of #call).

2. They maintain stack-frame state. That’s the reason why labels in C are local to a function, because you can’t just jump between functions without switching stack frames. Actually, there are tricks in C to do just that (namely longjmp and setjmp to jump to arbitrary addresses and continue execution which is actually how continuations are done in C), but we’re focusing on Ruby here, right? Basically, the continuation object yielded from callcc (the {|cc| thing}) contains a snapshot of our stack frame at the point it was yielded at (remember, the block is only yielded that first time). This allows us to jump between methods in a class, between classes, and jump back from a nested call when we are arbitrarily deep in a stack frame.

Anyone Up For A Quick Real World Example?

The last situation is the one with some real world usage. Imagine we’re writing a web framework with a Rails-style before_filter and we want the ability to halt the execution during a filter and jump all the way back up to the router code to find the next matching route. Sinatra (sort-of) does this with the `pass` method, and though it probably doesn’t use continuations to achieve the result, the concept here is a perfect example of wanting to jump back through our stack frames arbitrarily. We could be 3 method calls deep, or we could be 20 method calls deep, but we need to “go to” a specific point in our program execution. Usually, people implement this with try/catch style exception handling (RouteAbortError maybe), but continuations may be a little cleaner depending on the scenario (we might have a method handling the exception 3 method calls up, but we want to jump 7 method calls up to the initial point in code).

Less Powerful, How?

There’s one thing you may have noticed from the initial example, it’s that jumping forward looks different from the example where we jumped backwards. The limitation is that continuations can’t actually jump forwards, at least not between method calls. The reason is that in C, labels are compiled into the program statically, but in Ruby, the continuation objects are created at runtime. This means that we’d need to execute that callcc call in our future method to generate the continuation, but we can’t run code that hasn’t yet been run. In short, continuations are great for jumping back in time, not quite so for jumping forwards.

Final Correction

So I initially called continuations “glorified gotos”. Hopefully this got you to understand the simple concept behind their use; but now I should fess up and modify the definition just a little bit to be slightly more accurate. Instead of glorified gotos, think of continuations as:

GLORIFIED, STATEFUL, BACKWARDS JUMPING, GOTOs

Now that you know what the fuss is about, you can decide to hate continuations all you want.

invalid multibyte char (US-ASCII)

- OR -

CompatibilityError: incompatible encoding regexp match (Windows-31J regexp with UTF-8 string)

The errors themselves are relatively self-explanatory. Ruby 1.9 is far more Unicode aware than 1.8, and this error happens when have some Unicode (usually UTF-8) in one of your files. What you have to do to fix these, however, is not always as straightforward.

Well, after some time pulling my hair out, I’ve figure out that the solutions to these issues are actually quite simple.

Invalid multibyte char (encoding here)

If you get this issue, add the following to the top of each exploding file (below the shebang if there is one):

# encoding: utf-8

Note: You can also use "coding:" or even the Emacs style -*- encoding: utf-8 -*- but I like the simple term, ‘encoding’. Also note that you might need to replace ‘utf-8′ wth your specific encoding if it’s something else.

This should resolve the issue.

Basically, Ruby by default assumes that every file is encoded as US-ASCII, and so when it reads UTF-8 (or any Unicode) it freaks out because it is beyond the 7-bit encoding. You have to tell it that the file is encoded as utf-8 by listing it as we did at the top of the file. Yes, it’s a little anal, but I’m sure we’ll get used to it.

Incompatible encoding regexp match

This issue is a little bit hairier. I had this problem with the BlueCloth 1.0.0 gem (on line 972 of bluecloth.rb). It turns out that there are a few switches that turn on specific encodings, and for some reason BlueCloth turns on the //s switch which enables the SJIS encoding (maybe John Gruber wanted //m for multiline?). Ruby 1.8 didn’t mind having this on, but 1.9 freaks out. Moral of the story, when you see this error, check your Regexp switches.

I need a mini-framework

I’ve been looking at all these different frameworks to find something that can run more efficiently on my tiny little ghetto server, because I don’t have the resources to run these memory hogging rails apps for my relatively tiny websites. I really need a small framework for the kind of apps I make. You know, pull out a quick blog, wiki, or other, with no DB access at all. What about Camping? No, that’s a little too small. I settled on Merb. Merb is considerably bulkier than Camping, and for a bit I was wondering if even it was too much, until now…

The Merb guys have just released a developer version 0.9.0 which has some neat changes, but what definitely caught my eye was (from the last few lines of the post) the --very-flat option for the application template generator. No need to explain, I’ll just show you how awesome it is:

titanium:merb jinx$ merb-gen blog --very-flat
Fri, 15 Feb 2008 22:57:23 GMT ~ Not Using Sessions
RubiGen::Scripts::Generate
      create  /blog.rb
      create  /README.txt

Now, if we load up the one file created for our project:

Merb::Router.prepare do |r|
  r.match('/').to(:controller => 'blog', :action => 'index')
end

class Blog < Merb::Controller
  def index
    "hi"
  end
end

Merb::Config.use { |c|
  c[:framework]           = {},
  c[:session_store]       = 'none',
  c[:exception_details]   = true
}

BAM!

Imagine that? That's all there is to our app. That's the entire source code-- program logic, configuration and support files. It's fully executable as its own application with the command merb -I blog. Microframework indeed. Granted, it's pulling all of the 'merb-core' gem, but that's pretty small. This code is super portable (in the put-it-on-a-usb-key sense, not the platform-to-platform sense) and really quick to develop with. Step aside, Camping.

Granted, I don't think I'll use this method of development since it's the same reason I won't use Camping, but it's nice to know I can drop down to the really simple level if I need to just prototype one quick "one-button" app and still have room to grow it out. The fact that Merb can actually do this is what's most mindblowing. It's a true testament to the modularity and extensibility of the framework's design. Getting Rails to run without ActiveRecord is a pain enough, let alone pulling out everything but routing and controllers.