10 Cool Things From RubyConf X

This last week was the fantastic RubyConf X. It has been ten years of RubyConf and in celebration of this notable occasion, the organizers located it in New Orleans and opened up the registration to a lot more people then most years past. This had the clearly foreseeable consequence of turning the conference into a really fun time!

So here, in no particular order, are 10 cool things I saw or heard at the conference.

1. Rite

During Matz's keynote he introduced "Rite" which is a embedded version of Ruby designed to run on devices such as digital TVs, and other neat small gadgets. It will have a different implementation that the CRuby implementation, optimized for the smaller lower powered profile of the next generation gadgets. The project is sponsored by the Japanese government and is already being used in development by a major game company that could not be named but is will known. My palms started sweating the minute I heard about it, and I am already getting excited about the prospect of flying_robot 2.0 based on Rite.

2. Evergreen w/CoffeeScript

CJ Kihlbom and Jonas Nicklas gave an excellent overview of client-side UI testing. They also demoed their own highly useful Evergreen testing framework which works together with Ruby and Jasmine looks like a very succinct and useful approach toward browser testing. Writing specs in CoffeeScript looks very tasty.

3. Gentlemanly Git Tricks

Scott Chacon's talks on git always leave me feeling knowing both more than I did, and less then I thought I did, at the same time. This session also had a hilarious and yet useful section on 'how to be a gentleman' including tips on whiskey, how to dress, how to tip, and how to treat a lady. Keeping it classy, Scott!

4. "F-Bombs, Zeds, _whys and a Missing Brain Area"

The keynote speeches from Dave Thomas, David Heinemeier Hansson and Matz could not have been more different on the surface, and yet had a similar theme: defy the limitations of the status quo, and seek out new ideas that are actually better. Dave's admonishment of the community to get over our gender bias, David's F-bombs, weed photos, and cry of "Freedom!", and Matz's love of diversity from _why to Zed, and adopting of David's amusing yet appropriate term "freedom-patching" in lieu of the less pleasant-sounding "monkeypatching" were all different ways of showing our desire as a community to seek out these truths. As long as we keep talking to each other, and also listening with an open mind.

5. Ruby 1.9.2 is Ready

Several people have been saying it, I am been using it from some testing, and Jim Wierich said it in the 'hallway track': Ruby 1.9.2 is ready for prime-time. If you are not transitioning your apps to 1.9.2 you should be. Performance, and cool tools like minitest are just two reasons to do it today.

6. Beyond The Code

Paul Campbell, Joe O'Brian, Keavy McMinn, Jon Dahl, Tom Preston-Werner and several other interesting developers spoke about more than just programming. Hacking business, art, music, and code, are all just aspects of hacking. RubyConf is a great place to find out not just about Ruby code, but the motivations and inspiration behind people we respect, and look to to improve ourselves.

7. Lightning Talks

The number of people that are eager to signup for a lightning talk was huge at RubyConf, as always greatly exceeding the available time. Even trimming down each to 4 minutes, there was only time to get thru relatively few, and I was lucky to get to speak about the Ticketmaster gem.

8. Kid Programmer Mini-Conf

Sarah Allen, Sarah Mei, Jim Meyer (who sadly could not make the conference at the last minute), Liah Hansen put together a parallel kids programming track, for the first time ever at RubyConf. The idea was brilliant, and I hope to bring my own son next year to participate.

UPDATE: Sarah Mei informs me that Maxwell Salzberg is also an organizer of the kids track. My bad!

9. Hallway Track

As always, the conversations at RubyConf are amazing. The people who attend are doing amazing things, and the change to hang out for a few days talking is a fantastic chance to learn and find out incredibly useful and interesting things. You have to actually attend RubyConf to experience this, you just cannot get it by watching the videos.

10. Music

From the live music in New Orleans, to the DJs, it is really great to have been in a city where music is something living, vibrant, and cherished. Getting to do my music/brain hacking talk on "How To Jam In Code" was just the icing on the cake for me in the city of Jazz. Getting to create a bio-computer made of living people is a special privilege, thank you very much to everyone who participated.

But most of all, thank you very much to Kelly Fowler, Chad Fowler, Rich Kilmer, and David Black for doing so very much for all of us. It is a lot of hard work, and we all appreciate it!

