The second day (it seems like I've been here longer) of the conference was very busy.

Refactoring No Clergy

Two to five musicians play music given by a score on a web browser. The audience also has web browsers and can suggest what they would like to hear in the piece. Using Markovian Transformations, the next page is generated for the musicians to play.

Kevin Baird sadly did not have any samples of the music generated from this, but will hopefully put some up soon.

Embedding Ruby into a Robotic Marine Laboratory

MBARI is using Ruby to control their marine laboratory (a 5' cylinder). The original aim of the project was to identify harmful algae blooms. They do this by analysing chemical reactions against samples of water. The lab has to stay in position for 6 months at a time, so power is a concern too.

Brent Roman talked about how they were originally using a language they created themselves, but switched over to ruby as more probes (analysis of specific organisms) were needed. Ruby was chosen as non-programmers (scientists) would be the ones writing probes.

As the hardware is unique, Brent wrote a system similar to mocks to allow him to continue to develop the system without the laboratory being there. Ruby 1.6.8 stripped of many standard libraries was put on to a 16MB flash card, which controls everything from servos to the probes. 2MB Linux kernel, 500kB Ruby Core, 1.6MB Native code libraries.

Apparently NASA are also interested in this technology too.

PDF::Writer

Austin Ziegler presented PDF::Writer. Basically it allows you to generate PDF documents specified in Ruby. It can already import bitmapped graphics, and vector graphics are being put into version 1.2.

Austin was showing us where he wanted the project to go. The tidying up of how you specify what goes into your PDF. Perhaps he will be influenced by Jim's DSL talk.

Polishing Ruby: Power Tools and Toys

Ryan Davis gave a very slick presentation of various tools which came out of MetaRuby.

ZenTest looks like something most people would want to use. It generates missing tests from existing classes. It also includes a diff tool which makes it easier to locate problem code.

RubyInLine allows you to write C functions directly in your Ruby code. Thre is no need to compile anything, and technically you are not limited to C.

ParseTree extracts the Ruby AST and returns a sexp (s-expression). It also allows visualization of your AST which can give you better understanding of your code.

Ruby2C transforms your Ruby into C. This can be used to help optimize, or to obfuscate.

Zen Hacks is a miscellaneous collection of tools. Most make the author wince. These include ruby2ruby, auto refactoring, ruby obfuscator, zenprofile, and zenoptimize.

Creating Domain Specific Languages in Ruby

Jim Weirich started off showing siteswap notation, followed by Rubik's cude solving notation, and finally guitar TABlature. All these were examples of DSLs (Domain Specific Languages). He then proceeded to show that DSL are designed for non-programmers who understand their domain space.

There are various types of DSL: External: Awk, Sed, Yacc Work Bench: PowerTools Embedded: A subset of an existing language to create the DSL

Jim's experience is from creating Rake. He started out by scribbling down how he saw the DSL working. James Britt's method was mentioned: Write by exception - write it how you want to, then hack it until it is Ruby.

Using methodmissing, constmissing, hooks into method_added it is possible to create your DSL. A key part is using BlankState which will remove all unnecessary Object methods. Perhaps this will become part of RubyCore.

I am quite keen on getting a list together of DSLs specified in Ruby.

System Testing in Ruby with Systir

Karlin Fox started off showing a test which went through and filled out web forms using Watir. Systir suggests story driven development. Your user will write their own tests in a DSL you specify with them.

I like the look of this, but am skeptical about the likelihood of a client writing their own tests. I can see them writing specification type tests which allow you to see if your application gives them what they requested, but I don't see clients writing tests for failing conditions.

Other things on the Radar

Mike Clark's learning tests - I found this interesting and actually did it with ActiveRecord without realising it. One colleague wondered why I had written tests which just confirmed ActiveRecord was working. Part of writing the tests showed me how certain things worked, so I think was worth it.

Selenium is similiar to Watir, except that it doesn't rely on IE. It will run on Linux and MacOSX.

Komodo is an ActiveState product which is now has alpha Ruby support. I happened to sit next to Eric Promislow who showed me how it worked. The Ruby debugger is built in, and allows you to set breakpoints. I liked it and will be giving it a more thorough test. One thing I forgot to ask was whether it has vim keybindings.