- Eric Hodel gave an interesting presentation on the internals of Borges (a framework that uses continuations to make writing web applications much easier). He discussed the code porting tool he wrote to port Seaside from Smalltalk to Ruby and turn it into Borges. He also gave a demo of sushiNet (which is pretty much a direct port of the Smalltalk demo of the same name). He also discussed some of the more difficult problems in writing a web app, such as bookmarking and backtracking, and explained how Borges deals with those problems behind the scenes. - James Britt gave a summary of the more popular XML processing tools available for Ruby. A tool I found particularly interesting was RQDS, which is a command-line tool for querying various sources (such as a SQL database) and producing XML output (which could then be translated into HTML for a webpage). Other, more general-purpose tools included numerous parsers, validators, and serializers. - Francis Hwang gave a talk on Lafcadio, a library for simplifying interfacing with MySQL. He claimed that adding this layer of abstraction greatly simplified his unit testing; he had an entire mock object store that he could use in his unit tests. Lafcadio does not work with PostgreSQL, but Francis didn't think it should be too hard. Two other libraries that provide similar functionality include Vapor (which is like Lafcadio but works with PostgreSQL) and criteria. A discussion followed the presentation on some of the difficulties with using Ruby idioms when making SQL queries. - Steve Tuckner talked about how he used Ruby for commercial application development. His company is rolling out a new product (a "fax server in a box"), and they needed a GUI for it. Steve discussed some of the social problems (how do I convince my boss/co-workers to use Ruby) as well as some of the technical problems. He also communicated to us some of the lessons he learned from the experience: 1) Do more research up front to mitigate panics, 2) take more time to build scaffolding for testing, and 3) don't choose Ruby as a solution to a problem just because it is fun. - Jack Herrington (author of "Code Generation in Action") talked about using Ruby to generate code for C++ or Java (though the talk was more about code generators in general than code generation using Ruby). He discussed some of the various types of code generators (code mungers, inline code expanders, mixed code generators, model-driven generators, tier generators, and particl class generators), and explained their good points and bad points. He explained that a good code generator is multi-layered, keeps system-specifics to a minimum, separates depolyment and model specifics, uses templates, and creates output that can be used to feed other generators further downstream. He also talked about problems development groups have when using generators (such as whiteboard hell, maintenance of the generator, etc.). - On Friday we had a roundtable with Matz where we were allowed to ask Matz questions, and he could answer. We discussed having a formal specification for the Ruby language and how that would affect/impede development of the language and how it would improve stability of the language. I asked about Matz's plans for ensuring backward-compatibility (or at least a well-defined path for moving code from Ruby 1.8 to Ruby 2.0). His response was very wise: we want to change the language to make it better, so we must change as much as possible in Ruby 2.0 so that it will be around for a long time. Ruby 1.8 will stay Ruby 1.8 forever, so we can continue to use it without worrying about compatibilty versions between minor revisions of Ruby 1.8. - Shashank Date gave a talk on using Ruby to write code for the Lego Mindstorms RCX brick. He discussed the two models for writing for the brick: downloading a program to the brick, and directly controlling the brick through the IR interface as the program is running. His son Rutvik gave a demo of how to use the software that came with the Mindstorms kit to write code for the robot he built, and then Shashank gave a demo of how he used Ruby to directly control the brick over the IR interface. - David Alan Black gave a talk on the implications of writing and releasing a "quasi-framework" to the public. He talked about a project he is starting at Seton Hall University in which students and teachers can have discussions online through a "one-way mirror". His project uses a quasi-framework he wrote that he explained could be useful to people as an idea or concept, but communicating that idea to other people is a challenge, since the Ruby world lacks a good forum for such ideas. A discussion followed in which the audience through out some of their ideas about the topic. - Michael Granger talked about his MUES framework. MUES is the "Multi-User Environment Server" whose purpose is to be a framework for FaerieMUD. He made heavy use of the Gang of Four book and Design Patterns in Communication Software in designing the framework, and had his own reactor; event subsystem complete with thread pools, event queues, and dispatcher; IO subsystem with various transport layers and filters; and a nice object-oriented system for defining environments, contexts, participants, and roles within a virtual world. - Nathaniel Talbott (author of the Test::Unit library which comes with Ruby 1.8) explored writing secure software using Ruby. He discussed why Ruby works well in secure software, as well as tricks he used to make his Ruby code more secure. He also discussed what real security is and why the burden of security cannot lie entirely with the software developers. - Brett Pettichord talked about one of the many classes he teaches in which he teaches Ruby as a tool for testing web software. Most web testers test pages manually or at the very best use a very rudimentary scripting languages for scripting their tests. He showed how he uses the IE controller script from Chris Morris to control IE from inside IRB, then to write unit tests using the same techniques. The advantage of testing webpages this way is that the Javascript on the page can be tested in addition to just the CGI scripts that are running on the server side. - Jim Freeze gave a talk titled "introducing Ruby to the corporate world." He talked about some of the hoops he has had to jump through to get Ruby accepted in his company and some of the techical issues with deploying Ruby libraries and extensions in a heterogenous environment. He gave a list of "best practices" which among other things outlined how Ruby libraries should be structured. - Matz gave the keynote address in which he talked about his visions for Ruby 1.9 and Ruby 2.0 (Rite). He talked about the development path for Ruby 2.0 and about new features that Ruby 2.0 will have (many oohs and aahs came as we saw some of these features). He also explained his desire to see the RCR (Ruby Change Request) process improved. He requested that in the next few months we submit RCRs that may change/improve Ruby drastically, but mandated a format that all these RCRs must follow (in the past, RCRs have been freeform, resulting in requests that are not very well thought out). At the end of the talk we got a quote from Matz in true Matz style: "Coding in Ruby is a joy, and coding in C is like a puzzle. I like puzzles." Links that may be of interest: - http://www.rubyist.net/~matz/slides/rc2003/ - http://www.rubygarden.org/ruby?Rite - Jim Weirich gave a tutorial on how to use Rake (a Ruby replacement for Make). Rakefiles are Ruby scripts in their own right, and use special methods to define targets and dependencies. He discussed tasks, file tasks (special tasks used to build files), and rules (like file tasks but do pattern matching). Rake is not a complete replacement for Make (there's no parallel Rake and Rake can't read standard Makefiles), but all in all it looked like a very clean build system. - Hal Fulton explained to us his vision for a "refactoring framework". He talked about the library he is developing which allows users to write Ruby scripts to manipulate a scintilla buffer; these scripts can move and manipulate code to produce roughly equivalent code that looks different from the original. These scripts, or "refactorings" can be shared between Ruby users in the community. Eventually the system will become part of FreeRIDE, but for now it is a standalone system. - Rich Kilmer had the privelege of giving the last talk of the conference, a walk-through of the Ruby Java Debug Wire Protocol. He used it in the DARPA UltraLog project to build a system in which a single Ruby script controls over 300 Java virtual machines across the network. Rich also gave a demonstration of RubyGems, a new CPAN-like packaging system for Ruby (so new, in fact, that it was just started Friday evening by a group of nutty Ruby programmers, but Rich was nevertheless able to demo creation and installation of a gem, as well as dependency checking at load time). Rich also showed off Alph, a Ruby library to generate Flash interfaces.