RubyConf X was a tremendous affirmation of the strength and depth of sharing within the Ruby community. I look forward to seeing what the next ten years have in store for us.

Flying Robot: World Tour 2009 Continues

As usual, no blog posts = a lot of other activity here at Flying Robot HQ. Among other personal stuff, my brother Damen Evans and I have been getting ready for the last public demos of @flyingrobot for 2009. And we are going out with style!

Later this week, we roll up to San Francisco to present at the prestigious RubyConf! Then, next week @flyingrobot and I will fly off to Madrid, Spain, to do our first European appearance at the awesome-looking Conferencia Rails.

Anyhow, if you have been waiting eagerly for more Flying Robot news and gadgets, be patient. We will be unveiling our mysterious cool new stuff in just a few days...

RubyConf 2008 - Rubinius - Evan Phoenix

The Ruby VM wonkiness continued at RubyConf 2008 - Day 1. Next up we heard the "State of Rubinius" address on the status of the anointed heir to the Ruby federation. Evan Phoenix is a fun guy, and it proved to be a both informative and enjoyable session.

Evan says Rubinius is "meta-circular-ish", and slow, but getting faster. They have a new VM that is written in C++, which is a sharp tool, and as such, it is possible to poke your eye out. However, he says it allows them to better model work. The three main advantages are:

- type safety
- organization
- architecture

What is type safety, may ask many Rubyists. Well, sometimes a duck actually IS a duck. The Rubinius code just feels better with OO nature of C++, as opposed to just plain C. Also, it is possible to make the VM class hierarchy that mirrors the Ruby class hierarchy.

Exporting Methods - a day in the life of a primitive operation

- things you cannot do in Ruby
- small example

class String : Object {
  Fixnum* size();
}

class String
  def size
    Ruby.primitive :string_size
  end
end

There was interesting question about why flatten out ala :string_size aka no namespacing. Evan did not seem to give a definitive answer...

Method Dispatch - From resolution to execution

Resolution
- going from receiver and method name to actual method
- three mechanisms
- hierarchical lookup
- global cache
- inline cache

Execution
- every method provide an execute function pointer
- each primitive is an executor
- Ruby methods use executor specialization

Ruby Methods
- Specialized executors based on argument info
- Very simple fast version for majority of cases
- Slower fallback case for all cases

Critical Path
- Populate message object
- Call rep over trampoline
- Fill in more of message object
- Call method executor

Execution/Framing
- Method context objects store info about each method
- Chained together using refs (spaghetti stack)
- MethodContext creation speed is crucial

- Default contexts are allocated in special section of memory
- Normal execution follows simple stack pattern
- We can exploit to allow for fast creation and deallocation

Calling to C
Can you imaging life without ruby gems that use C extensions? For example:
- hpricot
- mongrel
- mysql
- sqlite
Not a problem. A simple recompile == usable in Rubinius

Tricky
- GC interaction requires indirection
- Uses 'quantum leap" stack jumping
- Allows for semi-graceful recovery from extension segfaults

Performance
Rubinius is doing well on micro-benchmarks
- method dispatch
- GC
- OK on macro-benchmarks
- Poorly on mega-benchmarks

Solutions
- LLVM
- JIT
- AOT
- Improve algorithmic efficiency

Rubinius is concentrating on compatibility right now, but will then address performance. Just like Koichi-san said, it is a curve of improvements.

Evan ended up with a nice quote from Woody Allen - "If you're not failing every now and again, it's a sign you're not doing anything very innovative."

Going To RubyConf 2008

Yes, it has been quite a while since I last posted. I have been busy with several interesting code things I will be talking about soon, along with my family's annual trip to Spain (lots of good times, but no posting about that).

Busy, yes. but not TOO busy to make my plans to go to RubyConf 2008. November in Florida, I can just imagine it now... hard core Ruby coding, jam sessions in the hotel, and maybe even some post-election riots. Plus roller disco. Damn, I'm there!

And if you want to be there, better get it together and register now.

Werewolf vs. Vampyre

I had read with mild amusement the minor dustup over the craze of Werewolf players at RubyConf 2007. If you don't know what it is, you can read about it here.

Some people just really enjoy playing social games. Let's call them the Werewolves... you know who you are, even if the rest of us do not.

