Rubinius Maximus

I got a little excited when I read of the team assembled right now working on Rubinius up at Engine Yard in San Francisco.

After following the Ruby VM coopitition for while, and then seeing the Rubinius crew in full effect at RubyConf 2007, I am more convinced than ever that we are going to see some SERIOUS code coming out of these guys.... and assembling them all in one place is the best way to do it. Props to Engine Yard for making it happen. Get the throne ready, because the inheritors of the Ruby Imperium cometh.

Hail, Rubinius!

The Eyes Have It

Software usability has really benefited from the latest and greatest digital technology for eye tracking. If you are not familiar with eye tracking, it is exactly what it sounds like: a camera watching where the user's eyes are focused, and matching that to the screen to identify what the user is REALLY looking at, for how long, and in what order.

Here is a really great summary called "Scientific Web Design: 23 Actionable Lessons from Eye-Tracking Studies" that collects information from several different studies, and packages it up into something pretty, dare I say it, usable.

It is really worth it to read the whole thing, and it is pretty short. Here are a few highlights that got my attention:

• Text attracts attention before graphics


• Fancy formatting and fonts are ignored


• Type size influences viewing behavior


• One-column formats perform better in eye-fixation than multi-column formats


• Lists hold reader attention longer


• Navigation tools work better when placed at the top of the page

There is so much more to UI than drawing a pretty picture. Applying some science to the art of user interface design can result in something truly beautiful.

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.

RubyConf 2007 - Day 1 - "What Makes Code Beautiful" - Marcel Molina

I remember Marcel Molina from the first RailsConf, when the Rails core team was introduced to the audience. What had impressed me at the time, besides his cool glasses, was the fact that Marcel comes from a literature background.

That makes his take on programming in Ruby very interesting, because he approaches it from an aesthetic perspective, not just a functional one. To Marcel, code must achieve both, for it to be considered beautiful.

What Is Beautiful?
Here are some historical definitions of beauty:
Plato - "The ability to grasp mere appearances cannot lead to adequate understanding. At its worst, the appreciation of beauty can mire us in the world of sense experience... but at its best it can lead to the understanding of goodness."
Rousseau - "I have always believed that good is none other than Beauty in action, that the one is inextricably bound up with the other and that both have a common source..."

There is something deeper than appearances that makes something beautiful.

Looking at human language, meaning is often implicit in sentences. Normally in software, using rhetorical effects is considered bad, unlike literature.

Ruby had an appeal to Marcel as a language, as a visceral response to the language itself. But why? Elegance and beauty are used to describe Ruby code, but what does that mean?

Settle On A Working Definition
Marcel goes with Thomas Aquinas for a working definition of beauty requiring three qualities:
Proportion - Economy of size & ratio of parts
Integrity - a glass hammer may look good, but it doesn't work for a hammer - to have integrity, a thing must fit its intended purpose
Clarity - something should be simple and clear. There is a big difference between sophistication and complication

Apply definition of beauty to software
Marcel provided a contrived example, a case study that created a Coercion class to "help" when parsing XML. In his example, he starts with a 25 line class with three methods and such obfuscated code that even the author admitted that he does not understand it. He then proceeds to show how it can be reduced to 12 lines of reasonably clear syntax.

To achieve beauty, we need checks and balances between each of the qualities of beauty - each is necessary, but none are sufficient themselves alone.

Does code quality relate to beauty?
Marcel cites Kent Beck's "Smalltalk - Best Practice Patterns" as a strong influence. The book is full of pearls of wisdom like "most good Smalltalk methods fit into a few lines". After reading the book, Marcel realized that it was a set of descriptions of the elements that make Smalltalk code beautiful.

How Is This Useful?
We may not be very impressed by the beauty in a case statement. But imagine programming before the 'if' statement. 'If' is way better than assembly code... there is a relativity to what makes code beautiful. Today, Ruby is considered beautiful. In the future, we may consider it as ugly as 70's assembly code based on the aesthetics available to us.

"An expert is someone who has made all the mistakes that can be made in a very narrow field" - Neils Bohr

Ruby is optimized for beauty.
- try to imagine better modes of expression
- violations of beauty rules reveal mistakes
- do enough of this and you will innovate

RubyConf 2007 - Day 1

Where RailsConf is growing to become a spectacle, RubyConf still has that special, small feeling of sharing. It is like the difference seeing a really great band perform at a small club before they get "discovered", and then seeing them again in an arena. Still the same band, but a much different experience. Being here at RubyConf 2007 brings back the joy of hacking Ruby code for its own sake, not just creating the latest and greatest social web application. Although Rails is Ruby, Ruby is not just Rails.

As I arrived for the opening address, I immediately ran into many Ruby friends, starting with Michael Hartl, author of the popular Rails book, RailsSpace. Michael had kindly saved me a seat up front and center. Wow, thanks Michael!

Despite losing our electrical power (due to the ultra-powerful toasters outside interacting badly with the dozens of daisy-chained power strips?), the proceedings were ready to get underway. For those who have not followed the history of RubyConf, this is the 7th annual Ruby conference! According to David Black, who gave the brief introduction, the attendance this year is 15 times the size of the first conference. That is a lot of toast.

And this is going to be a lot of text. Thanks to feedback from many of you, my wonderful friends, I am splitting my RubyConf 2007 in-depth coverage into separate smaller postings. I will post links to each individual session, as soon as I complete them. Here is what I attended on day 1:

RubyConf 2007 - Day 1 Sessions
"What Makes Code Beautiful" - Marcel Molina
"Advanced Ruby Class Design" - Jim Weirich
"Controlling Electronics with Ruby" - Ben Bleything
"Hurting Code For Fun and Profit" - Ryan Davis

After the day's sessions, I went to a very nice dinner with a group of new friends including "The Ruby Way" author Hal Fulton, and David Koontz, creator of a slick new tool for programming Swing entirely in Ruby called Monkeybars. Thanks for a nice time everybody!

We then hurried back, just in time to catch the "town hall" with Matz. Perhaps it was all the rushing around, but to me, the town hall was too chaotic. I'm sure the Ruby Central people had a good concept in choosing that particular format, but I just think it worked out so well. Perhaps doing a town hall on the second night of the conference? Or perhaps just scrap the idea... I'm not sure, but it just wasn't that good, especially after some of the strong sessions we had seen earlier in the day.

Let me be clear that this was no fault of Matz, who was very gracious thru the whole thing, but I think there were too many people with too many different agendas and lines of questioning to pull it off.

