Day Two: Saturday, 15 November 2003
If there was a theme for the day's presentations, it could have been "using Ruby." Presenters described several projects that use Ruby and some of the decisions you have to make when developing (in Ruby in particular). A couple of presentations were useful to those of us trying to get Ruby into a corporate environment. Matz's keynote speech was about Ruby the language.
One thing I had barely registered the previous day, but which became increasingly apparent to me, was the intersection between the Ruby community and people using Extreme Programming (XP) techniques to get things done. Every time there was a break, it seemed that pairs or trios would form around a couple of laptops, and "stuff" would happen. It was amazing to see how productive people could be with Ruby — ideas mentioned in one presentation would be turned in to working code in minutes, it seemed.
The first couple of presentations described projects that use Ruby.
The presentation I enjoyed the most was Shashank Date and his son Rutvik demonstrating Lego® Mindstorms™ and its development environment on a Windows PC. Shashank wanted to see if he could make it as easy to program Mindstorms in Ruby as from the Lego IDE. He also wanted to let people develop and test their code for the robot on a PC without an IR tower attached. (The IR tower is an infrared communications tower used to download bytecode to the robot.)
Shashank's motivations for the project were to learn and have fun, knowing that mistakes along the way were just part of the process. The project is still a work in progress, but Shashank was able to use components from the Ruby distribution and Application Archive to build a system that talked to Windows to control the IR tower, a server layer on top of that to implement the protocol used by the robot, and then a client layer on top of that to generate the bytecode for the user.
drb was used to distribute the client and server.
Shashank's demonstration was a simple program that drove the robot forward until it ran off the edge of a dark pad, and then reversed direction until it ran into something, and then reversed direction again. The robot has sensors that let the program look at the brightness of the ground or see if it has run into something. The Ruby client program sends commands to the robot and reads the sensors immediately. In this demo, it didn't download a program to the robot and then let the robot run by itself; the demo was distributed, and it worked well. Ruby components, such as
drb, let Shashank and Rutvik concentrate on their problem without getting in the way.
Michael Granger's presentation showed how Ruby can be used to build a more complex system, in this case a multi-user environment server, or MUES. This is a reasonably complex design that is intended to provide someone with the barest skeleton of a MUES; a developer can specialize from this general framework and implement the stuff they want, unencumbered by the framework author's ideas. If you wanted to implement a server for a multi-user dungeon, then you need to specify what rooms are, for example. This showcased Ruby implementing a system with multiple threads, asynchronous events, and multiple subsystems fleshing out a moderately complex design.
A couple of the presentations were by people using Ruby to implement projects, and they talked about the processes they went through. The processes and problems were by no means special to developing projects in Ruby, but the differences between languages can affect the trade-offs we make.
David Black talked about what to do when you get the feeling that something in your code might be worth turning in to a framework or library. He was developing (yet another) small web application and discovered an abstraction he thought might be generally useful in similar contexts. There was lively audience participation, and the discussions, questions, and answers were illuminating.
The issues discussed included whether Ruby's ease of implementation makes documenting the unique ideas in a framework important, as that lets people reuse concepts rather than code, and how many times do you have to reuse a piece of code until you have discovered what its core features really are, allowing you to make a fluff-free framework.
Nathaniel Talbott talked about his voyage of discovery into building secure applications with Ruby. Initially he focused on using OpenSSL as a way of securing communications, but soon realized that security was much more than just a few tactics and techniques. There wasn't much-Ruby specific here; security transcends the implementation language.
Brett Pettichord presented a quick overview of his use of Ruby in a course for software testers. Ruby is used here as a versatile tool. Brett's approach is to get his students using Ruby as quickly as possible, using
irb and interactive examples. Brett has developed a library to test web applications by using the automation interface to Internet Explorer. His students use this from
irb to interact with the browser's DOM almost transparently. It is a simple step to get from interactive commands to a small script that contains the commands to be sent to the browser and examines the resulting DOM to see if the expected effect has been achieved. Ruby is simple enough to be picked up quickly and expressive enough to allow the testers to express what they want to do without fighting the language.
irb is an interactive Ruby shell that can be used for testing code snippets. This is described along with the Ruby debugger in the "When Trouble Strikes" section of the Programming Ruby book.
Jim Freeze's talk, Introducing Ruby to the Corporate World, seemed a logical follow on to Brett's talk. If you have a great idea about how Ruby might be a great tool with which to do something new or how it might be a replacement for some "legacy" scripting languages (they know who they are :-)), then you might be interested in Jim's experience of getting Ruby accepted in a corporate environment.
Corporate managers are interested in the value of this new technology to the company, not arcane language features. You need to be honest about what can be achieved and take the initiative; Jim used Ruby's scalability, reusability, and maintainability as rationale for its introduction, compared it to other languages in use in his industry (Tcl/Tk and Perl), and constructed a good case for Ruby's introduction.
Matz gave the much anticipated speech after dinner. The talk was about where Ruby is going and the order in which various improvements and changes are planned. We have a lot to look forward to in the near future. Ruby will be changed and improved, but "the Ruby way" will still be "the Ruby way." The future looks exciting and interesting.
There was an animated and entertaining question-and-answer session. Matz asked for, and received, feedback on the changes he was proposing for Ruby. My favorite answer of the night was after Matz was asked if he preferred coding in C or Ruby; after a brief pause, he said the liked them both — coding in Ruby is a joy, and coding in C is a puzzle.
People have fun with Ruby, and people keep on saying it makes them productive.
The modules that come as standard with Ruby 1.8 and the modules available on the RAA allow people to start projects that are vital to their companies. I saw that Ruby is being used in big corporations, and people are arguing convincingly that Ruby is scalable, maintainable, and fun.
As a personal aside, it's great to have a conference at the stage where there are enough good presentations to fill the program, but not so many that you have to pick tracks and inevitably miss stuff.