Other people, however, view RubyConf as a place to get together with the other commiters on their beloved project, stay up all night, and crank out a new release before their presentation the next day. Let's call these people the Vampyres... subsisting on mysterious red liquids, and notable for the pallor of their skin.

So what is the problem? Can't we all just get along? Not really, cause these two sub-species have very different priorities and modus operandi. Werewolves come out in droves when the time is right (full moon). They operate as a pack, sniffing out things and then chasing after them collectively.

The Vampyre is by nature a bit more cliquish. You simply cannot have a pack of wild creatures committing patches without *some* kind of arcane ritual involved. You can call it merging branches if you want. There is usually a coven of Vampyres, with a charismatic leader surrounded by younger creatures.

I go to a conference to hang out, drink a few beers, and then go to bed to rest from the inevitable time zone changes. If I want to get into a big social hoopla, I just go to soccer practice. On the other hand, if I want to stay up all night programming in a group, I can certainly go do that whenever I want. Personally, I do not find group programming at all efficient, but if someone else does, go for it.

I feel like a covert human thinking he is hidden among these undead creatures. If the Werewolves and Vampyres want to get together in order to get down, by all means they should. Just don't get stuck in the middle!

RubyConf 2007 - Day 3

As day 3 of RubyConf 2007 began, the breakfast buffet had to remind us of its presence. This time, it was the main sound system that was taken out by the ultra-powerful toasters. When Dr. Nic was asked if he wanted to get started anyhow, he had to give two of his charmingly nasal "No" rhymes with "Pow" before MC David Black caught his meaning. This gave some of us a moment to try to catch up on the flurry of RubyConf blogging. Not that you could tell that from the extreme lateness of this post. But enough of my feeble excuses.

Finally, Dr. Nic took the stage, and gave an entertaining if kitschy presentation of his new RubiGen generator to make generators. The whole "A-team" gimmick was over the top enough that Dr. Nic himself admitted by the end how he looked forward to retiring it. All I can say is "curse you for planting that theme song in my head for over an hour". On a better note (ouch!) this is for sure some useful stuff, and I will no doubt be doing some "generatin'" of my own coming up soon.

Next up was "Behavior Driven Development in Ruby with RSpec". Although the presentation was not as flashy as the first, it was full of great information presented by smart guys who really know their stuff. I did not know Dave Astels, and although I have spent some time hanging out with David Chelimsky, I don't know him half as well as I would like to. Watching their live demo of ping-pong programming on stage made me wish that I had someone really, really good to pair with these days. It looked fun!

For a former Fitnesse junkie like myself, the syntactical sugar applied to testing of requirements that is Behavior Driven Development using RSpec is really appealing. I really don't know why some really smart people like Chad Fowler and Ryan Davis are not into it. I suppose that I have spent a lot of time with trying to sync up a customer's need with some custom software that was being written, and so the merger of domain specific languages and executable specifications is just particularly compelling.

The last of the three main sessions was Jay Phillips presenting "Adhearsion - Sane VoIP Development". Way back when, I did some telephony stuff on ancient evil AT&T System V boxes, so I have followed from afar the wild and craziness of VoIP with the jaundiced eye of one who has gone there before, and came back having lost half of the party. Poor Vonage... ahem. That said, the Adhearsion project taking a Rails-like approach to the stinking morass that is anything related to telephony is rather ingenious. I think much of the crowd will never use any of this stuff, but it was really neat. I wish Jay luck in his quest!

After the main presentations, I decided to keep close to the cutting edge, and see what the Google Summer of Code hath wrought. Amusingly, I must not have been the only one to lack major interest in the other sessions, cause the Goog room was full up on the "everyone who is anyone in Ruby" crowd. Can you say "time to catch up on feeds"?

Of the Google SOC projects, I cannot remember much. I was most impressed by one student's charming honesty. It would seem that the project hadn't really gone all that well, and the work produced didn't seem like anything usable. But he had learned quite a lot. I think we often forget the value in so-called "failure", cause we of course only extol the virtues of success. But Edison's remarks on failure are instructive, and I took from this kid that he was going to be a lot more ready for real-life programming challenges as a result of his experience. I was a lot more impressed by that than some well-crafted but uninteresting code library that I will probably never use.

