Conference Introduction

David Black did his usual "Welcome to RubyConf" thing. Sounds like one or two presenters didn’t make it, so we will be doing some creative scheduling. The new PickAxe books are here, but they won’t be handed out until this afternoon (boo hiss). Oh, well.

Teaching Ruby in a Corporate Environment (Jim Freeze)

Jim is working for an EDA company. His company has established Ruby as the "knighted" language for development in this company consisting of mainly Electrical Engineers. Jim has a 3 day course on teaching Ruby to the EEs. It is oriented toward coding neophytes. I really appreciated his examples that were targetted for particular kinds of engineers.

Ruby as Maestro (Rich Kilmer)

Rich’s talk was a last minute addition to the presentation list to make up for a missing presenter. Rich’s company used Ruby to automate a component based blackboard system running on more than 300 nodes. The active agent program is a huge distributed java program, but Ruby is used to configure, build and control the system.

Rich’s project uses one of my favorite features of Ruby … the ability to create domain specific languages for specific purposes.

  wait_for "SocietyQuiesced", 2.hours do
    do_action "StopCommunications"
    do_action "StopSociety"
  end

(an aside)

There seems to be a running commentary on IRC #ruby-lang if you want to listen in.

Lunch Break

Using and Extending Ruwiki (Austin Ziegler)

Ruwiki looks like a very promising wiki clone. I’ve considered using it for my comments page. Ruwiki is very extensible (tweakable markup, different markup engines, different storage backends, etc.).

(another aside)

Bill Kleb from Langley just asked for help getting Ruby to run on the IA64 architecture.

Tycho: A Proposed Ruby-based PIM (Hal Fulton)

Hal talks about his implementation of a Personal Information Manager inspired by Info Select (a.k.a. Tornado). Tycho looks like a rather interesting way to organize information. The executable node feature could do some really interesting things (I’m thinking of a contact list that could dial your phone for you … Ok, that’s lame, but you get the idea)

Pickaxe II

Woohoo! Time to hand out the PickAxe II books.

Hacking Ruby (Paul Brannon)

Paul shares some ideas about hacking ruby code … i.e. messing around with Ruby internals, changing the meaning of built-in functions and classes, and generally having fun.

Alph (Rich Kilmer)

         In Xanadu did Kubla Khan
      A stately pleasure dome decree
    Where Alph, the sacred river, ran
    Through caverns measureless to man
           Down to a sunless sea.

Alph is a Ruby/Flash bridge allowing you to write Ruby code to control a flash application. Now that sounds simple, but there are really "interesting" hoop Rich had to jump through to get here.

Rich always thinks big. MacroMedia’s new license scheme for the layout managers makes it impossible to use layout managers with Rich’s scheme (without paying a lot of money). So, Rich is thinking about implementing an open source component library to run on the Flash VM. (note to self: Never piss off Rich)

After Conference Activities …

The formal part of the conference was over around 9:30 and we had to vacate the meeting room so that the hotel could lock it up. A large fraction of the conference attendees drifted into the hotel lobby and claimed any spot that was near a power out to continue talking and hacking. Here’s a quick rundown on some of the mini-gatherings:

• Charlie Mills was helping Bill Kleb get Ruby compiled for the IA64 archtecture. Charlie is the fellow who helped Rich Kilmer and Chad Fowler with their DNSSD service wrapper at OSCON this year. It looked like Bill and Charlie had some success by disabling optimization on the C compiler.
• At least on person was working on their presentation for the next day.
• There was a fairly large group talking to Charles L. Perkins regarding the history of Smalltalk. Charles was involved with the early Xerox Parc Place developers and had some good inside stories about the early days of Smalltalk. Later when I dropped by it sounded as if they had moved past Smalltalk history and were discussing some of the capabilities of Prolog.
• Right next to the Smalltalk history group was another cluster of folks watching as David Heinemeier Hansson helped Jim Freeze through a tutorial on Rails. I’ve used Rails a little bit and am very impressed with the framework. When I dropped by, Jim had just got a login screen working for the demo weblog.
• Chad Fowler was helping Shashank Date work on Gemifying some of the windows tools that Shashank is planning on releasing. This is where I landed for a while. By the end of the evening, we had Shashank’s WxRuby application running as a gem.

Oh, and by the way, it looks like Genx4R is the 100th ruby app/library to be packaged as a Gem.

(More Ruby Fun tomorrow)

• Feedback

If we hit 100 before my talk tomorrow, I will add a mention of that Gem to the presentation (how about that for motivation).

• Feedback

For example, if I wish to link to http://onestepback.org on a wiki page, then I must spell the link as HTTP://onestepback.org. Otherwise the updated page will be rejected.