After such a very full day of Rubyism, I went back to my room and crashed out, certain that Matz's keynote address the next evening would be much more satisfying.

Sinatra, a Ruby web framework, and Why It Matters

As followers of this blog know, I am very interested in the Ruby language itself, not just web development. But it is undeniable that Ruby has become popular largely due to web development powered by Ruby on Rails. However amazing Rails is, however, it is not the final web framework to be developed in Ruby.

When Ari Lerner first told me of the Sinatra project, I was interested to see where he was going with it. Now that I have seen it, I totally get it, and I am more interested than ever. Let's compare it to Rails, Camping, and Merb, to better understand where Sinatra fits in, and why Ruby programmers should take a look at it.

Unlike Ruby on Rails, Sinatra is not a Model-View-Controller (MVC) based framework for creating websites. If you want helper functions that help you create forms, connect to databases, or any of the other myriad of functions that Rails provides, you will not find them. Instead, Sinatra is a very simple, yet powerful, Domain Specific Language (DSL) for defining RESTful HTTP actions, and then defining how the application is going to respond to them.

Rails requires a separate routes file to define how the web application is going to respond to requests, which hooks up to the appropriate controllers/models. Sinatra defines the simplest thing that could possibly work. When you declare a new "get" or "post" action, Sinatra will automatically add the route, and simply start responding to requests that match.

Here is a simple example of a Sinatra application:

require 'rubygems'
require 'sinatra'

get '/' do
   "Hello world"
end

As you can see, a Sinatra application's code is tiny, similar to Camping in that you can easily create an entire web application deployed as a single file. Unlike Camping, Sinatra does not have such a "crazy meta magic" feel to it... why's coding style is not for the faint of heart.

Like Merb, Sinatra is implemented as a Mongrel handler. Also, like Merb it is both thread-safe and has better performance than Rails. However, where Merb tries to be a "Rails-lite" for devs who are already familiar with Rails, but want a more bare-metal approach, Sinatra unabashedly takes an entirely different direction with its very minimal DSL-syntax.

Not to say that you cannot use ActiveRecord or whatever other Ruby gems you want to create your application. But unlike Rails, Sinatra's base core is incrediby minimal, and it puts the onus on the developer to decide what to include, instead of adding a bunch of things that may not be appropriate for the type of application that Sinatra would be good for.

So what would it be good for? API implmentations, quick minimal applications, and web development that does not want or need things that are included in Rails, like ActiveRecord. Control panel mini-applications, or perhaps widgets. I am looking forward to really getting into some fun with Sinatra... check back soon here for more.

Yesterday, the Ruby Inside blog mentioned Sinatra, and some of us have been digging it for the last few days. Take a look, and you will enjoy the appeal of a simplicity and elegance in development you haven't felt from Ruby for a long time... a very long time.

More Developer Fun In Los Angeles

Last night was the always entertaining Los Angeles Application Developer Meetup. L.A. is not known for the same massive quantity of developers as the bay area, for example, but having joined forces with the LA Ruby on Rails Meetup crew some time back, the monthly event is still growing.

This month's was held at the impressive new digs of YellowPages.com, who have been busy building out a huge Ruby on Rails based local search replacement for their venerable 100K+ lines of Java code. Thanks for the great sandwiches, boys... next time, buy beer!