The last session of the day for me was Aaron Bedra's extremely cool "Sploitin' With Ruby". It you do not know about Metasploit, it is a security research nee hacking tool, that is written almost entirely in Ruby. Taking an open-source, very plugin-oriented approach allows security professionals and outgunned system administrators to try to keep up with the R & D budgets of black hats, who these days have major economic incentives to hack your systems. Anyone who knows anything about security knows that these is no such thing as a secure operating system. That said, it was pitiful how easily you could probe for these exploits using Metasploit, without even knowing a fraction of what would be required before the invention of such tools.

I just hope a bunch of the people who were making dumb comments in the room understand that breaking into your own computers to test them is smart, and a great way to harden your defenses against various nasty people. Breaking into OTHER people's computers is a recipe for a stay in federal prison.

After the fun and games, I had to join the throng of taxi-seekers and head for the airport. RubyConf 2007 had been great, but now it was time to get back to the enormous piles of work that had only grown in my absence. RubyConf is a fantastic fun time, and a real inspiration to many of us. I will most certainly be back again next year, assuming that my finger is quick enough on the mouse to grab a seat.

RubyConf 2007 - Day 2 - "The Ruby VM Smackdown Begins"

As the sun rose over the hills of North Carolina, the quiet betrayed a seething fire blazing in the hearts of three development teams. "Three teams enter, one team leaves!" Yes, I am talking about the main event, people, the one, the only, Ruby VM Smackdown! The room was jam packed, the anticipation was high.

As good fortune would have it, I was sitting right next to the head of the team who was my personal favorite to win the day. Yes, I am referring to Evan Phoenix, leader of Team Rubinius along with co-conspirator Ryan Davis. You should have seen the look at their faces when the JRuby team showed the Rubinius RSpec test suite as part of their demo! But I am getting ahead of myself...

I like the underdog in a fight, when the underdog is tough, and under-estimated by their opponents. On one side, the resources of Microsoft, on the other, the full power of Sun. And then, THE LADS. If you don't want to see that one go down, you have no passion for the cutting edge of innovation. And if you do not know about the history of innovation in the software industry, you might miscalculate the odds. Gentlemen, to your corners... I want a clean fight!

MC Chad Fowler got up, and gave a brief intro to the show. "We are about to see what Matz called 'wonderous' last night," he said. And it was true.

First up, was John Lam of Microsoft with IronRuby armed with "State of IronRuby".

Next, Charles Nutter and Thomas Enebo of Sun with JRuby using "Ruby for the JVM" style.

Last, the challenger, Evan Phoenix with Rubinius wielding "Rubinius 1.0".

Wow. Bread and circuses, indeed!

I will be posting individually about each of the Ruby VM contestants, and will update the above links when I am done...

After all that excitement, the crowd was starved. We shuffled out to eat our lunches, and converse on all we had seen. From everyone I spoke with, the mood in the crowd was firmly in the Rubinius corner, with a close second to JRuby, with third place probably going to YARV. Hardly anyone I spoke with at RubyConf had any interest in using IronRuby at all!

That is to be expected from a conference like RubyConf, well known for its strong ABM (Anything But Microsoft) attitude, which is pretty unfair. That said, I think the uptake in the .NET community will be the measure of the success of IronRuby, not whether they can get the typical RubyConf attendee to switch back to Windows.

In the afternoon, I got to see some great sessions, from:

"Refactotum: Ruby" - Stuart Halloway
"Maximizing Productivity" - Eric Hodel
"Mac OS X Loves Ruby" - Laurent Sansonetti

I will be posting individually for each session when I get a chance, and will update the links here.

Once the afternoon's sessions had wrapped up, a large group of us overran a local BBQ joint named Mac's, with tasty BBQ, a great beer selection, and a bunch of Harleys in the parking lot. Despite our somewhat atypical appearance (nerd chic) for NC, we were welcomed warmly by the locals. There must've been 30+ people from RubyConf there, it was great!

We then returned at the perfect moment to hear Matz's keynote speech. And it was good. Really good. Matz is charming, and quite funny. His wit was so much better able to emerge in a forum where he was simply presenting, rather than the somewhat less successful "town hall" format that had been attempted the evening before. I have a separate posting with his remarks which will be up later:

RubyConf 2007 - Keynote by Matz

Once the keynote had ended, I just had to go up and shake the man's hand. I know it may be corny, but I really did suddenly appreciate what he really does, which is to inspire the community. People keep looking to Matz for all the answers, but the answers are up to us, my friends. No superheros, remember?

