Monday, July 31, 2006

OSCon Take-aways

I'm just starting my first work week after OSCon, and as I ride the bus in to work, I'm trying to put some order to my thoughts after the conference. There were a grundle of great talks and tutorials, any number of important hallway (or lunch, or whatever) conversations, a bunch of interesting blog posts from other attendees, and (of course) FOSCon. Beyond the things I expected to learn (like more about DSLs in Neal Ford's talk), I took away a number of themes that will play out in my activities over the next several months (and some future blog posts). Here's my list:

Ruby Community

  • The Ruby community is both really big and really helpful — even more than I thought.
  • The Rails community really is a part of the Ruby community — despite my fears to the contrary.
  • Starting & Supporting local/regional Ruby communities is key to the ongoing success of the greater Ruby community.


  • It's the people/social setting that makes a conference really great.
  • A wider range of opportunities at the conference is important (to a point).
  • Organizing conferences is hard — thanks to ORA & Ruby Central for their work on OSCon, RubyConf, and RailsConf.


  • Publishers can be leading or lagging indicators in a community.
  • Communities ned to communicate with publishers to drive the creation of the content we want/need.


  • I have to try harder with my own LOTY (Language Of The Year) — I want to hit Javascript, C, Haskell, and Smalltalk over the next several years.
  • I know more about Ruby than I thought I did, but less about Ruby than I want to.
  • More people read this blog than I though — I need to write more worthwhile stuff and less drivel.

An Early Announcement

Just a quick post to keep myself honest. I've heard that telling people about a goal you've set, and committing to keep them up to date is one of the best ways to keep yourself on target for that goal. I've tried it with some other things, and it's seemed to help. So without further ado, my announcement.

I'm going to try to lose fifteen pounds — oops, wrong goal. I'm writing a book. I've signed a contract with the Pragmatic Programmers and have just started writing. I'm not ready to start tossing around titles or topics yet, other than that it's about Ruby. Let me get a bigger chunk written, then I'll be able to tell you more.

I'm hoping to write about 50 pages each month, and will drop a progress report here on my blog every Friday. If I can keep to this schedule, I should be able to make a bigger announcement in the fall.

Your job, should you choose to accept it, is to gently pester me about my progress. Feel free to drop the occasional email, or to make comments here. (Oh, and if you want to bug me about the weight thing, that probably wouldn't hurt either.)

Saturday, July 29, 2006

OSCon, It's the all about the people

I loved being at OSCon and catching up with people from my past and meeting new folks. Tuesday night, I invited a bunch of folks for an impromptu dinner between the last session and the start of the evening activities. We ended up with: Andy Hunt, Andy Lester, Dave Thomas, David Black, Glenn Vandenburg, Jim Weirich, John Labovitz, Lennon Day-Reynolds, Mark Conway, Mike Clark, Pat Eyler, Phil Tomson, and Audrey Eschright. (Sadly, Avi Bryant, Ingy Dot Net, and Stas Bekman couldn't make it.) There were a lot of great conversations floating around an outdoor table at the Produce Row Cafe. Where else could you gather a group like that?

What's up with RWB?

I didn't have any luck finding a new owner for RWB, but it turned out that something even better was about to happen. There were a lot of things I'd wanted to do with RWB to make it really useful. I just didn't have the time to sit down and get them done. Since no one was interested in taking it over, I've been trying to make the decision between letting it die (not my favorite option) or finding time to get stuff done on it (not really pleasant either).

I'd basically decided to cut back on a couple of other things so that I could push RWB ahead slowly, when Zed announced RFuzz. there seemed to be a lot of overlap, so I dropped Zed a line seeing if he were interested in harvesting the good parts (ideas mostly) from RWB for use in RFuzz.

This merger turned out to align quite well with what Zed was hoping to do with RFuzz anyway, so RWB's future is set — it has none. RFuzz will be the project to use if you want to do capacity, load, or fuzz testing of web applications with Ruby.

I hope to contribute to RFuzz (even if only a little bit). Even more though, I want to see RFuzz run with the ideasI had for RWB and become the kind of web server/webproxy testing tool the community really needs. Once again, I'm left saying: "Go Zed!"

RWB is dead! Long live RFuzz!

Thursday, July 27, 2006

RubyInline: Going a bit Further

Last time around, I wrote about RubyInline and profiling, and raised a couple of questions. This time around I'm going to talk about RubyInline and benchmark in a (probably vain) attempt to answer the existing questions, while raising new ones. There were basically three questions that I'd like to handle:

  • What should we call this stuff?
  • How does it work?
  • How do I use Ruby objects in my C? (Yes, I'm conflating two questions here.)

The simple answer to the first is that yes, we're really just writing Ruby methods (albeit in C). To really understand why and how that is, we need to look at what RubyInline actually does.

RubyInline does a couple of things in the process of working (if I get any of this wrong, hopefully Eric Hodel or zenspider will jump in and correct me). The first time it's run, it copies the C source into a temporary directory (~/.ruby_inline) and tweaks it a bit to make it Ruby-aware. It then compiles the C to a shared library (a .so in my case) which is linked into the running Ruby script, and any methods are made available for calling.

If RubyInline is run again against the same script, it checks to see if the shared library is newer than the original source file and only recompiles if the source is newer than the object file. This helps cut the compile and link latency that would be introduced otherwise.

The idea of Ruby methods written in C might seem foreign, but you actually use them all the time. Array#uniq is just a bunch of C, but you'd never know it without digging around in the Ruby source (not recommended for the faint of heart). RubyInline just makes the process of writing Ruby in C a bit easier (well, a Lot easier).

Let's take a look at this in practice. Since my last post raised some questions about using Ruby objects (Fixnums and Arrays) from C, so I borrowed some code from example2.rb in the source, and worked from there. Here's the code:

#!/usr/bin/ruby -w 

require 'rubygems'
require 'inline'
require 'benchmark'

class Array

  # build the Array#average method in C using Ruby Objects
  inline do |builder|
    builder.c_raw "
      static VALUE average(int argc, VALUE *argv, VALUE self) {
        double result;
        long  i, len;
        VALUE *arr = RARRAY(self)->ptr;
        len = RARRAY(self)->len;
        for(i=0; i<len; i++) {
          result += NUM2DBL(arr[i]);
        return rb_float_new(result/(double)len);

  # build the Array#ravg method in Ruby
  def ravg
    Float(self.inject {|sum, elem| sum += elem }) / Float(self.length)


# build a good sized loop over a big array
max_loop = (ARGV.shift || 20).to_i
max_size = (ARGV.shift || 1_000_000).to_i
a = (1..max_size).to_a

# benchmark the C versus the Ruby versions
Benchmark.bmbm(10) do |x|"C")    { for i in 1..max_loop; a.average; end   }"Ruby") { for i in 1..max_loop; a.ravg;    end   }

Other than showing the use of Ruby Array objects from C, the only interesting thing is the benchmarking code (the last block in the file). Even this is pretty simple stuff though, it reads something like this:

Run the bmbm method (which runs a benchmarking rehearsal and benchmarking test), with the report headers left justified in a 10 character block. The first blob to benchmark is given the header 'C', and runs a loop averaging the big array once each time through the loop. The second blob will be labeled 'Ruby' and will benchmark the ruby average method.

The output of running this script looks like this:

$ ruby inline_array_benchmark.rb
Rehearsal ---------------------------------------------
C          27.790000   0.110000  27.900000 ( 29.643141)
Ruby      115.280000   0.280000 115.560000 (119.626154)
---------------------------------- total: 143.460000sec

                user     system      total        real
C          27.680000   0.030000  27.710000 ( 28.382200)
Ruby      116.040000   0.340000 116.380000 (120.795489)

It's interesting to note that the rehearsal takes a bit longer for the C version. It's tempting to say that's because it compiled the C code, but that's not really the cause. The compile time takes so little time, it's lost in the noise.

Hopefully this helps answer some of the questions that have come up. If not, feel free to keep asking — I'll keep trying to answer them.

Wednesday, July 26, 2006

RubyInline, Making Making Things Faster Easier

Today on ruby-talk, I caught a thread called "For Performance, Write it in C". I'd like to present a slight amendment to that thesis. Let me explain.

It all started with an email at work. Someone was passing around a bunch of prime number printers in various languages (C, Java, C#, Perl, and Python). They all used the same (ugly) algorithm, and were supposed to show just how 'performant the languages were. Since I'm the local Ruby evangelist, I was asked to write a Ruby version. Here's what I came up with (warning, ugly algorithm ahead):


for num in 1..10_000 do
  is_prime = 1
  for x in 2..(num - 1) do
    if (num % x == 0) 
      is_prime = x
  if is_prime == 1
    puts "#{num} is a prime number"
    puts "#{num} equals #{is_prime} * #{num/is_prime}"

How fast is it? Well, time says:

$ time ./primes.rb > /dev/null

real    0m2.905s
user    0m2.716s
sys     0m0.004s

Certainly, nothing to write home about, but not too far from Perl or Python either.

Wanting to improve it, and not being able to touch the algorithm (we want to be comparing apples to quinces after all, not apples to oranges). I know my only hope is to find the bottleneck(s) and rewrite it (them?) in C. My first step is to grab Ruby's profiler and see what it says (oh, by the way, I reduced the value of num to 100 so that this would complete in my lifetime ... the profiler is slow).

$ ruby -rprofile primes.rb > /dev/null
  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 63.64     0.14      0.14      101     1.39     3.56  Range#each
 13.64     0.17      0.03     1133     0.03     0.03  Fixnum#%
  9.09     0.19      0.02     1233     0.02     0.02  Fixnum#==
  4.55     0.20      0.01      100     0.10     0.20  Kernel.puts
  4.55     0.21      0.01      200     0.05     0.05  IO#write
  4.55     0.22      0.01      248     0.04     0.04  Fixnum#to_s
  0.00     0.22      0.00       74     0.00     0.00  Fixnum#/
  0.00     0.22      0.00      100     0.00     0.00  Fixnum#-
  0.00     0.22      0.00        1     0.00   220.00  #toplevel

Which tells me that most of my time is spent in each (well, it's actually spent in the block I sent to each. It's taking a whopping 1.39 msec per call, compared to .0X msec for everything else. What would happen if I rewrote just that block?

Enter RubyInline (A great tool written by zenspider and Eric Hodel). I'm not a C wiz by any stretch of the imagination, but this stuff is pretty easy to bang out. My new code looks like this:


require "rubygems"
require "inline"

class Primes
  inline do |builder|
    builder.c '
    int prime(int num) {
      int x; 
      for (x = 2; x < (num - 1) ; x++) {
        if (num == 2) {
          return 1;
        if (num % x == 0) {
          return x;
      return 1;

p =

for num in 2..10_000 do
  is_prime =
  if is_prime == 1
    puts "#{num} is a prime number"
    puts "#{num} equals #{is_prime} * #{num/is_prime}"

Not too ugly. At least I can still see what's happening. The main loop being in Ruby helps a lot too (especially if this were a much bigger program). How much of a difference does it make? time says:

$ time ./cprimes.rb > /dev/null

real    0m0.328s
user    0m0.288s
sys     0m0.020s

An order of magnitude improvement. Not too shabby.

What's the lesson here? Optimize what you need to (and only what you need to), profile find out what that is (it may be slow, but profiling is your friend), and use the right tools (rewriting a bit of code with RubyInline is way better than rewriting the whole app in C).


I guess I should include a link to RubyInline.

Creating Passionate Users

First of all, I love Kathy Sierra's blog Creating Passionate Users. Secondly, she gave an amazing talk last night as OSCon (she even pointed out my favorite April Fools joke from last year, a parody product announcement).

She talked about Creating Passionate Users (what else?). The great irony was that in the row in front of us there was a guy I recognized from the Ruby Guidebook session yesterday. He had his laptop out on his lap, and was reading a PDF of AWDwR and working through examples during her talk. Anyone skipping Kathy to read a book and hack on Rails is developing some serious passion!

Tuesday, July 25, 2006

OSCon Quotes I

There have been some great quotes on #oscon already. Two of my favorites:

  • (10:20:53) gefilte: SOAP makes me feel dirty
  • (10:41:59) jgw: yes, perl 6 is the Duke Nuke Forever of programming languages
It looks like a tumbleblog would be a great way to post from OSCon.

So far, all the sessions have been tutorials. I'm not going to post a lot notes from any of them, but I'll try to post some overviews tonight or tomorrow morning.

RubyConf Talks Announced, What to Do With Too Many Talks

Ruby Central has announced the speakers for this years RubyConf, and it looks like a great lineup. I'm especially looking forward to hearing from Zed Shaw and Evan Phoenix — assuming I'm one of the lucky 200 or so to beat the rush and get registered. The only sad part is that I know Chad and David had to turn away a lot of great talks. There just isn't room for all of them in a conference of this size.

This brings me back to my earlier point that we need to have more regional ruby gatherings. I've not been alone in talking about this. In fact, Ruby Central also announced a regional conference grant program (pdf) yesterday.

The program will grant up to $1500 for a regional Ruby themed conference (for use in subsidizing speakers travel, renting space and AV equipment, and the like — there are some rules and restrictions, go read the announcement linked above for the full scoop). There will be several grants made this year, hopefully the program will run well enough to see it continued into the foreseeable future.

So, what does this mean? Well, it provides a lot more outlets for Ruby Speakers to go and spread the news. It also means that local Ruby Brigades (or regional groups of Ruby Brigades) should start thinking about hosting a program. I'd love to see the slc.rb, utahvalley.rb, and BYU RUG work with Rubyists in Utah, Colorado, Idaho, and Wyoming to pull something together in the Spring. There are a bunch of New England area Ruby Brigades, I'll bet that they could pull of a great conference. The Pacific Northwest is home to at least four groups full of prominent and interesting Rubyists, if they put together a regional conference it will be worth travelling to.

Get out there and start coordinating!

Friday, July 21, 2006

Ruby Lightning Articles — what a great idea

I'm always amazed at the things I find over at (Christian Neukirchen's tumbleblog). Recently was a link to an O'Reilly article called Still More Perl Lightning Articles, with the comment " O’Reilly should publish Ruby Lightning Articles too. ;-)".

Not being one to eschew something just because it has its roots in the Perl world, I followed the link then dug a bit deeper. Each bigger article (anthology?) is a collection of short (500-1500 or so) word articles about some neat tool, method, or what-not in Perl. They're up to three of them so far (though the articles are spread over the last three years). At first it seemed like an interesting idea, then I started having second thoughts.

The more I looked at it, the more it looked like a collection of blog posts. I'd much rather see the O'Reilly Ruby Blog keep running lots of shorter posts and articles independently. Maybe a better way to go would be something like this:

O'Reilly (or someone) should put together a small bounty for short, informative, well-written articles (say $50 each). They could also maintain a list of article requests that could be used by prospective authors. As articles are recieved, they could be vetted by the existing O'Reilly Ruby Bloggers then posted.

In the end, it would be a win-win-win situation. A few people would end up with a couple of extra bucks, O'Reilly (or whoever) would get a collection of new content for their site, and the Ruby community would have more documentation available. Such a deal.

The big question is, "What should be on the list of article requests?" What do you think?

Publishing: The Four Kinds Revisited

I've had the opportunity over the last couple of weeks to trade emails with the CEO of a boutique publisher. This discussion has helped me sharpen my view of the technical publishing market in general, and of boutique publishers specifically. (As always, you can go back and see my original post on classifications here.)

During the course of our conversation, he challenged me about my definition of his company as a boutique publisher. After reading his comments I had to refine my thinking a bit. I came up with a more structured approach to my division of publishers. If you were to draw a graph measuring where a publisher fell along two axes (Community and Production), the resulting four quadrants would each hold one of my classes ('Big-Box', 'Mom & Pop', 'Boutique', and 'Farmers Market').

A discussion with another friend raised some questions about what these axes mean, and how they fit together. Here are my explanations (complete with over-simplifications and over-generalizations — it's a two-fer-one sale):

  • The Community axis:
    • Provider: These publishers don't see themselves as members of the community, but as a vendor that caters to the community's needs. At it's best this creates a strong drive for customer satisfaction — at its worst, it breeds a "father knows best" attitude that turns off the community. Providers can do some wonderful things like sponsoring conferences and user groups, providing infrastructure, and the like. The benefits only come when the community is seen as a viable market though.
    • Partner: As members of the community, these publishers see themselves as participants in the ongoing conversation that shapes the community. Being a partner limits the size of the publisher as they can only be engaged in a small set of communities before they're spread too thin to be effective. Partners give back to the community not based on the marketing bottom line, but based on their relationship.
  • The Production Focus axis:
    • Commodity: Publishers with a Commodity Production focus look will look at books, authors, editors, and buyers as part of an established process. They push for their process to create the 'best' books. When it works, you end up with books of consistent quality being produced in a timely and predictable fashion. Then the process doesn't work, it's like Procruste's bed.
    • Craftsman: Following the Craftsman Production focus means that the publisher is focusing on getting each book right according to the needs of the book itself. Books tend to be produced more slowly, and to be more unique. At it's best, you get masterpieces like Tufte's work. At it's worst, you get the published equivalent of a Jr Highschool Shop project.

How does it work then? Let's look at a "Mom & Pop" publisher. They're in the Commodity Production and Community Partner quadrant. I'd expect that this kind of publisher would be talking to community members to find out what books to work on and to look for writers, not working with graphic designers to figure out the best or most cutting edge look for their books. I'd expect them to be looking at the bottom line, and publishing books that enough of the community wants to be profitable. With the concern about community comes contribution to that community, but it is measured against its impact on sales and profit.

How does this model affect my thoughts on publishing? It lets me see how a publisher might slide from one classification to another. I can use it to see where I think a publisher sits, and how they might want to interact with there community (or communities) if they want to stay there. If a publisher want to change the way they do business, this model can help identify what changes to make to get them moving in the right direction.

What do you think, am I full of hot air? Can you use this model to place your favorite publisher? How well do they fit?

This post is part of a collection of articles about Publishing, Growing Markets, and Books.

Thursday, July 20, 2006

Ruby and Rails in more and more places

I just got a draft manuscript of Edmond Woychowsky's "AJAX: Creating Web Pages with Asynchronous JavaScript and XML". I haven't really paid any attention to it yet (too much other stuff on my plate), but I was intrigued to see: "Includes extensive code examples and primers on key Ajax technologies, from Javascript and XMLHTTP to Ruby on Rails" (emphasis mine) on the front cover.

Looking further, this amounts to two chapters (nearly 30 pages) on Rails and Ruby. Admittedly, this is not much space (and Edmond could have polished his Ruby up a fair amount) but it is a nice mention, and takes up over 10% of the book.

What's next? A ruby introduction in an Introduction to Linux book? Oh, wait, that's a rant for another post.

More information about this upcoming book is available from its: Prentice Hall homepage. You can also pre-order a copy here (

Monday, July 10, 2006

JRuby Interview Leftovers — A More Agile API

Since articles on the O'Reilly Ruby Blog are supposed to fit in a certain length, there are always a couple of choice bits that need to be trimmed. I'm finishing up an interview with Charles Nutter and Thomas Enebo, the developers of JRuby, and have a couple of pieces to post here. Enjoy!

I'm not sure I understand why C Ruby having C extensions limits its ability to make "sweeping architecture changes". Is this because the API must be kept stable, or is there some other reason? Does JRuby not have Java extensions that present the same kinds of problems?

Charles: Ruby's C extensions have access to the full set of internal Ruby APIs; this means they are heavily dependent on Ruby's internal data structures, object creation mechanisms, call semantics, and so on. As a result, C extensions require that those APIs, structures, and semantics all work the same from version to version. To change them would break many extensions.

In JRuby, we have a number of libraries implemented in Java, but there are few if any third-party JRuby extensions, owing mainly to JRuby's relative youth (and our repeated discouragement from creating extensions that depend on internal APIs). We plan to support an extension mechanism (Java-based, of course), but it will be far removed from the inner workings of JRuby itself.

C Ruby is essentially an open book, where extenders can call any internal APIs or manipulate internal data structures to achieve their ends. This makes those extensions very powerful and flexible, but requires that Ruby internals be frozen.

Friday, July 07, 2006

JRuby Interview Leftovers — Ruby Books

Since articles on the O'Reilly Ruby Blog are supposed to fit in a certain length, there are always a couple of choice bits that need to be trimmed. I'm finishing up an interview with Charles Nutter and Thomas Enebo, the developers of JRuby, and have a couple of pieces to post here. Enjoy!

Thomas mentioned that after seeing a Perl script ported to Ruby he was intrigued enough to go out and buy the Pragmatic Programmers' Pickaxe book. That got me thinking.

I wonder how many people come into Ruby through Dave's book. What other books would you guys recommend to someone who's just getting into Ruby?

Charles: I actually haven't had time to read many others. I've just started working through Agile Web Development with Rails, and it's very good. Tom and I also offered comments and suggestions to Bruce Tate for his From Java to Ruby book, but I haven't had a chance to read it yet.

Thomas: I have not read any Ruby book other than Agile Web Development with Rails. A good and well-written book. Probably not a book for learning Ruby though. I bought both editions of Pickaxe and have never found a need to buy another Ruby book.

Wednesday, July 05, 2006

A Tale of Two Books

I'm finally getting around to pulling my thoughts on publishing back toward Ruby. I've got a pair of short case studies about publishers dealing with Ruby books that I'd like to share with you. I think it helps clarify some of the differences that I see between the kinds of publishers I've been describing.

The following is a true story, names have been changed or withheld to protect the participants.

My friend, Tom, and I have been approached by two different publishers to look at or work on books. In both cases, the publishers knew that the books were flawed, but thought that they were recoverable (given enough work).

The first publisher is a Mom & Pop Publisher. They came to us and were pretty up front about their concerns, they asked us to read the existing draft and get back to them. Both Tom and I encouraged them to either drop or rewrite the book, there were too many problems to overcome (it was unfocused, repetitive, and got any number of facts wrong). I don't know that publisher number one has followed our advice, but it seems like they might have.

The second publisher was a Big-Box Publisher, they approached me to become the technical editor on the book. I knew I wouldn't have time to do a good job at it, so I recommended they talk to Tom. He took on the job, and began to see problems very quickly. The author was getting basic stuff wrong. The further Tom got, the more concerned he was but on raising his concerns to the editors at publisher number two, he found them more interested in finishing the book quickly than addressing the deep flaws (or killing the book).

Now, I'm not trying to say that Tom and I have all the right answers, but I think these two scenarios illustrate the difference between the Big-Box and Mom & Pop publishers. The big guys think of themselves as providers to the community, they know better. The Mom & Pops recognize that they need to listen to the community, especially when the community is complaining.

I hope both these publishers succeed in getting into the Ruby community, but I hope that it's not on the backs of these two books. I think these books would hurt them much more than being in the community will help them.

This post is part of a collection of articles about Publishing, Growing Markets, and Books.


I mentioned that RubyConf Michigan has been announced in my weekly blog post over on Linux Journal, but it's worth talking about again. It's being held on Saturday, August 26th, and will feature a number of local speakers as well as David A. Black and I.

Sadly, this conflicts with the upcoming BarCamp Utah. I wish there were a way I could do both, but short of cloning I don't see how it can happen. I hope the local BarCamp goes well, and that we get a solid Ruby presence there.

Another announcement of note was that the JRuby team has released a shiny new JRuby 0.9.0. According to the announcement, this one will run untweaked Rails an RubyGems 0.9.0. Great work guys!

Monday, July 03, 2006

Cross Langauge Cage Cleaners for Cardinal and Parrot

Andy Lester is one of those Perl hackers I admire and keep an eye on (you just never know when a great idea is going to come careening our of him). He and I have crossed paths a number of times because of our shared interest in libraries (the book lending kind) and library software. Even though we hang out in different language camps these days, I flatter myself to think of us as friends.

Yesterday, he posted an article about his new project — cleaning the cage for the parrot project (Andy always seems to come up with great metaphors for his projects). He's looking for people to join him, you don't need to be a Perl 6 or a Parrot wizard. All you really need are some basics:

  • know how to build software packages
  • basic software testing skills
  • an eye for detail (especially on the corners
  • an ability to read code

The idea is to build Parrot on a variety of systems, enforce coding standards, ensure code coverage, create tools to help with these, and to work on documentation.

Parrot's a Perl project, so you're probably wondering 'How does this fit into Ruby?'. Well, I think there are two ways: first, the Cardinal Project (and Kevin Tew's Ruby on Parrot project) both rely on Parrot, so this will help both of them; second, Ruby's starting to heat up on a number of VM fronts (NekoVM, HLVM, JVM, .NET, and maybe more) so the experience and ideas that come out of the Parrot Cage Cleaners should be both transferrable and useful for other VMs as well.

I think I'll go check out Andy's new project — even if it's just as an observer. I hope others in the Ruby and Ruby on (name your favorite VM(s) here) communities will too. Hopefully Perl and Ruby will both benefit.

Update: Andy sent me an email to say: I didn't even come up with a name for the project: Chip Salzenberg just mentioned it as a joke and I said "That's absolutely perfect!" It's . . . a testament to the power of getting people together in one place..."