Anyhow, four presentations took place on various fun topics of technical interest. First, Jeff Yamada and his associate (sorry I didn't catch your name) showed AIR. I then did a short presentation on Continuous Integration and CruiseControl.rb. Olmo Maldonado talked about his impressive JavaScript library MooTools, and then Ari Lerner showed his just-relased Ruby web development framework, Sinatra.

AIR
Long, long ago, I used to work with Flash and ActionScript. Most of us more "serious" programmers were always very frustrated with the language, the programming environment, pretty much everything except for the final product. Since then Adobe has introduced technologies like Flex and AIR to try to address the shortcomings of using Flash as a "real" development tool. Yamada and friend are the authors of the upcoming book "AIR Bible". AIR nee Apollo is designed to provide a way to create native OS applications, while using the toolset that Flash/Flex developers are used to. If you are into Flash/Flex already, then this is probably great for you, but I am not overly in love with so many angle brackets mixed in my code... let's just say that "it ain't Ruby". One small thing I will suggest to the boys: please try to find some relevant application to show for a demo a of a new technology. Between this, and what all of the Microsofties were show a few months back for Silverlight, no one is going to take this new desktop app paradigm seriously!

How To Get Your Code Together and Keep It That Way
Then I did a presentation myself, called "How To Get Your Code Together and Keep It That Way". It was really an exhortation to use the best practice of Continuous Integration, while showing how easy it is to get started with the ultra-cool CI tool CruiseControl.rb. If you are a Rails dev, and you are not using CruiseControl.rb yet, you should be. If you have a development project with greater than zero developers, it is worth it to setup a CI system, even just to keep yourself in check. You can get a copy of my presentation here. But don't just believe me, it is in yesterday's O'Reilly Radar too.

As I was demoing the CC.rb project page, where they are doing CI builds of both CruiseControl.rb itself and the Ruby on Rails project, I noticed that the Rails build has had failing unit tests since Oct. 3. What is up with that? Let's get on it boys!

MooTools
Next up was Olmo Maldonado, once of the authors of MooTools. MooTools is a JavaScript framework for web development along the lines of Prototype or jQuery. I had been hearing about MooTools, but hadn't really checked it out. Naturally, since both of those other JS frameworks already exist, and with Prototype really having dominated in the acceptance wars, MooTools does have a different approach on several levels to justify its existence.

Heavily optimized for speed, according to Maldonado, Moo performs much faster than either Prototype or jQuery on the slickspeed benchmark test at performing DOM selects, which is the core convenience provided by any JS framework.

Another difference is that MooTools libs are completely orthogonal. As such, the developer only needs to incorporate the specific libs that contain the functionality that is required for that application, unlike both Prototype and jQuery which require downloading the entire framework to use any part of it.

MooTools seems to have a more serious emphasis on good software devlopment practices than the othe JS framework projects. One example of this is that MooTools was developed using JSSpec, which is a Behavior Driven Development framework for JavaScript.

Already up to version 1.2, MooTools has been adopted in some very interesting places. The three demos that Maldonado showed were the iPhone version of the Pop-Cap game Bejeweled, the Ubuntu.com website, and then most curious of all, the Microsoft Expression website! What, M$ couldn't use Silverlight? Oh yeah, everyone already has Javascript... no additional download required. Whatever happened to that famous dogfooding?

MooTools is realy designed for the developer who wants to work in pure JavaScript. Most Rails devs like to use the Ruby on Rails Prototype helpers to do nice AJAX-y things like edit in-place and auto-complete functionality. MooTools does all that, plus has a bunch of UI gadgetry too, but having no inline functions, is not really compatible with the way the Rails helpers work. Perhaps someone will create a Rails plug-in that can collect up all of the MooTools Javascript, kida like what the Unobtrusive Javascript plugin does... for those Rails people who want to take advanatge of the DSL-like syntax, instead of dropping all the way into JavaScript.

Sinatra
Speaking of DSLs, the final presentation of the evening was by Ari Lerner, showing his incredibly cool new little Ruby web framework called Sinatra. In fact, I was so impressed by Sinatra, that I decided to give it its own posting. I suggest you go check it out right now!

The R/evolution Will Not Be On Television

The medium of video is better than ever, thanks to YouTube. Video content is a lot improved by splitting video into smaller pieces, making the videos searchable, and most importantly, allowing for self-publishing. Helping for niche content authors to get their message out, has as a natural effect, a large proportion of idiocratic nonsense, but there are gems buried in the muck.

Nothing to me is more emblematic of this, than the brilliant videos put together by Michael Wesch of Kansas State University. His latest work Information R/evolution continues the themes in his famous Web 2.0 - The Machine Is Us/ing Us video, which you must have seen by now. The real genius of Wesch's videos, is not just that they explore such interesting ideas, but that they break complex concepts down into very easily digested pieces, while also being fun to watch.

R/evolution expands on ideas about decentralized organization of information. For example, groups of people tagging videos, or digging a new blog post. What this does is allow us to look/find information in more than one way. This is quite different than the top-down categorization typical in physical systems like file cabinets, and just as they are quite necessary there, they get in the way in the virtual information space. Information stored electronically, instead of on paper, allows us to look at that information in a whole different way, but Wesch points out how we constantly tend to confine our views based on the preconceived notions built up in a physical world.

As it just so happens. Gord Hotchkiss has an interesting new posting about some of the implications of these ideas. Hotchkiss's premise is that we are evolving in the ways that we actually perceive information, due to the changes in how we access it.

I have been seeing this lately firsthand in my son's use of his web browser. He was recently unconvinced by my explanation about why he might want to type a web address into the address bar, instead of just typing it into Google and clicking on the first link, as he has taught himself to do...

Is Your Database Getting Tired?

Is your database getting old and tired? Mike Stonebraker thinks so. Stonebraker is a database guru and long-time researcher, and when I say database guru I mean one of the founders of Ingres, and former CTO of Informix, not just some guy who knows how to debug a stored procedure.

Here is a juicy quote from a recent article published by MIT of which he is one of the authors:

We conclude that the current RDBMS code lines, while attempting to be a "one size fits all" solution, in fact, excel at nothing. Hence, they are 25 year old legacy code lines that should be retired in favor of a collection of "from scratch" specialized engines. The DBMS vendors (and the research community) should start with a clean sheet of paper and design systems for tomorrow's requirements, not continue to push code lines and architectures designed for the yesterday's requirements.

Strong stuff! Especially for a generation of programmers for whom the relational database is just another ubiquitous part of their standard solution architecture. So is SQL the new HTML as some have claimed? Or are we heading to a new generation of database engines that are created individually for each solution space, perhaps created on the fly and defined in a domain specific language.

Carpe Emporium

I was wading thru my daily ration of VC blogs just now, when something caught my eye. Or I perhaps I should say, I was "submerged, weightless, suspended in the tepid depths of the thing... in a state of perfect sensory deprivation, when all at once an extraordinary thing happened: I noticed something!"

(Thank you Mr. Wolfe)

There is the midst of Fred (A VC)'s 30 thoughts at 30,000 feet, it was:

Should the CEO of every technology company be a technologist? It seems like it’s easier to teach a technologist finance, marketing, sales, and management than it is to teach a good manager technology. And it seems that key business drivers are increasingly technical. It was true in the past, when Novell beat Banyan with marketing over technology, or when Oracle beat a host of relational database companies with sales over technology, that technology alone didn’t win the day. But let’s look at Facebook versus MySpace, Google versus Yahoo!, Skype versus Net2Phone, and Apple versus the entire music business. The companies with strong technologists as leaders seem to win more often these days.

I could hardly believe my eyes! Back when my associates and I used to do silly things like meet endlessly with VC's (and you know who you are) I often heard about how "we would need to hire a CEO cause, ahem, everyone knows technologists cannot run a company."

Now that we are entering the commodity period for software startups, these people must be getting desperate. "Sure, we'll let you be CEO..."

Pretty pretty pretty pretty... good

Yet more wisdom about user experience and interface design from the Signal Vs. Noise blog, this time debunking the mistaken idea that a good user interface has anything to do with just drawing a pretty picture, and handing it over to someone to implement.

One phrase in particular really caught my attention, "our designers apply their talents to the native materials of the web."

Now, I am not trying to pick on Photoshop people here, but how can you design an interface that is interactive, without using interactive tools to do so? DHH really has this right, since the web is built with HTML and CSS, a good web interaction designer needs to work with these "materials".

Likewise, a web interaction designer, might not be good at videogame design. Both the web, and console games, have their own set of standard use metaphors. Even each console has its own language, consider the vast difference between UI for the XBox 360 vs. UI on the Wii. Each has its own selection of native materials, and choosing to ignore these elements by inventing your own, makes it more difficult for users to anticipate what the software is going to do, based on their previous experience.

As such, working with the native materials of the web means conforming to a very small set of options, an exercise in constraints. This does not mean there should not be aesthetic to web UI design, quite the opposite. But it is an aesthetic based on sticking to certain forms, and the further you move away from these forms, the harder for users to adjust.

The realm of "graphic" design is only indirectly related to "user interface" design. Both require design, but each also requires certain distinct skills and knowledge from the other. A user interaction designer may work in the visual realm like an artist, but has to have an engineer's discipline, at least it they are going to be good, and not just pretty.

The Proper Use Of Color

Really cool article here from of all places NASA (go figure) courtesy of the Signal Vs. Noise blog. Entitled "DESIGNING A COLOR GRAPHICS PAGE", it really breaks down a process of utilizing color to maximize user understanding of information.

Color for its own sake is better kept to the domain of art. Functional design, like that of software user interfaces, need to be much better thought out, reaching for both utility and aesthetic qualities. Not an easy goal to achieve. The NASA article is a very good, if erudite, treatment of the subject.

UI wonks and wonkettes always mention Jakob Nielsen. Myself, I have never been a big fan of his. Sorry, I know all user interface snobs are supposed to be, but Nielsen's own website has famously ugly design and (gasp) poor usability. I am not making this up! Plus his big famous book was really boring.

I am much more a fan of Steve Krug and his fantastic "Don't Make Me Think". Now THAT is a book on usability. It probably took a really long time to write such a short book.

Stop The Bug-Based Development

I enjoyed reading Phil Haack's little "you're either with us or against us" diatribe from earlier today, where he rails against non-test-driven development. I only differ in that I prefer to call it Bug-Based Development (BBD).

So are you one of those fifth-column types who is providing aid and comfort to the enemy? Draw a line in the sand... never make your troops take casualties retaking the same ground twice... no bastard ever won a war by dying for his country. You won it by making the other poor dumb bastard die for his country.

Give 'em hell, Phil!

Weighing In On The Upcoming Ruby VM Smackdown

Earlier today, I read with great interest the potentially inflammatory post where Ola Bini proclaims the Ruby VM wars already over, and basically divides the Ruby VM empire into two halves, with the center controlled by Rome, err, I mean Rubinius primitives.

I had already come to this conclusion a while ago. Not because I am smarter than anyone, FAR from it. Probably because I am more superficial, and easily impressed by meaningless characteristics, like how cool is the name Rubinius?

Seriously, back to something more erudite, like Ola's post. Notably missing from this future of Ruby utopia is any IronRuby/Ruby.NET vision. Is this a simple oversight, due to the pro-Sun anti-MS bias that any Java programmer has to have, or more likely knowing the source, is it because of the sadly glacial progress of Lam and his new friends, as compared to both Rubinius and especially JRuby?

Man, it must SUCK to work at Microsoft sometimes!

RubyConf 2007 => Ruby VM Smackdown

I just registered for RubyConf 2007, which will be held Nov. 2-4 in Charlotte, NC. If you want a more intimate, more hard-core Rubyist experience, than what RailsConf is turning into, RubyConf looks to be it.

There not being that many tickets available, you better register right now if you want to go. I registered without even looking at the agenda first... just filled out the registration form, and hoped it's was not too late.

Once I has nervously typed my credit card info, and gotten my email confirmation, I took a few breaths. and got around to checking out the schedule for the conference I had just committed to attending. I was not disappointed.

Lo and behold, the ultimate battle of the Ruby VM's will be taking place on Saturday, Nov. 3. Take a peek at what's in store:

9:00A - John Lam - State of IronRuby
10:00A - Charlie Nutter - JRuby: Ruby for the JVM
11:00A - Evan Phoenix - Rubinius 1.0

Wow! If you care at all about the future of Ruby as a language, not just as a vehicle for fevered dreams of Ruby on Rails-based world-domination, you can't help but get excited. The three ascendants to the throne of dynamic language glory, all duking it out in a back-to-back 3-hour frenzy. Yum!

Improving the language performance of Ruby is the big thing needed to push out all those other wanna-be next big languages into the dustbin of interesting languages that no one uses. I think Erlang is really neat, don't get me wrong, but one look at that syntax, and sugar is not what comes to mind!

Visualize This

Did you ever want to present information in a visual format, but didn't know which one was most appropriate? Don't know a Petri net from a concept fan? Or perhaps you just need even more visual stimulus from your information?

Well, welcome to a feast of visualization splendor. Just have a glance at the Periodic Table of Visualization Methods... your eyes will never go hungry again.

Thanks to Visual Literacy for creating this great info, and to Jeff Atwood of Coding Horror for blogging about it.

Lord Raise Me Up

As usual, human ingenuity has raised science to a new height. In this case, a very small height, but let us not quibble about a few details. UK researchers have discovered a way to circumvent the Casimir force, which is what causes very small things to clump together. By using a clever type of lens, the researchers were able to reverse the Casimir force in their experiment.

Despite the fun headlines, this does not mean repulsors for the masses. Any practical application would likely be amazing new manufacturing techniques for nano-tech materials, and new types of nano-devices, not flying cars at this point. More like nano-engines that are more efficient due to reducing friction by "floating" the components of the device together.

At the very least, this should spawn a new outbreak of copycat perpetual motion machines and the like...

Fun At Yahoo! In Los Angeles

Last Tuesday night was July's Los Angeles Web Application Developer Meetup. This event is starting to get really good. Not only were there lots of people who came out, but our hosts Yahoo! actually bought us beer too. Hint to future hosts of the meetup... be cool like Yahoo! and provide BOTH a projection screen and beer.

There were two especially fun presentations, at least to me. Jim Bumgardner of Yahoo showed off some of his really interesting web gadgetry. Now I didn't know Jim when I walked into the meetup, but I have seen his work. The man has done some innovative stuff over the years, that is for sure. Also, he has to have one of the best gigs I have seen for a while, getting paid to build really fun things.

He showed several different ways to choose one item from a group of items, without resorting to any of the usual tired UI metaphors. My personal favorite was the Wheel of Lunch.

The other extra fun presentation was Richard Herrera showing Pickleview, an iPhone application created to track real-time baseball scores. Now if they were soccer scores, I would have had to run out and get an iPhone... actually, I may just end up doing that anyhow. But I digress.

Developed in PHP (but we won't hold that against them, will you, dear reader?), Pickleview combines an XML feed of Major League Baseball scores, and mashes it up with Twitter. A pretty cool little application, I would have to say.

Now I am getting interested in whipping up something for the iPhone myself... stay tuned.

Drunk In Space

Apparently, the altitude in orbit is not high enough for more than one of NASA's finest. According to an independent panel, on at least two occasions astronauts were allowed to fly after flight surgeons or other astronauts warned that they were drunk, so drunk that they posed a flight safety risk.

You cannot have a machinist fabricating spacecraft parts who is unable to urinate in a little cup, but a DUI is space is not a problem that NASA is concerned with? I guess the sky IS no longer the limit...

An alternate view is as follows: the astronauts know how poorly designed the shuttle is, and need to throw back a few stiff ones to get back in the saddle. These are likely the more experienced ones who have actually been up a few times, and know the risks. Perhaps they were colleagues with the crews of the Challenger or Columbia. We shouldn't judge too quickly what it takes to do that job, as much as many of us many have fantasized about a journey into space. But they should still need to pass a breathalyser before they fly a 1.7 billion dollar spacecraft.

IronRuby Lives!

John Lam and company have finally gotten something together to release to the world at large for their IronRuby project. I have not had a chance to play with it yet, but as a hard-core Rubyist I will, of course, have to do so.

A few interesting observations from how they have chosen to go about developing this project. One is that they are distributing the source code, albeit as part of the Microsoft Permissive License. I don't really know much about this MS-license, I will have to go find out how permissive it really is.

Another interesting point, is that the IronRuby project will be managed through RubyForge, instead of CodePlex or another of the .NET open source communities. They really want to make an effort to reach out to the Ruby community, it would seem, by being in the old familiar places.

I look forward to playing with it...

Eventually The Machines Will Win

I have never been a big checkers fan. Good thing, cause I would have had to give up the game after the recent "solution" of the game by a team of Canadian computer scientists. Every possible move of every possible game has been mapped, and a checkers playing program can take each of these into account before deciding on its next move. No human player has such ability.

Actually, as it turns out, the best possible outcome in a game of checkers, given two players who each make perfect moves, is a draw.

The next game to be solved will likely be othello, than other even more complex games like chess, which has 10²⁰ more possible moves than checkers.

It is only a matter of time before sufficient computing power allows the machines to contemplate eventualities of which we have not even postulated the existence.

The Singularity IS coming...

Ruby Is More Of A Free Love Kind Of Language

I have been really, really busy lately, which is why I have not had a chance to post anything. I finally caught up on some reading and listening, and John Lam, father of the IronRuby project at Microsoft, has a fun interview on the DotNetRocks podcast. Irrespective of how I may currently feel about the direction over at Microsoft or rock, it is an interesting interview.

My favorite line has to be where John is describing the cultural differences between the users of Python vs. Ruby programming languages. "Ruby is more of a free love kind of language," he says.

I guess when they say that they have drunk the Ruby kool-aid over at Microsoft, they really mean it. But will they wake up hungover and pregnant with a baby they will name "Moonbeam"?

CruiseControl.rb and RCov Are SO Good Together

I spent a bit of time this morning getting CruiseControl.rb and RCov working together for a new client's fairly LARGE Ruby on Rails (70+ models, 40+ controllers) project. If you are not familiar with CruiseControl.rb, it is the Ruby based continuous integration tool from ThoughtWorks. RCov, on the other hand, is a very well known code coverage tool for Ruby. The implementation was incredibly simple, but finding the information on how to get the two working together required a perusal of the CruiseControl.rb code itself.

First of all, you will need to install the rails_rcov plugin. This useful plugin allows you to really easily run RCov using rake, and is essential to simple RCov integration with your CruiseControl.rb builds. You can install rails_rcov like this:

./script/plugin install http://svn.codahale.com/rails_rcov

Use the "-x" option if you want to use an svn:external link to the latest version of the plugin. I personally don't like to do that...I want control over when the software I am using gets updated, thanks.

Once the plugin is installed into your project you have some useful rake tasks like this one:

# sort by coverage
rake test:units:rcov RCOV_PARAMS="--sort=coverage"

Now you are ready for the final bit, which is adding a "cruise.rake" task to the "lib/tasks" directory of your Ruby on Rails project. The task should have something like this, which was lifted verbatim from the CruiseControl.rb build of CruiseControl.rb itself (that all sounds kinda twisted, but it is cool):

desc 'Continuous build target'
task :cruise do
  out = ENV['CC_BUILD_ARTIFACTS']
  mkdir_p out unless File.directory? out if out

  ENV['SHOW_ONLY'] = 'models,lib,helpers'
  Rake::Task["test:units:rcov"].invoke
  mv 'coverage/units', "#{out}/unit test coverage" if out
  
  ENV['SHOW_ONLY'] = 'controllers'
  Rake::Task["test:functionals:rcov"].invoke
  mv 'coverage/functionals', "#{out}/functional test coverage" if out
  
  Rake::Task["test:integration"].invoke
end

That's it. Now you have incredible code coverage goodness right within your build. You can even browse the source within the browser window of the CruiseControl.rb dashboard and see which lines of code were covered by your tests, and which were not...

So if you have a Ruby on Rails project, with a project team of greater than 1 developer, you had better start using CruiseControl.rb. It is too easy, and the payoff of doing continuous integration is huge!

A Little Bit Of Merb In Los Angeles

Last night, I gave a short presentation on Ezra Z's cool Ruby web development framework Merb at the Los Angeles Web Developer Meetup. Microsoft was kind enough to provide space at their new downtown offices, and even buy pizza. Can you say "(munch munch) Silver (crunch) light (munch) launch (gulp) budget"?

When I started my presentation, I asked the room how many people were using Ruby on Rails. Almost everyone in the place raised their hand. Nice! My talk was a brief review of what Merb is, and some of the similarities and differences with Rails. The crowd was very attentive, and there were some good followup questions asked afterward.

Anyone who is interested in the slides from my presentation, they are available here.

There were also presentations by Ari Lerner about Ruby metaprogramming, and Ben Sandofsky on the Seaside web framework. I especially liked the example that Ben used to illustrate continuations.

Lastly was Woody Pewitt, the Microsoftie tasked with demoing Silverlight. It was funny how long it took their poor projector to recover when he plugged in his Vista notebook to show his demo, given that every other presenter was using a Mac. Woody was a good sport about it, and there really is a lot of interest in Silverlight right now, so I saw a number of people talking to him after the demo.

Anyhow, a good time was had by all, and I am looking forward to the next one. Here in L.A. we have a thriving little tech scene of our own, albeit not as huge as the bay. But don't count us out!

Without Air, No One Can Hear You Scream

I was shocked to read about the ongoing problems with the life support computers onboard the International Space Station. Every time I hear of problems up there, I feel a serious rant coming on.

I grew up on science fiction books. In fact, I would have to say that the vast majority of my childhood was spent far away from this planet. Suffice to say, I am a serious supporter of space exploration.

But this madness with the ISS is about more than I can take. Between the noise, the need to keep reboosting its orbit, and the lack of any real scientific value, we really SHOULD abandon ship at this point!

Microsoft Vs. The Galaxy

"The more you tighten your grip...the more star systems will slip through your fingers..." - Princess Leia

Power Rangers Should Test First

Last night, I got home a bit late. My 8 year old son was still up, watching the Power Rangers. "Sit down and watch with me, Dad," he said. "I'm surprised you still like the Power Rangers," I said, as I sat beside him on the sofa. "I mostly just like the vehicles," he told me.

The Power Rangers were in trouble in this episode. The bad guys had taken remote control of the Rangers' giant robots, and the Power Rangers were helpless without their usual firepower. The Smart Rangers, meaning the guy with the glasses and the Asian girl (WTF!!!), were constructing a jamming device to block the bad guy's signal, while the other Rangers got their behinds handed to them by their own robots.

"OK, that finishes it. Let's go!" exclaimed Glasses Ranger as he attached the last part to the jamming box. They rushed off to the scene of the battle. "I hope this works," said Glasses Ranger and pushed the button. Nothing happened. "Oh no, what could be wrong?!" cried out the Smart Rangers.

My son, who had been quietly watching all of this, suddenly spoke out. "They're stupid. They should have tested it first."

Ruby/Microsoft?

Martin Fowler just posted on his bliki a little piece entitled RubyMicrosoft. As I read it, I felt a strange chill run down my spine. Perhaps a few words of explanation are needed...

At RailsConf recently I stood at the Thoughtworks booth for a moment chatting up Fowler, and embarrassing myself by asking for a photo with him (he doesn't pose for photos with people). Luckily, I was rescued by the arrival of Oli Bini, and an ensuing short discussion about JRuby. I expressed my admiration about how they had been "cleaning Microsoft's clock" as far as their much faster progress with a runtime for the Ruby language then Microsoft's efforts with the DLR.

Much to my surprise, Martin was actually paying attention to what we were saying (I mean to what I was saying, after all he knows and speaks with Ola), and chimed in about how Thoughtworks was working with Microsoft on language compatibility for IronRuby. I expressed a poorly articulated skepticism at the prospects.

Lo and behold, the RubyMicrosoft blog posting sums up rather well the half-formed mumblings I was trying to stammer out. Well, this is why he is a keynote speaker, and I am a dead programmer. However, impressed as I am at his intellect, I am not sure I share his optimism about Microsoft.

I certainly don't know if I am an "alpha geek" or anything like that. I'd rather be a jazz programmer than a rock star. But given my long history working with Microsoft technology, and then the seemingly contradictory fact that I was at both RailsConfs, I must really identify with the movement. Chalk it up as just one more developer who Microsoft is losing to the rebellion.

I Would Rather Be A Jazz Programmer

I have reading a bit lately about "rockstar" programmers. Recruiter ads are proclaiming "Rockstar programmer needed". Various websites named rockstar<name of technology> or alternately <name of technology>rockstars are springing up everywhere.

I would rather be a "jazz musician" programmer, myself. Nothing against rock, don't get me wrong. Glam, punk, metal, I can go there. I frequently do. It's the "star" part, that has been starting to bother me.

Here are some differences, as I see them:

Rockstar
- One big hit song, then disappears
- Embarrass themselves as they age
- Claims they wrote the song
- Keeps trying to get back that sound they used to have
- Gets back together with the old band after unsuccessful solo careers
- Wants to marry a model and have a movie cameo
- Won't play without a contract and advance payment

Jazzer
- One big hit, and they become an influence
- Get cooler with age
- Claims the song is just a cool arrangement of a standard
- Keeps trying to produce a new sound
- Records with a variety of musicians over time
- Wants to become a professor at Berkeley School of Music
- Jams on the street corner just because they feel like it

RailsConf 2007 - Day 3

By the time we got to RailsConf Day 3, only the most hard core remained. In other words, almost everyone. And we were glad to have stuck around, because some of the best content of the entire conference was yet to come. David Black, introduced two integral members of the Ruby on Rails team, Jamis Buck and Michael "Koz" Koziarski, the co-authors of the seminal "Rails Way" blog.

The Rails Way
Jamis and Koz and both written and read a lot of Ruby on Rails code. The Rails Way is not just what could be done, but what should be; the best way to build a Rails application. Their knowledge of best practices is second to no one, and they shared a whole bunch of great information. I can't really do their tag team code review justice, but here are the highlights:


Fat controller is anti-pattern
*hard to test
*break apart into a model object

A model is anything that encapsulates data and logic, not just an object that talks to a database.
*one benefit of this encapsulation is testing
*another advantage is the form_for handle can easily use a model

When to use with_scope
*move the logic to the parent class, so as to freely get the scoping with no extra work
*do not go crazy with DRY

ActiveSupport has helpers to make some code self-documenting for dates/times

Asociations
*People make associations, but then fail to use them throughout the rest of the application
*this helps keep code from breaking in the case where database keys change, for example

Cargo culting
*He hates !! (not-not) idiom.
*Ternary operator...likes it sometimes
*Explain exactly why you need boolean returned, again?

Model helpers
*use associations in views instead of instance variables

Routing
*simplifying non restful routes - map.with_options

Override to_param to make nice looking URL

Returning method

 returning new do |booking|
  booking.some_thing
  booking.some_other_thing
 end

The session was really great. Pretty much everyone in the room, no matter how advanced their level, got something good out of it. We could have stayed there all day, with different people bringing up pieces of code for these guys to refactor. If you can, hire them.

Javascript - Fu
Dan Webb is the author of the LowPro extensions to the Prototype JavaScript library. He had a really nice tight Takahashi style presentation. He was also extremely funny, and the information incredibly useful. Once again, the last day of RailsConf really had a lot of good stuff!

JavaScript is the language we all love to hate. A peasant language, meaning that "lower-level" programmer have to work on the JavaScript code while "higher-level" ones get to work on the "architecture".

JavaScript - fu is not easy to master. Developers are forced into refuge by using frameworks and libraries.

The Ancient Manuals of JavaScript-Fu
* The Tao Of The Event Handler (Events)
* Five Method of DOM Fist (DOM)
* Lightning Script Style (Optimization)
* Iron AJAX Technique (Progressive enhancement)

There are big differences in browser implementation of JavaScript.

Two main techniques: inline vs. scripted event handlers

Inline - applied as soon as browser loads

What happen when more than a little bit of inline code

Scripted event handlers
*problem in they attach after the element is loaded

LowPro library is an extension library for Prototype, but Prototype library trunk now has a similar thing.

// Prototype 1.5+ and LowPro
Event.onReady(function() {
  $('item').observe('click', function() {...});
});

// Prototype trunk
Event.observe(window, 'DOMContentLoaded', function() {
  $('item').observe('click', function() {...});
});

// Basic onload
Event.observe(window, 'load', function() {
  $('item').observe('click', function() {...});
});

Attach handler from script to each object you want, in order to stay DRY

Separate your JavaScript out of your pages, just like you separate CSS

Large number of event handlers can choke browser performance

How:
* use script based by default
* in bug page try event delegation
* if all else fails use inline

Event delegation - yahoo tehnique
* event bubbling

Better inline handlers
*a tag needs an actual HREF
*do as little as possible, for example:

 return view(this);
 function delete(elemtn)
 {
  new Ajax.Request(element.href), {
   method: 'delete'
  });

  return false ;
 }

5 methods of DOM fist
*3 oficial W3C methods to modify the DOM
- appendChild
- insertBefore
- replaceChild
*1 non-standard (from IE)
- innerHTML

DOM methods insert with precision - have to create nodes first
InnerHTML shifts large bulk amounts of HTML, but with little control

Really easy to use innerhtml from Rails with Ajax

The bastard son - unholy marriage of DOM methods and HTML

Element.fromHTML = function(html) {
  var root = document.createElement('div');
  root.innerHTML = html;
  return root.firstChild;
}

var node = Element.fromHTML('<div>');
element.insertBefore(thing, node);

Lightning Script Style
* making things as fast as possible
* do not use javascript_include_tag :defaults cause it downloads 5 big files
* browsers take time both to download AND evaluate a script
* the less JS the better
* mooeffects smaller than scriptaculous, but less powerful
* browsers can only load 2 resource at once
* combine js files
* Use gzip instead of JS based minification.

Make sure everything is cacheable

Faster loops

 for(var i - 0, enemy;
  enemy = enemies[i]; i++) {
 defend(enemy);
  }

Be careful with selectors
$$('.anything'); slower
$$('span.anything'); slow
$$('#item .anything'); // css xpath selector

Iron Ajax Technique
* rule #1: browsers suck
* main browsers are getting better quickly
* but what about the others?
* Corporate security blocks Javascript at firewall
* the traditional rails opin: f* you!
* but why turn away users if you don't have to

Progressive Enhancement
1. start with plain HTML
2. test if necessary brwt features are there (XMLHTTPreq, canvas, etc)
3. If present, then apply xtra JS features

Tt's easy to apply to ajax
* HTML
* JS
* RJS

Try progressinve enhancement first

Lastly, Dan recommended a few books on Javascript he said are better than all the others:
* Professional JavaScript Techniques
* Bulletproof Ajax
* DTHML Utopia: Modern Web Design Using Javascript and DOM

Dan's session was full of good stuff. Even the people who thought they knew it all were scribbling down a couple things before the end. And thank you, Dan, for making it really fun as well as informative.

Dave Thomas
Dave's speech was unconventional, in that he doesn't say what people expect him to. I consider that a good thing. Many people in the crowd were perplexed for long moments as he spoke. For those people who need a simple explanation of Dave's speech, the two recurring themes for RailsConf were "give", and "don't get stuck".

"Just to set the record straight, the first RubyConf was 3 people and a dog, and the speaking was in between sips of beer"

Orthodoxy - do what is expected
Orthopraxy - do the "right thing"

It's called Object oriented programming, not class oriented programming. Challenge: write next next program with objects instead of classes

What Are Your Cargo Cults?

Dave is a real thinker, and I hope that our community can rise to the challenge and keep progressing. Embrace Orthopraxy!

RailsConf 2007 - Day 2

After the incredible energy of RailsConf Day 1, Day 2 seemed to slow down the pace a little bit. That was good for me, as I could spend some time catching up with friends both old and new, and not just attending sessions like an information junky. First would come the morning keynote speeches from Cyndi Mitchell of ThoughtWorks, and headliner Tim Bray of Sun Microsystems, with a short interlude from Charles Nutter.

Cyndi Mitchell - Thoughtworks

Ms. Mitchell is UK Managing Director of ThoughtWorks. As such, she is a polished corporate representative, which is exactly the kind of emissary that Rails needs in big organizations. She had a few interesting points:

* 40% of new work at ThoughtWorks is coming from Ruby on Rails in the enterprise
* We need to reclaim the word "enterprise" back from meaning "bloated, inefficient, and expensive" to its original meaning of "entrepreneurial"
* The "real" enterprises are using Ruby on Rails to get stuff to market quickly
* ThoughtWorks is offering a complete Rails production stack called RubyWorks, and is will be providing paid 24/7 support for Rails.

Tim Bray - Sun Microsystems
After Cyndi, the irrepressible Tim Bray took the stage. Despite not really being that much into Java, I have been following Tim's blog for quite some time, as he is a smart thinker with plenty to say to the industry at large.

Tim thinks that the Ruby language is as important as Rails (I agree!!). With JRuby, Sun wants to sell lots of hardware to large enterprises that will be choosing Sun Hardware and Solaris as the preferred platform for their Rails applications. Sun is also doing lots of work on NetBeans to do better Rails development.

Tim then briefly brought up Charles Nutter to give him some Rails street cred...er, I mean to explain why Ruby developers should care about JRuby.

Charles made two main points:
* A whole different way to do Ruby dev...using tried and true Java tools that already exist
* Move into enterprise where Java is accepted but Rails is still not

Then back to Tim:
It is not CIO's who lead industry...it is people like us.

How to make money on free products
* first you get adoption
* then you get deployments
* then you can monetize at point of value - no large business will adopt any tech that is not supported

Big companies will either get a handle on web 2.0 or get disintermediated

He assumes Rails will succeed beyond our wildest dreams.

Java, php, and .NET will never go away

The network is the computer...and its a heterogeneous network. And JRuby is how we get everything to talk to each other.

Java really consist of three main parts: language/JVM/Java APIs.
JRuby lets Rails programmers access the latter two.

How do we get everything to talk to each other? REST

Etags are a way to solve the REST problem with different versions of the same data.

ATOM - Everything should have a publish button: cameras, phones, browsers, etc

Is REST all there is? SOAP... WS-* 36 specs, ~1000 pages of documentation.

WSIT - interop with MS WCF

Hot developer issues
*static vs dynamic languages
*maintenance
*tooling
*integration
*concurrency
*time to market
*scaling
*load balancing
*observability
*file IO
*DBMS
*Shared nothing architectures
*CPU
*concurrency
*debugging
*unit test
*functional programming?

Which matter the most?
*Conventional wisdom for each language
- Java: performance, tooling
- php: web scaling, ease of use
- Rails - time to market, maintainability
*Tim says: The most important are Time to market, and maintainability

Extra Action Marching Band
After the speeches, I went to a session I didn't find that interesting at all, and so in the interest of not offending anyone else too badly, I shall let it remain anonymous...you know who you were. But near the end, a massive blast of sound came from the entrance to the conference center, and then proceeded past the sessions rooms toward the main hall.

It was the Extra Action Marching Band, an amazing avant-garde performance troupe. If San Francisco (which is where they are from) had a love-child with New Orleans, it would be something like this band.

Despite an almost-incident with the conference center security staff, they were able to finish their set. The music and performance were quite incredible, showing a high level of musicality as well as serious creativity. The bullhorn with a delay pedal attached was really amazing sounding...I have to make one like that for my harmonica.

After this unique musical interlude, it was back to the conference sessions...thamks to Tim Bray for the photograph.


Xen And The Art of Deployment
Ezra Zygmuntowicz of Engine Yard, Merb, and BackgrounDRb fame gave my favorite presentation of the day. The session was packed, with both information and people. If you wanted information about scalability, at least from the perspective of the stack, then this was the high point of the entire conference. Here are copious notes of what he said:

Serving up Rails right now is all about Mongrel

Mongral uses a Ragel state machine for validation

Why is mongrel better:
*HTTP is well known protocol
*Mongrel easy to setup and use
*Transparent wire protocol

Thread safety
*Rails not thread safe
*1 request at a time per mongrel

New dog, old tricks
*Wide # of options to load balance front end
*pen, pound, HA-proxy
*Lightspeed can serve static files
*Apache 2.2/mod_proxy_balancer can do same

Each current solution has problems

Nginx
*serious performance
*small resource footprint
*no leaks under heavy load
*killer rewrite and proxy mods
*author is cool and responsive
*Nginx + Mongrel
*This is THE stack
*apache for mod_dav_svn
*flexible config allows both serving static and dynamic requests
*fast!!!
*Nginx cannot do upload progress due to buffering
*no connection rate limiting for proxy modules yet

The future for nginx
*mod_rewite going away
*replace with http_script_module
*embed NekoVM directly into nginx

Perfect simple stack
*Linux
*Nginx
*Mongrel (mongrel_cluster)
*Monit

Swiftiply - the cool new solution

Evented Mongrel
*hot patch
*remove ruby treeads
*replace with eventmachine event loop
*mongrel single threaded
*big IO speed increase
*stand up to higher load

How is single threaded faster?
*Ruby green threads are slow
*mutex locks are expensive
*one process can only do so much IO
*event driven means running in a tight loop and firing callbacks
*without context switching between threads, single process has less overhead

Mongrel vs evented mongrel - performance stats
*1 user - 1K more req/sec
*100 users - 758 req/sec vs. 3700+

Swiftiply proxy
*event drive proxy, small memory footprint
*faster than ha-proxy

How is swiftiply different
*In a normal proxy, you need to config each back end server in advance before starting proxy
*swiftiply is a client/server architecture, where new back end servers register with proxy
*keeps persistent connection between proxy and back end servers
*auto-configuration of proxy

This means you can start/stop as many mongrels as you want, and they get configured into proxy, opening the door to auto-scaling

The Zen of Xen
*monolithic linux VS modular lnux
*old model: one box running all services
*new: specific virtual machines setup for specific purpose

We all want to modularize application why not modularize servers

What about more than 1 box?

Old school - more boxes
*mysql box
*another box for other services

New school
*add another xen box
*pick resource intensive parts, and more to another VM
*each VM only runs one thing, but well
*target performance problems
*scale better

Advanced clustering
*boot off dom0 off of USB drives
*SAN for all Xen domU
*red hat clustering suite for fencing and cluster options
*GFS for 100% posix file sys
*hardware load balancer, or dedicated box running Ultra Money or LVS

Create a fabric of compute and storage
*If a node fails, just swap in another
*Move hot VM's to less loaded machines
*Deploy app on 1 node, then bounce mongrels with GFS
*Fragment and page cache across nodes
*Scale from 1 or 2 VMs to as many as traffic requires and then back down again as traffic subsides

RAM RAM RAM
*most rails apps are RAM bound before they become CPU bound
*Avg mongrel serves 70-120 mMP PER mongrel
*RMagick is a typical RAM hog
*:include on active record also very bad performance
*95% of rails apps will leak memory at point or another

Use Rails plugin leakhouse to find leaks

Rails eats DB resources for breakfast

Most people's production apps hav no database indexes! Learn where and when to apply indexes.

ActiveRecord insulates developers so much to the point of massive inefficiencies.

You will need to denormalize data and use custom SQL statements to get performance

Other Tips
*do not use file system sessions
*script/runner is inefficient. do not load rails into bgprocesses.
*Use raw MySQL and Ruby without Rails if you can
*DO NOT use script/runner to pocess incoming email. Run deamon in loop and poll svr with net/pop3 or net/imap

Rails is great for 80/20 rule, but you are on your own for last 20%

Learn how to write custom mongrel handlers

When is optimization NOT premature?

Ruby is plenty fast, its Rails that is on slow side

Cache, cache, cache espcially static HTML files

Do not store full ActiveRecord object in session, just store hash to recreate it

Parting thoughts
*do not take anyone's word as gospel
*test and benchmark for yourself
*trust but verify

The Rest Of The Day
After Ezra'a session he was swarmed like a rock star. I know, cause I was standing nearby having a really nice chat with Zed Shaw the creator of Mongrel and Evan Phoenix, the creator of the Rubini.us Ruby runtime I was mentioning yesterday. You go, Ezra!

Later on, I got to hang out at the Engine Yard booth with Ezra for a few minutes, where Mike Brown and some other brilliant Kiwi whose name I didn't catch were chatting him up. I learned even more about hard-core clustering from listening to those guys go off...all I can say is I'm glad I have hosting at Engine Yard!

I wanted to go to Dr. Nic's RejectConf, but so many people told me they planned on going that I figured I wouldn't get in. I couldn't take the prospect of being rejected twice at the same conference, so I made other plans which turned out to be really fun.

After dinner with the same group of RailsConf friends from last year, with more delicious Portland beer, and excellent conversation, I headed to the BoF sessions, to hear about Amazon's EC2 service. I really wanted to learn more hard-core details about it, but so many people were just hearing about it for the first time, that the session was dominated by introductory questions. Oh, well!

I was about ready to turn in. Lucky for me, Rails Machine was having their party at my hotel. Bradley and company are really smart, cool people, and also offer a fantastic service, so I was glad to hang out with them for a few minutes. The most fun was jamming on harmonica with Joey deVilla the AccordianGuy. After hearing him last year, I had brought a couple of my harps with me just in case, and we finally had a chance to bust out a couple of songs together. That was really fun! Thanks, Joey. If anyone has any photos or video, please post it somewhere...if not, well, you had to be there.