Afterwards, I want to the legendary RejectConf, held right next door. Don't ask me how I wedged my way in, but I did it. To everyone who's toes I stepped on: sorry! There was a fun series of lightning talk (5-10 min) presentations of pretty much brand-new stuff. The beauty of RejectConf is its appeal to the ADD'd-out techno-junkie: every few minutes something else. I will be posting a rundown of RejectConf when I get a chance here:

RubyConf 2007 - RejectConf

RejectConf was really a great highlight of RubyConf. Once they kicked us out, the entire crowd immediately migrated directly next door to the hotel bar where we drank beers and chatted loudly about techno-babble to our great enjoyment. I staggered up to my room, to rest up and prepare myself for Day 3.

RubyConf 2007 - Day 1 - "Advanced Ruby Class Design" - Jim Weirich

Jim Weirich is a very smart guy. So smart that his presentation was not about complicated classes, but about Ruby itself and how to take advantage of it to simplify things. Jim's background in computing is long and varied, something like a history lesson in programming languages. Here is the abbreviated list:

FORTRAN > C > Modula 2 > C++ > Eiffel > Java
and in parallel to this:
LISP > FORTH > TCL > Perl

Jim got started programming taking an introduction to FORTRAN class that just so happenened to be taught by Daniel Friedman, author of "The Little LISPer". As such, they studied LISP for the first half of the semester. They did finally get around to FORTRAN, where Jim learned firsthand the adage:

"A real programmer can write FORTRAN (Java) in any language"

Jim took us thru three examples that illustrate some very cool techniques to use as part of elegant class design in Ruby.

Box 1. Rake::FileList
Everyone knows and loves Rake, right? Rake::FileList is like an array but:
- can init with GLOB (an array of filenames, created using a pattern match expression)
- has a specialized to_s
- has extra methods
- uses lazy evaluation

In his first cut, Jim derived from Array:

class FileList > Array
 ...
end

Here is the first implementation for FileList:

class FileList > Array
 def initialize(pattern)
  super
  @pattern = pattern
  @resolve = false
 end

 def resolve
  self.clear
  Dir[@pattern].each do |file|
   ...
  end
 end
end

The problem is this:

f1 = FileList.new("*.c")

won't work, cause we never call "resolve". What we need to do is to do some lazy loading to "auto resolve", like this:

def [](index)
 resolve if ! @resolve
end

Lots of methods need to call resolve in this manner... which is a problem that Jim solves later using a little metaprogramming.

But there is a another problem with the current implementation. This is OK:

f1 = FileList.new('*.rb')
f1 + ['thing.rb']

But this is NOT:

f1 = FileList.new('*.rb')
['thing.rb'] + f1

Why? Because the + method requires passing a literal array to it as an argument, not an object of class Array. If only there was a way for an arbitrary object could indicate that it wants to be treated like an array... ah, but there is! The "to_ary" method was designed to do exactly this. The problem is you cannot call the to_ary method on an Array. The solution is not to derive the FileList class from Array, but instead to use the "to_ary" method to access an Array that is encapsulated into the FileList class.

Another shortcut is instead of calling resolve on each method, using some metaprogramming to add the "resolve" call to every method that might need it, like this:

RESOLVING_METHODS = [:this, :that]
RESOLVING_METHODS.each do |method|
 ...
end

The big lesson here is when trying to mimic a class, use "to_ary" and "to_str" rather than inheritance.

Box 2 - The Art of Doing Nothing
Builder is a very cool library which is part of the standard Ruby library to create XMl files, but using a friendly Ruby syntax. Did I mention that Jim is the original creator of Builder? Here is an example of Builder in use, if you are not familiar with it:

xml = Builder::XmlMarkup.new(:indent =>2)
xml.student {
 xml.name("Jim")
 xmp.phone_number
}

Builder uses method_missing to construct tags. This works really well... except what happens if you try to use it with a predefined method? method_missing will not work anymore, since the method is actually there.

Jim solution is to "inherit from Object without actually inheriting from Object", a class he calls BlankSlate. We want to have our Builder class inherit from BlankSlate, instead of Object.

class BlankSlate
 instance_methods.each do |method|
  undef_method(method)
 end