Since the wiki spammers currently use lower case for "http", their page updates are rejected. Now this will only work until the spammer catch on and start uppercasing the HTTP. As long as the number of sites that enforce this rule is small, it should be a while before they catch on (one hopes).

Since I have implemented this patch a week ago, I have had only one instance of spamming. Yes, the spammer used an upper case HTTP. I don’t know if that particular spammer always uses upper case, or just responded intelligently to my error message. But that hasn’t been repeated. Like I say, I’m cautiosly optimistic.

You can find the patch here:

• http://onestepback.org/packages/usemod_antispam.patch

The patch was created against version 1.0 of UseMod wiki.

By posting this, I’ve (probably) increased the number of sites using this anti-spam technique and have brought the day closer to when the spammers figure it out. Oh, well. We will worry about that when it happens.

• Feedback

One of the most important lessons I have ever learned as a software developer is to keep things simple. It’s also one of the hardest lessons to remember, because as programmers, we revel in the complex. Sometimes I am forced to reconsider designs where I let my love of complexity override my good sense for simplicity.

Revisiting Builder

However, as I was using, I discovered a rather annoying feature. If you recall, builders depended on the method_missing feature of Ruby to implement arbitrary XML tags on the fly. But, in order for code like this …

   builder.p { em("Hello World") }

to work, the em message must be sent to the builder object. Normally unadorned messages are sent to self. However, the builder object evaluated its block in a special way to hijack the value of self to point to itself.

It is really cool that we just need to mention the tag name and it automatically gets generated. But there is a downside. Suppose we replace the literal "Hello World" with a method called greet that dynamically determines the proper form of greeting. Now the code looks like this…

  builder.p { em(greet) }   # greet is a method

Now, not only em, but also greet gets sent to the builder. This is wrong, greet is a method defined on the current object, not the builder. To get around this, we must save the value of self outside the block and make it available under a different name. Perhaps like this…

  s = self
  builder.p { em(s.greet) }

As I was using builder I notice I was doing the s = self step on almost everytime I used a builder. And when I forget to use the s, I would get weird bugs in my HTML output.

Clearly I was being too clever (in my defense, I just copied the Groovy design for their builders). So I fixed the builder to use normal blocks with normal evaluation and the number of accidental bugs went way down. The greet example now reads like this under the new version of builder:

  builder.p { builder.em(greet) }

Now, since is it awkward to keep mentioning the builder name over and over, it would be nice to have a shortcut. Hence builders pass themselves as a parameter to the blocks. This gives us the opportunity to use a shorter name, but only with in the block. Again, the greet example is

  builder.p { |xml|  xml.em(greet) }

(The shorter name isn’t a big advantage here, but is a big convenience when many tags are created.)

So, it gets back to that old adage: KISS — Keep It Simple Stupid!

Postscript …

Builder is availble as a gem. Version 1.0.0 has the new, simpler interface. Because Builder is a gem, you can install both versions and use either, as long as you don’t mix their usage in a single application. To use the new version (after installing), just say

  require_gem 'builder', '~> 1.0'

This allows you to use any version greater than 1.0 but less that 2.0. To use the old interface, say …

  require_gem 'builder', '~> 0.1'

This allows any version 0.1 or later, but rejects version 1.0 and up. The ~> operator is called the Pessimistic version constraint is is helpful when versions of software have incompatible interfaces. The RubyGems wiki has more information about pessimistic version constraint and about versioning policies.

• Feedback

Builder Objects

Sometimes you get good ideas from other languages.

The basic idea is that you create a builder object and then send it messages. It responds to the messages by building up a data structure based on those messages.

Ack, it’s easy to see it in action than to describe it. For example, the following code …

  builder = Builder::XmlMarkup.new("", 2)
  puts builder.person {
    name("jim")
    phone("555-1234", "local"=>"yes")
    address("Cincinnati")
  }

will print …

  <person>
    <name>jim</name>
    <phone local="yes">555-1234</phone>
    <address>Cincinnati</address>
  </person>

So, an XML Markup object produces XML markup. Not very surprising until you think about the methods send to the builder. Where is the person method defined? Or the name method?

Actually, they are not defined anywhere. Instead we have defined a generic method_missing method and handles any undefined method and adds the name of the method to the XML markup we are building. In addition we use code blocks to capture the nested nature of the XML. The result is a very natural way to programmatically generate XML markup.

And it goes beyond just markup. If you use Bulder::XmlEvents instead of Builder::XmlMarkup, the same syntax will generate SAX-like events instead of markup. Or you can use a DOM builder to generate a DOM object tree (I haven’t implemented the DOM version, but it should be straightforward).

There are a couple of "gotchas" with this approach that you should be aware of …

