Attendee James McElhiney beat me to the punch with his review, but I still wanted to take a few minutes to talk about how things went.

We started with Boston, and then moved to Chicago, Austin, Los Angeles and Seattle. Our partners Amazon Web Services, CVSDude, New Relic and Soasta joined us for the trip, meeting with various customers, developers and managers. The crowd was varied, highly technical, and despite the early-morning start, had great energy.

The Roadshow was all about performance, and between the presentations and audience questions, we covered close to everything you’d need to know to meet and exceed your performance goals. Some specifics:

Tom Mornini and I presented Engine Yard’s value proposition, along with a live demo of the Engine Yard Cloud platform. Tom focused on end-user performance and the very significant impact it can have on business metrics, while I went into detail on some performance metrics that should be relevant to all rails developers, highlighting how Engine Yard Cloud can help users scale in the cloud.

Next New Relic walked us through RPM, and how they use it internally to monitor, well, RPM. Self-referential coolness aside, it was a great way to see how a tool can help you identify the bottlenecks in your application, while still remaining easy to setup and maintain. When the first audience question started with “I’m signing up for your service even as I ask this…” we knew things were on the right track.

CVSDude’s Willie Wang presented on enterprise-grade source control management, and how their solutions can help achieve agility in deployments. This is a key component of performance optimization—agile deployments enable us to fix performance problems faster and deliver features to customers more effectively. With Git support in their near-term roadmap, CVSDude was a great addition for our Rails audience.

Many of the attendees were customers of Amazon AWS, and Mike Culver’s presentations described the value proposition of AWS very well. The Amazon team had a busy week—with newly announced services, instance types and a price reduction (which we at Engine Yard immediately passed along to our customers). As expected, a lot of the questions were around their new announcements, and Mike explained how each of these increased the value proposition of cloud computing even more.

Finally, Soasta’s Dave Murphy had a great presentation on load testing using Soasta Cloud Test. Some of his numbers were particularly impressive—seeing them use cloud infrastructure to deploy multi-million user load tests on live production environments really brought home the value of using the cloud model. Tools like CloudTest, in conjunction with Engine Yard, can make it trivial for users to test deployments that would have been impossible to test before.

For me personally, the roadshow was a great way to meet customers, developers and spend cycles understanding their needs better. The biggest takeaway for me was that customers really care about scalability, but realize that they add most value by focusing on user happiness. This was exactly the philosophy we used while designing Engine Yard Cloud—we want you to continue to focus on features that add value to your products, and leave all your scalability, performance and agility needs to the Engine Yard Cloud platform.

If you missed the Roadshow, be sure to register for our upcoming Engine Yard Cloud Demo Webinar; I’ll be walking through some of the topics covered at the Roadshow and taking questions.

We look forward to visiting more cities soon. Until then, enjoy the presentations, and send us your comments and feedback!

(Update: We think the rule-set below is now complete, but we still welcome any suggestions or tweaks that you might have.)

There will be three prizes.

• The first prize (a Motorola DROID and $1,000 of Engine Yard Cloud credit) goes to the person who completes our challenge task correctly first.
• Second prize (a DROID and $500 of cloud credit) goes to the person who builds the most popular WASE endpoint (the one used the most often in the most submissions).
• Third prize (a DROID) goes to the “best” WASE endpoint written in Ruby (as determined by us). The contest DROIDS are full price, non-contract-linked, US models.

How WASE Works

Why is WASE the worlds worst app server technology? Well, instead of a sane message bus like AMQP, WASE uses Twitter as its message bus. Instead of a proper message router, WASE uses a list of twitter accounts as its program listing. And instead of encapsulating data with each message, WASE messages only contain a reference to JSON objects or arrays at input and output location(s) specified by a bit.ly.

“This Sounds Like the World’s Worst App Server. Tell Me More.”

Well here is an example of how a sample computation might work. Let’s say @engineyard wants to take a JSON file containing an array of names, and get a list of  the top quartile of names after sorting the array. We know that there are two Twitter accounts (which we will henceforth call WASEpoints) @ey-sort and @ey-firsthalf that can be useful to us. We know @ey-sort takes an input data set, sorts it and outputs the result. We also know that @ey-firsthalf takes an input data set, and outputs the first “half” of the dataset. To perform a computation, we set up URI’s for the program listing, the input data and the output data, and kick off the computation with an appropriate message. (For those of you with dataflow or actor-based programming experience, WASE should look like a vague, but disreputable cousin.)

So let’s go through the message flow:

We’ll put our program listing at:

www.engineyard.com/top-quartile-sorted-list.json,  (bit.ly/7yQK6) whose body contents are a JSON array:

["@ey-sort", "@ey-firsthalf", "@ey-firsthalf", "@engineyard"]

We put our input data here:  www.engineyard.com/unsortedmegalist.json (bit.ly/3kl0xs)

And set up a location for our output data here:  www.engineyard.com/top25percentofmymegalist.json (bit.ly/2uhGcl)

Or to summarize the bit.ly’s,

Program listing: bit.ly/7yQK6 (read with a http: GET)

Output location: bit.ly/2uhGcl (written with a http: PUT)

Input location: bit.ly/3kl0xs (read with a http: GET)