end

That does indeed get rid of all of the methods on the class. But that does not work, because there are some internal methods that Ruby needs that we do not want to get rid of, so we extend the class to this:

class BlankSlate
 instance_methods.each do |method|
  undef_method(method) unless name =~ /~__/
 end
end

This is not the only problem, however. Since in Ruby classes are open, we can also extend them using Modules.

require 'blank_slate'

module Kernel
 def name
  "hi"
 end
end

xml.name("Jim")

class BlankSlate
 def self.hide(method)
  ...
 end
 
 instance_methods.each do |method|
  undef_method(method) unless method =~ /^__/
 end
end


module Kernel
 class << self
  alias_method :original_method_added, :method_added
  
  def method_added(name)
   result = original_method_added(name)
   BlankSlate.hide(name) if self == Kernel
   result
  end
 end
end

We will need to do something similar for Object, in order to avoid the same problem. So are we done? Not quite, there is still one more thing... but I didn'y quite catch what it was! I will update this when Jim puts his slides up:

require 'blank_slate'

module Kernel
 def name
  "hi"
 end
end

class Object
 include Name
end
...
xml.name("Jim")

Hint: Use #append_features to modify open classes.

Box 3 - Parsing Without Parsing
ActiveRecord is a wonderful abstraction to use, but why is it that we use such a non-Ruby-like technique to select records. For example, we would use this in Rails:

User.find(:all, :conditions => ["name = ?", 'jim'])

Versus using a more standard Ruby language enumerable approach, like this:

user_list.select { |user|
 user.name == "jim"
}

Wouldn't it be nicer to do something like this:

User.select { |user|
 user.name == "Jim"
}

Jim starts out with a naive implementation, like this:

class User
 def self.select(&blk)
  find(:all).select(&blk)
 end
end

There are several problems, not the least of which is that the above code is far from efficient. A large set of results will use an enormous amount of memory.

Jim then goes on to show a properly "magic" implementation:

class User
 def self.select(&blk)
  cond = translate_block_to_sql(&blk)
  find(:all, :conditions => cond)
 end
end

How to implement the magic translate_block_to_sql method?
- write a parser yourself
- Use Parse Tree (Ambition project)
- Just execute the code in the block

As one might suspect, the answer is of course "just execute the code". In other words, create appropriate methods that are called when the block is executed to return the correct SQL conditions clause for the query. Let me warn you, dear reader, that I typed as fast as I could, but some of the code examples here are a little incomplete. As soon as Jim posts his slides online, I will revise and complete them.

class User
 def self.select(&blk)
  cond = translate_block_to_sql(&blk)
  find(:all, :conditions => cond)
 end

 def translate_block_to_sql(&blk)
  instance_eval(&blk) # this is not exactly the code, but I couldn't type fast enough!
 end
end

class MethodNode < Node
 def to_s
  ...
 end
end

OK, now what about the "==" operator?

class Node
 def ==(other)
  BinaryOpNode.new("=", self, other)
 end
end

class BinaryOpNode < Node
 def initialize(operand, left, right)
  @operand = operand
  @left = left
  @right = right
 end
 
 def to_s
  "#{@left} #{@operand} #{@right}"
 end
end

class LiternalNode < Node
 ...
end

class StringNode < Node # puts quotes around the string for SQL query
 ...
end

Do not use a case statement to differentiate between types. Instead open core classes, like this:

class Object
 def as_a_sql_node
  ...
 end
end

class String
 def as_a_sql_node
  ...
 end
end

Be careful how you name methods to avoid collisions.

Possible problems? Literals on left, because "==" is commutative. The solution is to use "coerce" method to handle numeric operators.

More possible problems?
"&&" and "||" operators cannot be overridden in Ruby cause they have short-circuit semantics in the Ruby language interpreter itself. Perhaps & and | instead? Too bad, because we have to write "special" semantics. Also "!" and "!=" cannot be overridden in Ruby

The ruby "criteria' lib already implements some of these ideas.

Conclusion
One important lesson to take away, is that programming languages really shape the way we approach problems. Learn the corners of whatever language you are using to take full advantage of it. Don't be afraid to think outside the box of past experience...

Jim was an amazing and dynamic speaker. All I can say is Joe O'Brian and the people at EdgeCase are very fortunate to have him around.