• Within the builder code blocks, any method call with an implicit object target needs to be sent to our builder. To achieve this, the code blocks are evaluated with instance_eval which changes the value of self to be the builder. This is OK until you want to call a method in the calling object. Since self is no longer the calling object, you have to explicitly provide the caller. Builders make this easy by setting the +@self+ instance variable to the caller.
• What happens when you need an XML tag that has the same name as an existing method name (e.g. id )? The builder objects handle this by inheriting from BlankSlate. In addition, all the implementation methods in a builder begin with an underscore, which makes them unlikely candidates for XML tags.

Because Builder objects lack the normal methods that most objects have makes working with them rather interesting. Consider the following irb session where we create a builder object and let irb try to display it (by sending it an inspect message):

    >> x = Builder::XmlMarkup.new
    => <inspect/>
    >> x
    => <inspect/><inspect/>
    >> x.to_s
    => "<inspect/><inspect/><to_s/>"
    >> x.methods
    => "<inspect/><inspect/><to_s/><methods/>"
    >> x + 5
    => "<inspect/><inspect/><to_s/><methods/><+>5</+>"
    >> x
    => <inspect/><inspect/><to_s/><methods/><+>5</+><inspect/>

Every time we send a message to the builder it records the name of the message. In a way, the builder has become a trace object, recording all the messages send to it. Weird.

Finally, consider this last example. Suppose we have a method that uses a builder to generate an RSS feed. Here is the method in part ..

  def generate_rss(builder, a_title, a_link, items)
    builder.rss("version" => "0.91") {
      channel {
        title a_title
        link  a_link
        # ... code missing ...
        items.each do |it|
          item {
           title it.title
           link  it.link
           description it.description
          }
        end
      }
    }
  end

Now a single method (generate_rss) can generate XML markup text, a DOM tree or a series of SAX events, all depending on what kind of builder object you pass to the function. That’s slightly cool.

As I mentioned, I got this idea from the Groovy language. Groovy has some other builders as well. For example there is an Ant task builder that integrates with ant. It is a very flexible technique that really shows off the power of a dynamic language.

Note: You can find the Builder object code in the RubyGem builder-0.1.1.gem available on the RubyGem server on RubyForge.

• Feedback

This is the first hand-built RSS feed I’ve put together, so let me know if I’ve screwed something up.

By the way, the idea from the feed came from the Dave's Article at the Pragmatic Automation web site

• Feedback

A couple of themes emerged from the conference. Aspect Oriented Programming may finally be coming of age. I first heard of AOP about 4 years ago. This year, there seemed to be more substance behind the buzz. We shall see.

Another theme was the the strong belief among the speakers that although Groovy is still very much in its infancy, it has a strong possibility become very significant in the next few years. If you haven’t heard of Groovy, it is a dynamic scripting language built on top of the JVM. Unlike other JVM languages such as Jython and JRuby, Groovy is designed to work closely with Java and especially the Java libraries. A brief look at Groovy reveals a lot of similarities with Ruby. I’ll be looking at Groovy in more detail.

I’ve got a couple ideas for blog entries inspired by the conference and I’ll post them here in time.

The program agenda is looking pretty good. I’m talking about RubyGems this year (what else!). I’m especially excited to see that David Heinemeier Hansson will be there and he will be talking about Ruby on Rails which has been getting a lot of air time recently.

The Conference is relatively inexpensive (only $200 for the conference fees) and it’s a great time to meet a lot of Rubyists all at once. The conference is in the Washington DC area (Chantilly, VA), so it is accessible to a large portion of the east coast.

If you are at all interested in Ruby, I urge to to come and meet with us! You can register here.

Update!

It has just been announced that Brad Cox, the inventor of Objective-C will be giving the Keynote speech at the conference.

• Feedback

It turns out that she is featured on the local school district's web site where she is a library aide. The picture was taken during one of the school’s book promotions. (Helen is the one dressed up as the Cat-in-the-Hat.)

Here’s the picture …

I really like the book. I’m a big believer in automating all that I can, that is part of the motivation behind the creation of Rake. Mike provides a lot of great ideas and I can’t wait to try them out. (BTW, Rake gets a footnote mention on page 40, Woo Hoo!).

The book is targeted at the mainstream Java audience, so it talks a lot about ant and Cruise Control. Ruby and non-Java scripting languages are mentioned only in passing, but this is reasonable given the size and scope of the book. Mike says that he wants to encourage non-Java scripting and that the www.pragmaticautomation.com website will feature Ruby whenever he can.

And true to his word, today he posted a stakeout script that runs his unit tests whenever a file changes. Check it out.

Oh, and check out the book too.

• Feedback