To perform the computation, we’d simply send the following twitter message from our @engineyard account: @ey-sort #wase, 0, bit.ly/7yQK6, 1256850843, bit.ly/2uhGcl, bit.ly/3kl0xs

So the message format of a WASTE message is: [WASEpoint], [WASE hashtag] [Program Counter (0 initially)], [Program listing URI], [Unix Timestamp], [Output URI] [,Input URI (optional)] [, Input URI 2 (optional)]

In the case of this computation, the message and computation sequence would look like:

• @engineyard sends: “@ey-sort #wase, 0, bit.ly/7yQK6, 1256850843, bit.ly/2uhGcl, bit.ly/3kl0xs”

…. @ey-sort reads the message from @engineyard in its twitter list and parses the message. First it GETs the program listing from bit.ly/7yQK6, GETS the input data set from bit.ly/3kl0xs, sorts it, PUTS the output to bit.ly/2uhGcl, then looks for the 0+1 WASEpoint in the program listing (@ey-sort) and then..

• @ey-sort sends: “@ey-firsthalf #wase, 1, bit.ly/7yQK6, 1256850875, bit.ly/2uhGcl”

…. @ey-firsthalf reads the message from @ey-sort in its twitter list and parses the message. First it GETs the program listing from bit.ly/7yQK6, GETS the input data set from bit.ly/2uhGcl, halves it, then PUTS the output to bit.ly/2uhGcl,  looks for the 1+1 WASEpoint in the program listing (@ey-firsthalf) and then..

• @ey-firsthalf sends (to itself): “@ey-firsthalf #wase, 2, bit.ly/7yQK6, 1256850885, bit.ly/2uhGcl”

… etc. …

• @ey-firsthalf sends: “@engineyard #wase, 3, bit.ly/7yQK6, 1256850899, bit.ly/2uhGcl”

— finally @engineyard receives this message with the pointer to the final location of output data.

A few new things here. There’s a program counter that tells the WASEpoint where in the program listing the computation is, and there’s a Unix timestamp (could be useful for discarding messages that get held up in the twitterverse?). If no input URI is specified, then the WASEpoint should use the Output URI as both Input and Output locations. One restriction that we will enforce for the contest is that a WASEPOINT MAY NOT DECREMENT A PROGRAM COUNTER: to avoid infinite looping. (Update: And a WASEpoint must conserve the program listing and output URI’s from the input to the output message.)

Hey, maybe we should have some basic error handling. Hmm, let’s say @ey-firsthalf is expecting a standard JSON object but the input data fails to parse properly. Let’s have it send the following message:

• @ey-firsthalf sends: “@engineyard, #wase, -1, bit.ly/7yQK6, 1256850885, bit.ly/2uhGcl

So the error message structure is: [Update: first WASEpoint in program listing], [WASE hashtag], [Negative of Program Counter], [Program listing URI], [Unix Timestamp], [Output URI] [, Input URI (optional)] [, Input URI 2 (optional)]

Note that there are no type declarations in the message format because the only data-type supported by WASE are JSON objects and arrays.

What are Guidelines for the Contest?

Apart from the message format and data guidelines above — here are additional guidelines:

1. Each contestant may register no more than 5 WASE endpoints/twitter accounts. WASEpoints must be registered here: www.engineyard.com/contests/waste/ to be eligible for use. Your WASEpoints must follow @eycontest. This is also where you should go to pick and choose good WASEpoints for constructing your app. Each contest entry must use a minimum of 10 WASEpoints from at least four separate contestants, where each WASEpoints performs functionally significant data operations.

2. Please do not submit WASEpoints whose twitter accounts you do not own :-) We do not want to encourage the business of spamming Ashton Kutcher with mysterious messages. We will test each submitted WASEpoint with a DM to make sure they are legitimate.

3. Source code for your WASEpoint must be posted to a public repository (e.g codaset, github, sourceforge, kenai) for other contestants to inspect :-) If observed behavior deviates from the posted code (aka you have filed a prank WASEpoint), then your entry and all your WASEpoints will be removed from the registered list.

4. A WASEpoint must not store state, and may not rely on any state data other than the input data (of course, it’s easy to generate a private data set programmatically, but this will also be considered state). Trivial WASEpoints (e.g. identity) will be disqualified, although triviality is hard to define, you know it when you see it.

5. You must use bit.ly as your URL shortener(to make everyone’s job building parsers easier — and bit.ly has a http: interface.

7. Challenge calculations submissions must be in the form of a tweet to @engineyard with the initializing message from your home twitter account. You must be following @engineyard with your home account in order to enter.

8. We must be able to reproduce your computation using your program listing and our own output URL.

9. We STRONGLY encourage people to write their WASEpoints in Ruby, but we’ll also accept Perl, Scala and Python. Although, be prepared for people avoiding your WASEpoint since the common denominator among people reading this blog is the fact that they know Ruby!

10. We may alter these guidelines along the way, based on your input and feedback, although the spirit and philosophy of them will remain.

However, when you have jobs that use resources from multiple machines, lockrun isn’t adequate. Consider a cron job that builds a local index of a bunch of NFS-mounted files. You don’t want more than one consumer of that NFS volume to index it at a time, otherwise performance will be degraded.

Enter distlockrun: it works similarly to lockrun except that it talks to a central server for mutual exclusion instead of locking a file.

First of all, you need the lock server running. It’s really lightweight, so you can run it on any machine you’ve already got. For example, on Engine Yard Cloud, it should be run on the database master in a screen session.

Start the server like so: distlockrun-server

By default, it starts on port 7890, but that can be changed with the --port option.

Then, on the client, run your job as follows: distlockrun --server {server's hostname} big-expensive-indexer.rb

If there’s already a big-expensive-indexer.rb running, then distlockrun will just exit. Otherwise, it runs the job and then tells the lock server that it’s finished.

That’s all it takes to get cluster-wide mutual exclusion; short but sweet!

All versions of nginx prior to 0.8.15, 0.7.62, 0.6.39 and 0.5.38 in the 0.8, 0.7, 0.6 and 0.5 nginx codelines are vulnerable.

Engine Yard customers have already been contacted via email about this issue. For Engine Yard Cloud customers, this patch will be automatically applied the next time you perform a deploy. All other customers should open a support ticket so that you can arrange an appropriate maintenance window with support.

Effective November 1st, we will be reducing the prices that we charge for instance hours in Engine Yard Cloud, passing through the announced price reduction in Amazon EC2 pricing. These prices will be in effect automatically for the November billing cycle. New and existing customers will not have to do anything to activate the new pricing, you will get the price reduction automatically starting with your November usage.

This table displays the current and new pricing for Engine Yard Cloud instance hours:

Our main web-site and pricing pages will be updated on November 1st to reflect these new prices. As always, we’re here to address an questions or comments, and look forward to hearing from you!

In this post, I’ll explain what I’ve been doing and how it relates to getting Rubinius ready for 1.0. We recently released version 0.12 and we’re going to be doing releases about every two weeks. If you haven’t built Rubinius yet to check it out, head over to our download page and get started!

Principles

Before we get into code examples, let’s lay the groundwork and review some general principles for writing software. We learn early in computer science that programming involves a series of trade-offs. There’s always the the classic trade-off between execution time and storage space. If we write a function that saves each value it computes, it can return the saved value instead of re-computing it, but saving the value requires using memory or disk space. A function that computes millions of values would potentially need millions of storage locations.

While speed versus space is probably the most well-known classic trade-off, there are others. With a nod to Philip Kapleau, here are the three pillars of developing Rubinius: Code Quality, Compatibility, and Performance, or QCP. These interact in complex ways and there’s no simple way to prioritize them. By compatibility, I mean conforming to the same behavior as MRI (or Matz’s Ruby).

These three characteristics are interdependent. Clean, high-quality code enables working more quickly on compatibility. When code is behaving correctly, it’s easier to profile and improve performance. Good performance, in turn, can make it easier to identify and fix compatibility issues. Quality code is easier to understand and work with when improving performance. These feedback loops push each of these code characteristics forward. The converse is also true. At times, it may be tempting to sacrifice quality to improve performance, but quick and dirty never pays off in the end.

To sum up, these are the goals we’re pursuing: simplify and improve the bytecode compiler code, improve performance, make it simpler and easier to bootstrap Rubinius, and ultimately make it easier to fix compatibility issues running fantastic Ruby software, like your Rails applications.

Parsers and Compilers

There’s a certain mystique that surrounds compilers. Rather than just accept the mystique, let’s take a peek behind the unicorns and dragons and check out the simple gears and pistons that make it all work. In general terms, a compiler is a process for converting data from one form into another. In the specific case of Ruby, the compiler converts text in the form of Ruby syntax, into operations performed by the computer’s CPU.

In discussing compilers, two rather distinct operations are often lumped together, namely, parsing and code generation. Parsing is the process of converting the source code into a data structure that the compiler can process to produce code that the computer, or a virtual machine, can execute, to perform computation. There are specific issues with each operation so let’s look at them separately.

A. The Parser

Humans are the most adept and complex parsers in existence. One natural language can choke up a powerful computer, but humans typically handle one and sometimes several languages with relative ease. Not just the words or sounds of a language either, but also the intonations, facial expressions and body language that accompany even the simplest communications.

Compared to natural languages, programming languages are very simple, but even the simplest languages can be challenging to parse. Syntactically, Ruby is a rich and complex language. We love it for the expressive programs we can write—but parsing Ruby is hard. Every Ruby parser in the Ruby implementations that I know of are based on Matz’s parser. From the beginning, Rubinius has used a directly imported version of Matz’s parser with a few minor modifications.

Detour—Bootstrapping

Before continuing, we need to take a short detour. I’ll be writing a post on the Rubinius bootstrapping process in the future, but I’ll start by briefly describing part of the problem here.

The Rubinius bytecode compiler, and most of the Ruby core library (classes like Array and Hash), are written in pure Ruby—and herein lies the challenge. The Rubinius VM interprets bytecode. To run the Rubinius compiler, it needs to translate the Ruby source code for the compiler into bytecode, but to do so, Rubinius needs to run the compiler. You can probably see where this is heading: around and around without getting much done.

That is the essence of the problem of bootstrapping. To break this loop, we need to insert a process that does not depend on Rubinius. In other words, we need something that’s not Rubinius to compile the core library and bytecode compiler so that Rubinius can load the bytecode and run the compiler. Then Rubinius can compile its own compiler and core library.

One way to do this would be to load the Ruby source code in MRI and use the ParseTree gem to extract the MRI parse tree as a recursive array of symbols and values, something also known as an S-expression or sexp. But, since you can’t change the MRI parser without impacting its run time behavior, Evan Phoenix wrote the sydparse gem.

This gem is essentially a C extension combining the MRI parser with the sexp generation code from ParseTree. The gem enabled Evan to modify the parser if desired and get the parse results as a sexp. The sydparse gem is basically built into Rubinius currently under the vm/parser directory.

For example, try the following code:

$ bin/rbx
irb(main):001:0> "a = 1".to_sexp
=> s(:lasgn, :a, s(:lit, 1))

So, with the String#to_sexp method, we have something that will take Ruby code and transform it to a data structure that should be fairly easy for a computer to process. And that is precisely how the early Rubinius bytecode compiler worked: it processed sexps into bytecode. It didn’t matter whether the sexps are output by sydparse running in MRI or by the Rubinius built-in parser. With that, a big part of bootstrapping was solved.

Back to the Main Road

So we’ve got a compiler that processes sexps to bytecode and it runs in both MRI and Rubinius. Everything sounds copacetic—what’s the trouble, you ask? Well, compiling Ruby is hard, too.

To make the process more tractable, Evan rewrote the compiler so that the sexps are processed into an abstract syntax tree (AST) of Ruby objects. Each object has a #bytecode method. To generate bytecode, start at the root of the tree and visit each node, calling the bytecode method for the node.

For perspective, let’s enumerate all the stages in the compiler. I’m glossing over a few details here, but you’ll see the basic picture:

1. parse tree: A tree of C data structs created by the MRI parser.
2. sexp: A recursive array of symbols and values created by processing the MRI parse tree.
3. rewritten sexp: The form of the sexp after certain structures are normalized to make converting the sexp simpler.
4. AST: The abstract syntax tree of Ruby objects created by processing the rewritten sexp.
5. bytecode: A stream of instructions that the Rubinius VM can execute.
6. compiled method: The bytecode packaged with some additional information like the names of local variables and the amount of stack space needed when the compiled method runs. A typical Ruby source code file compiles to a tree of compiled methods.
7. compiled file: The Rubinius VM can execute the compiled methods directly. But to avoid having to recompile them, the tree of compiled methods is serialized to a compiled file on disk. Rubinius can read the compiled file to recreate the tree of compiled methods in memory.

That’s a significant number of stages and it’s not hard to see where we can simplify to improve the process. Those sexp stages appear to just be passing data along. In fact, they require creating a lot of additional objects, time to process, and some seriously complex code to process them. The latter has a significant, negative impact on code quality.

S-expressions are just data, dumb and brittle. They only have form (e.g. [:x, :y] versus [:x, [:y]]) and position (e.g. [:alias, :x, :y] versus [:alias, :y, :x]) to encode information. If you wanted to add, for example, a line number to every sexp, you’d need to put the information in a form and at a particular position in every sexp, or you’d need to wrap every sexp in one that encodes the line number. The simplicity of sexps is beguiling, but you know what they say when all you have are s-expressions… Everything looks like function application.

On the other hand, we have this rich, object-oriented language that makes it trivially easy to create objects that conform to a consistent interface. We want to get from the Ruby text to Ruby objects as quickly, and simply, as possible.

One option would be to write the compiler so that it processes the MRI parse tree directly into bytecode. Unfortunately, that would require either rewriting the compiler in C (not gonna happen) or making the C data structs available in Ruby. The latter option sounds promising. We could translate the parse tree directly into an AST.

Melbourne

Enter Melbourne, a C extension that can run in MRI or Rubinius and process the MRI parse tree directly into an AST. In case you were wondering, it was named in honor of Evan’s sydparse gem, and some rowdy Aussie developers we know.

In Melbourne, each node of the MRI parse tree is processed using a mechanism we all know and love: a method call. At each parse tree node, all children are processed by recursively calling the process_parse_tree function (see lib/ext/melbourne/visitor.cpp). At a leaf node, there are no children to create, so an appropriately named Ruby method is called on the Rubinius::Melbourne instance that is passed to process_parse_tree.

Once all of a node’s children are created, a method is called for the parent node, passing along the objects that were already created for the node’s children. You can see the result of this process by running the following command:

$ bin/rbx -r compiler-ng -e '"a = 1".to_ast.ascii_graph'
LocalVariableAssignment
  @line: 1
  @name: a
  FixnumLiteral
    @line: 1
    @value: 1

In lib/melbourne/processor.rb, you can see code like the following. Whenever a local variable assignment parse tree node (lasgn) is processed, this method is called and the LocalVariableAssignment AST node is created. Pretty straightforward.

def process_lasgn(line, name, value)
  AST::LocalVariableAssignment.new line, name, value
end

One of my goals for improving the code quality in the compiler was to replace the use of conditionals by creating more explicit nodes in the AST. Sometimes code suffers from what I’d call conditionalitis, or inflammation of your conditionals (sounds painful, huh?). That’s where you maintain a lot of state and use conditionals to figure out what to do.

An alternative is to create different forms of things that just do what they are supposed to do. Simply avoiding using conditionals is not really an option, but where they’re used can have a big impact on code quality. It’s can be hard to understand by just looking at the code why one branch or the other would be taken when the program is running, but when the conditional results in different forms being created, it’s much easier to comprehend how the program will behave

For example, in MRI a.b = 1 and a[b] = 1 are parsed into the same parse tree node. But there are enough things that need to be done differently in the two cases that just creating different forms can make these tasks simpler and more explicit. The code in lib/melbourne/processor.rb for processing an attrasgn node looks like this:

def process_attrasgn(line, receiver, name, arguments)
  if name == :[]=
    AST::ElementAssignment.new line, receiver, arguments
  else
    AST::AttributeAssignment.new line, receiver, name, arguments
  end
end

B. The Compiler

By this point we have a fully formed AST that faithfully represents the Ruby code we started with. Emitting bytecode now is almost anticlimactic. Not really, of course, because there is plenty of work left to do. Just keeping track of local variables in methods, blocks and evals could take up a whole post, but the basic idea is really simple. Start at the root node and call the #bytecode method, walking down the tree until every node has been visited. All the details (and there are a lot of them) can be found in the #bytecode methods on the AST nodes (see lib/compiler-ng/ast).

Besides generating bytecode, there are other interesting things you can do simply by defining methods on the AST nodes and visiting them. I’ll give you two examples. First, let’s look at defined?.

# defined.rb
class A
  class B
  end
end

def x
  puts "hey there"
  A
end

p defined? A::B
p defined? x::B

If you run this code in Ruby, you should see the following output.

$ ruby defined.rb
"constant"
hey there
"constant"

This code illustrates something about defined?. It doesn’t just check internal data structures. In some cases, like x::B, it must do some evaluation.

In Rubinius, we simply add a defined(g) method to any relevant AST node that takes an instance of the bytecode generator object and emits bytecode appropriate for evaluating the expression passed to defined?. Here is the full code for the Defined AST node.

class Defined < Node
  attr_accessor :expression

  def initialize(line, expr)
    @line = line
    @expression = expr
  end

  def bytecode(g)
    pos(g)

    @expression.defined(g)
  end
end

Rather than emitting bytecode, it’s possible to simply evaluate the AST, performing actions when visiting each node. Rubinius has an evaluator for being able to write bits of code for which there is no simple Ruby syntax. The evaluator makes it possible to write directly in Rubinius assembly language (i.e. in the operations that the VM directly executes). Consider this example:

# asm.rb
def hello(name)
  Rubinius.asm(name) do |name|
    push :self
    run name
    string_dup
    push_literal "hello, "
    string_dup
    string_append
    send :p, 1, true
  end
end

hello "world"

If you run this in Rubinius, you should see the following output:

$ bin/rbx asm.rb
"hello, world"

Of course, this example is much easier to write in plain old Ruby. However, we use this facility in the Ruby core library. For example, in the Class#new method.

The basic idea is that a tree of Ruby objects representing Ruby source code is a powerful tool that can be easily extended to accomplish various tasks.

Compiler, Part Deux

Let’s revisit the list we presented earlier of compiler stages. How do we coordinate those stages? What if we need to insert a stage? Well, by creating more things we can name, and on which we can define behavior.

You can see the various stages laid out in lib/compiler-ng/stages.rb. By default, each stage know which stage follows it. You create an instance of the compiler by specifying the starting stage and the ending stage. Each stage has an interface with the preceding and following stage, with the compiler object itself, and with the object that performs the work for that stage. For example, if the compiler will compile a String to a CompiledMethod, it will consist of the StringParser, Generator, Encoder, and Packager stages.

The goal was to create an API for the compiler that made it simple to use programatically in a variety of circumstances. For example, using the compiler internally to compile a Ruby file when #require is called or in a command line script like lib/bin/compile-ng.rb. The command line script may give the option to show the data structures as the compiler is processing them. Here’s an example:

$ cat var.rb
a = 1
p a

$ bin/rbx compile-ng -AB var.rb
Script
  @name: __script__
  @file: "var.rb"
  Block
    @line: 1
    @array:
      LocalVariableAssignment
        @line: 1
        @name: a
        FixnumLiteral
          @line: 1
          @value: 1
      SendWithArguments
        @line: 2
        @name: p
        @privately: true
        Self
          @line: 2
        ActualArguments
          @line: 2
          @array:
            LocalVariableAccess
              @line: 2
              @name: a

============= :__script__ ==============
Arguments:   0 required, 0 total
Locals:      1: a
Stack size:  3
Lines to IP: 1: 0-4, 2: 4-14

0000:  meta_push_1
0001:  set_local                  0    # a
0003:  pop
0004:  push_self
0005:  push_local                 0    # a
0007:  allow_private
0008:  send_stack                 :p, 1
0011:  pop
0012:  push_true
0013:  ret
----------------------------------------

$ bin/rbx var.rbc
1

Take a look at bin/rbx compile-ng -h for more options and try this out on your Ruby code. It opens up a pretty exciting world of understanding.

A Final Note

Melbourne and the new compiler will both be enabled in the up-coming 0.13 release, so anywhere I’ve used compile-ng or compiler-ng in this post, will become just compile or compiler. Until then, all the code exists in the Rubinius Github repository, so you don’t have to wait to check it out.

Thoughts? Questions? Leave them here!

Library What, Huh?

What makes libraries so special? They save time and effort by providing code you don’t want to write. Skip the nitty gritty of this authentication scheme or that request protocol and get on with the task at hand. There are many ways for a library to capture wily domain knowledge and not all are created equal. After working on some libraries and reading many more, what follows are my personal guidelines for creating lovely encapsulating bits.

First, Do No Harm

It should be easier to work with a library than without it. People will grudgingly use libraries that are painful, but will recommend and rave about libraries that feel good. You should start with some idea of what an ideal interaction with the library might feel like. Your first pass at implementation will tend to be rough work, but keep utopia in mind. Subsequent iterations can work to unify reality and awesome.

This happened when I wrote shindo, a test framework that I wrote because I wanted something short and sweet. I have a love/hate relationship with testing. I like the confidence that tests give me, but I’m just not a big fan of the process. Shindo lets me easily understand what’s actually happening when tests run. It looks like this:

# Each test is a Ruby block, with success determined by return value
Shindo.tests('examples') do
  test('successful test') { true }
  test('failing test')    { false }
  test('pending test')    # no block provided
end

My first pass at implementation was basic, but then I started iterating. I wanted the runner to be more interactive than what I was used to. So I added a prompt system that halts the test run when it runs into an error and asks you what you want to do. This led to rapid iterations:

1. I needed backtraces, but I didn’t want to raise errors. So I wrote a nice backtrace object and added some code to view its output.
2. I wanted a better way to sift through files referenced in the backtrace, so I added the ability to choose a line from the backtrace and get an excerpt of the file containing it.
3. I wanted a better way to debug errors, so I added the choice to launch irb with the same binding as the test block. That’s my kind of digging in.
4. There was no need to run all the tests all the time, so I added tags to help narrow a run down to the relevant ones.
5. Finally, I added the option to reload files and restart the test run.

Keep It Simple

Libraries should be less complicated than the problems they address. Simple libraries are easier to understand, improve and maintain. Abstractions are a tempting place to start, but they are easier to build on a solid foundation. Start with the simplest thing that could work, staying close to the problem you are trying to solve. For instance, when wrapping public APIs, match the names of attributes and functions to the API documentation. It makes it easier to refer to things and provides documentation from the start.

When I found out I would be joining the Engine Yard Cloud team, it occurred to me that I should have more than a passing knowledge of AWS. I started by reading tons of docs. Equipped with a rough idea of what was involved, I wanted an easy way to experiment and code AWS. Such was the genesis of fog.  AWS interactions can be super complicated, so I started by mapping the docs almost directly to code. Using it looks like this:

s3 = Fog::AWS::S3.new(
 :aws_access_key_id => id,
 :aws_secret_access_key => key
)

# get a list of buckets
s3.get_service

# create a bucket
s3.put_bucket('bucketname')

# get the contents of that bucket
s3.get_bucket('bucketname')

# delete that bucket
s3.delete_bucket('bucketname')

I’ll be the first to admit that its not the prettiest, but it worked! And when in doubt, the AWS documentation could remind me what in the world some method I wrote a month ago was supposed to do. Recently someone asked if I had generated this code somehow. I wrote it all by hand (unless you count copy/paste as code generation), but for once it was oddly comforting to be mistaken for a robot.

Stay Focused

Stick to capturing stuff for one problem at a time. If sub-sections start getting distracting, consider extracting them into their own libraries. Avoid monkey patching; use inheritance or something that is not monkey patching. Premature optimization is the root of all evil, iteration is the trunk of all good. Do not undermine your tree, and do furnish it with leaves of documentation so that it does not wither and die.

While working on shindo, I ended up adding lots of backtrace related code. Since I was not relying on raised errors, I needed some other way to control starting and stopping tracing. At first it was small and self-contained, like this:

class Annals

  attr_accessor :buffer, :max

  def initialize(max = 20, &block)
    @max = max
    start
  end

  def lines
    @buffer.map do |event|
      "#{event[:file]}:#{event[:line]} #{event[:method]}"
    end
  end

  def start
    @buffer = []
    @size   = 0
    Kernel.set_trace_func(
      lambda { |event, file, line, id, binding, classname|
        if event == 'call'
          unshift(:file => file, :line => line, :method => "in #{id}")
        end
      }
    )
  end

  def stop
    Kernel.set_trace_func(lambda {})
    @buffer.shift # remove Annals#stop from buffer
  end

  def unshift(line)
    @buffer.unshift(line)
    if @size == @max
      @buffer.pop
    else
      @size += 1
    end
  end

end

But it just kept growing. So I pulled it out into its own project, annals. After extraction I could proceed to add other handy backtrace related features, even ones I had no real need for just then. Small libraries like this make great building blocks for newer, crazier stuff.

Add Value

Once equipped with more knowledge about the problem than is healthy for any one person, abstraction is a go. Tackle low hanging fruit first. Ruby is, afterall, object-oriented, so consider providing some nice models that encapsulate the nitty gritty bits. Write mocks. No one knows better what mocks should do. Add some command line tools or an interactive mode. Focus on eliminating pain points, increasing usability and generally making the project awesome to work with.

With a good foundation of low level functionality in fog, it was time to start adding value. I added easy mocking, because running tests against AWS can be expensive and slow. Then I started building objects around the various entities. Here is how the objects replace the low level calls from earlier:

# this is optional and great for testing
Fog.mock!

# connection
s3 = Fog::AWS::S3.new(
 :aws_access_key_id => id,
 :aws_secret_access_key => key
)

# get a list of buckets
s3.buckets.all

# create a bucket
bucket = s3.buckets.create(:name => 'bucketname')

# get the contents of that bucket
bucket.objects.all

# delete that bucket
bucket.destroy

The new interface mimics DataMapper, an interface myself and many others are already familiar with. I did my best to abstract away the nitty gritty captured in the low level functionality while leaving the ability to get stuff done. I think it is better, but it is still a work in progress. I dedicate a little time every day to filling in the blanks, but libraries have a way of never truly being finished.

Lather, Rinse, Repeat

Making libraries that capture a domain and feel good to use is hard. Implement the simplest thing first, but never stop iterating. Be absurdly consistent. Keep fiddling with the look and feel. If something seems painful, it probably is, so fix it. Make your code a joy to use and people will reward you by using it, and submitting patches (hint, hint)!

What do you think makes a good library? How can I improve mine? Comment and let me know!

Warning: Most of the code you see in this post should never be used in real life by actual programmers. The snippets are meant to provide insight into the power of Ruby, and more obviously, are for entertainment value.

1. Expressions are Cool

One of the great things about Ruby is that everything is just executable code. In fact, everything is an expression. This makes it nice because you can then programmatically build up a set of methods in a class body, like this:

class Numeric
  MM_SIZE = 0.00025

  [:mm, :cm, :dm, :m, :dam, :hm, :km, :Mm].inject(MM_SIZE) do |size, unit|
    define_method(unit) { self * size }
    size * 10
  end
end

Ignoring the fact that I just modified Numeric, you have to admit that being able to do stuff like this in Ruby makes it a great language; a language with the flexibility to define methods progammatically because everything is just code and expressions.

Over the years of supporting JRuby, I began to realize that the grammar is a bit too too generous. At this point you can argue that it’s up to programmers to hang themselves with any bizarre language feature. So what’s the fuss?

def foo(a, b=def foo(a); "F"; end)
  a
end

p foo("W", 1) + foo("T") + foo("bar")      # => "WTF"

Is there a sane reason to allow a def as the value of an optional argument? Since we have a language where everything is an expression, this is just life in the Ruby lane. Luckily, def returns nil and not UnboundMethod or something that’s considered useful; otherwise there would be some pretty weird code floating around.

Before I go on, I wondered about variable scoping…

def foo(a, b = self.class.send(:define_method, :foo) {|_| ": I captured #{a}" })
  a
end

p foo("foo") + foo("bar")  #=> foo: I captured foo

Of course it makes sense that the optional argument value of ‘b’ evaluates in a scope where it can capture ‘a’… but wow! The potential for strange Ruby code is just amazing!

2. It Makes Sense But…

Other times the grammar has oddities which seem to make sense on the surface but generally confuse you when you start to stray off the path of idiomatic Ruby. Heredocs are a great example:

a = <<EOF
hooray
multi-lines
EOF

This how we normally see them. The idiomatic example may have us define a heredoc as: when encountering a heredoc statement (<<EOF) take all lines after that statement until we encounter the heredoc marker on a line by itself and use those lines as a multi-line string. Certainly, that would still work for this example:

{:skybox => "/data/skyboxes/mountains/",
 :floors => [
  {:location => [0,0,0],:data => <<EOL, :texture => "data/texture/wall.jpg"},
........BCB.........
.........P..........
....................
........DDD.........
.......D....D.......
....................
....D.....D....D....
....................
..D....D....D....D..
...BBBBBBBBBBBBBB...
EOL
  {:location => [0,10,0],:data => <<EOL, :texture => "data/texture/wall.jpg"},
# More elided ...
}

Heredocs in this code are interleaved in the middle of a hash literal… This is odd, but the definition still holds up. Let’s break the definition:

def foo(a,b)
  p a, b
end

foo(<<ONE, <<TWO)
This is one
ONE
This is two
TWO

Two heredocs on the same line break the definition. I think with a little work we could fix the definition to talk about what to do about multiple heredocs on the same line, but then consider this case:

a = <<ONE
This is one. #{<<TWO}
This is two. #{<<THREE}
This is three.
THREE
TWO
ONE    # => "This is one. This is two. This is three.\n\n\n"

Coming up with an easy to read definition is starting to get rough. Maybe just accepting that you can do weird things with heredoc without actually explaining them in a common definition is the right thing to do. Do we really want people to use heredocs this way? Is it cool that we can do stuff like this?

3. Mystical String Concatenation

Ruby’s grammar is huge. Super huge, and sometimes you see something in the grammar that makes you wonder how it got there. For me the one I wonder about the most is what I call the “Mystical String Concatenation” feature:

string        : string1
              | string string1 {
                  $$ = support.literal_concat(getPosition($1), $1, $2);
              }

Since string1 must be a type of string literal this translates into the following Ruby syntax:

a = "foo" "bar"
p a # => "foobar"

Is this really useful? The performance benefit is that the parser will concatenate the string before any execution happens…. but this only works for string literals! A programmer could just rewrite the string as “foobar”. Perhaps someone wanted to inspect strings into an eval statement?

one = "foo"
two = "bar"
a = eval "#{one.inspect} #{two.inspect}"

It mystifies me…

Conclusion

Ruby is beautiful, powerful, and in some cases, wacky. I’ve only just scratched the surface of the weird convoluted things you can do with Ruby’s syntax. What’s most interesting to me though is that Ruby programmers rarely touch these strange bits unless they’re trying to be cute…

Compared to another language I used to always use (it starts with a P and is four letters, but I seem to have completely forgotten its name…), it’s surprising how rarely real Ruby code ventures into the land of the indecipherable.

Both Ruby and the previously mentioned forgotten language are very powerful, and can get a lot of the same things done, but it seems that Ruby code ends up being written in a largely idiomatic way. Ruby may be a rat’s nest for writing a coherent specification of the language, but the Ruby that people write using this underspecified language ends up looking really nice.

The model for the directory was that any firm could add an account, and once they received three customer endorsements, they would be checked as “confirmed” and prioritized in search results. Firms could also add up to three “showcase” projects so that customers could click through and see the quality of work. The goal was to let the work (and the customer endorsements) speak for themselves.

So far, the directory has been pretty successful. It now has about 250 development firms listed. Although we built in a “request for work” submission feature, it’s mostly being used by potential development customers as a way to research firms, rather than as a way to submit work requests, but we have high hopes here. So far, we’ve had a few problems with spam accounts and bogus customer endorsements but not many. As far as development details, the site was built from scratch in Ruby on Rails in 3 weeks, then added 3 weeks of polish before launch.

There are 272 customer endorsements for member work, and as you’ll see from the code, currently, the formula used to return search results is pretty basic:

1. first it includes companies with matching or lower minimum budgets
2. then it includes companies with matching locations (by state in the US and by country everywhere else – this filter is optional)
3. then it orders by whether a company is confirmed (has 3 endorsements)
4. then it orders by how many endorsements a company has
5. then it returns results randomly.

If your company profile is confirmed and you have lots of endorsements, all else being equal, you will rank higher in the search results. But in our experience, matching by budget and location is very important, as it is a qualifying step for most potential customers.

Continuing our support of open source projects and initiatives, and after discussing the directory’s future with some of the community, we felt it made sense to release this directory application as open source, and today we’re officially releasing the source code of the application in a generalized form that can quickly and easily be customized and put into use by anyone that needs a directory site.

You can find the Rails Directory source code released under the MIT License on GitHub at http://github.com/engineyard/rails_dev_directory.

Feel free to fork the repo and review it, play with it, or modify it as you see fit. If you’re interested in contributing to the source code, or have any feedback, drop us a line at info@railsdevelopment.com.

Credit for developing the application in large part goes to Paul Campbell, Nick French and Ben De Jesus here at Engine Yard.

1. It’s easy to forget to compress your JavaScript and CSS

It seems like people are pretty good about gzipping their HTML and images, but for whatever reason, a lot of people forget to tell mod_deflate to compress JavaScript and CSS files. JavaScript payloads are becoming a much bigger percentage of total downloads (even a majority of the payload for many sites), and they’re blocking the rest of the page from loading.

2. Watch out for slow third party services

Some of the big outliers in page load performance are caused by poor response times from third party services. Services like Google Ads and Analytics, Doubleclick, and Facebook Connect can kill your performance if you loading them early, so almost all sites (sensibly) put them as late as possible in the page load. Response times of up to eight seconds from Google Analytics are not uncommon, so this can result in a big road-bump in your page load if it’s in the wrong place. Google Analytics, in particular, uses document.write, so most people have to work around it, but a significant minority of sites don’t.

3. Using multiple image hosts doesn’t always mean higher performance

There’s nothing magical about using multiple image hosts. It should produce higher performance by allowing parallel downloads, but only if you’ve put the necessary resources to work. An interesting performance outlier in the survey was a site that had configured multiple image hosts, but response times from those hosts were multi-second — probably a good sign that they were under-resourced.

4. S3 is NOT a Webserver!

Amazon S3 is a reliable, cheap storage service, but don’t treat it like just another web-server. Response time in the wild was regularly between 0.5 and 1.5 seconds, so make sure that you’re not serving performance sensitive content from it. And if you do, try to use pre-loading to hide latency. Unlike a regular web-server, S3 (still) does not gzip content, so you also need to use a pre-compression utility like Yahoo’s Smush.It to reduce image sizes before you put them up there.

5. Most performance variability is NOT attributable to page factors

When we did the analysis, we found that less than half of total page-load time in our sample was attributable to front-end factors like the number of http requests made by the page, the size of the page payload and whether or not you were scaling images in HTML. A majority of performance variability (a little surprisingly) was attributable to stuff that had nothing to do with page construction (basically network and back-end factors).

To learn more about what we found about average page response time, page size targets and http chatter, as well as what the analysis said about front-end performance, sign up for the Rails Roadshow, coming to a city near you in two weeks time. We’ll be presenting along with our partners New Relic, Soasta, Amazon, CVSDude and more.

See you there!