The third international Ruby Conference ran from November 14th to 16th in Austin, Texas. It brought together Yukihiro "Matz" Matsumoto, the creator of Ruby, and Ruby users from many countries and disciplines to discuss the state of Ruby and to let us hear what Matz has in mind for the immediate (and not-so-immediate) future in the Ruby world, as the language matures. If you want to discover more about Ruby, the Ruby Home Page is a good place to start, and the next places to visit are the community web site at Ruby Garden and the Pragmatic Programmers' collection of Ruby links.
For the past couple of years, Ruby seems to have been popping up all over the place. The conference gave me a chance to get an idea of who's actually using Ruby and what they are doing with it, and put some faces to names.
The comp.lang.ruby newsgroup is the main forum for discussing Ruby. It's gatewayed to a mailing list, and many of the contributors to the newsgroup are also active on the #ruby-lang IRC channel on irc.freenode.net.
Ruby Central Inc. organized the conference. This was the first Ruby conference separate from OOPSLA, and it was a pleasant surprise to see that there were around 50 attendees, not significantly different from the previous year. If you have ever browsed the comp.lang.ruby newsgroup, then many of the names of conference attendees would be familiar. I suspect that there will be quite a few blog entries from the conference.
Some of the major events of 2003 for Ruby were its tenth birthday, the release of Ruby 1.8.0 in August, and the first European Ruby Conference. Ruby 1.8.0 contains several improvements in the core language over 1.6.x, as well as the inclusion of some of the more popular packages available from the Ruby Application Archive (RAA). Rubyforge, a site for hosting Ruby-based projects, was launched in July 2003.
The day started with breakfast and David Black's introduction. David and Chad Fowler are amongst the people who put a lot of their time and effort into realizing the conference as Ruby Central.
Over the course of the day, there were five presentations, and a roundtable with Matz after the evening meal. I'm not going to give a blow-by-blow account of the talks; I expect the presentations will be available online somewhere.
In one presentation, Steve Tuckner described the benefits of using Ruby for a commercial product, as well as the difficulties he encountered implementing a Windows application that talked to custom hardware. In another presentation, Jack Harrington talked about code generation. His book, Code Generation in Action, uses Ruby as a language to demonstrate the construction of programs that write programs.
There were presentations by the developers of libraries that can help people working on projects that need a web application framework (Borges, by Eric Hodel) or an object-relational mapping layer (Lafcadio, by Francis Hwang). Both of these are in an early stage of development.
James Britt presented a survey of the XML (and XML-related) libraries for Ruby programmers. Ruby 1.8 includes several useful XML libraries, such as Sean Russell's REXML.
The roundtable covered a variety of areas, from requests for a formal language specification to whether Matz was bored after ten years of developing Ruby. Fortunately, he's not. Some of the more serious topics raised were a desire to get more of the Japanese documentation translated into English, and the issue of how best to package Ruby extensions so that it is easy to install and remove them. Other questions ranged from possible speed optimizations in Ruby to how Matz planned to manage change in the language as more code uses it, and whether particular keywords should be deprecated. During the roundtable discussion at the end of the first day, Matz said that he would be talking about Ruby 2.0 and beyond the next day.
My impressions after the first day were very positive, as Ruby seems to be used in a variety of areas, and there are more modules and libraries becoming available each week.
It seems that people like Ruby because it makes them very productive. Several people commented that, after switching from another language that they used well, they thought that their productivity improved and that the maintainability of the code improved, too.
Ruby's character affects the way people use the language. For example, many of the XML libraries that aren't just wrappers around C or C++ libraries seem to implement a Rubyesque interface first, and then have facilities to use "gnarly" specs added so that, say, people familiar with DOM can be comfortable.
The people using Ruby in commercial environments suggested strategies for getting Ruby into an organization.
The mealtime discussions were interesting. Ruby developers wanted more documentation, especially of the libraries. People who had seen the No Fluff, Just Stuff symposiums were surprised how many times Ruby was mentioned by panelists at a Java event. Ruby evangelists were wondering what needs to happen to make Ruby more popular. Do we need more books or a couple of big applications to show that big Ruby projects work? Many people are quietly introducing Ruby to organizations formally, or as a tool that allows them to be more productive as consultants.
All in all, it was an interesting first day that allowed me to put faces to names, showed me the number of different types of people using Ruby. I looked forward to the next couple of days.
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.
Sunday was the final half-day of the Third International Ruby Conference. The three sessions focused on the applying Ruby as a tool.
Jim Wierich presented Rake, a Ruby
make-like utility, describing what it does and examples of its use. Jim wanted something like
make that was portable, easy to use, dynamic, and flexible. There were a couple of aspects of the talk that got my attention.
The first was yet another developer showing that he could be massively productive in Ruby, and that Ruby can pack a phenomenal amount of utility into a few lines of code. Jim characterized his first cut as being thirty minutes of work, which yielded about 70% of
make's useful functionality in about a page of code. A common theme through the talk was how "way too hard" turns into "not too hard" with a little thought, and then after thinking "just do it" the Ruby version seems to spring naturally into existence.
The second thing that struck me was how easily Jim's pseudocode turned into Ruby. Jim has a few years' experience writing software, and it was a joy to see him describe the way that powerful features could be implemented in relatively little, but extremely lucid, Ruby code. This was just another example of a developer's experience and Ruby's design "just working together."
Hal Fulton showed us the beginnings of code refactoring and code transformation support in the FreeRIDE project. FreeRIDE is an IDE implemented in Ruby, and Hal demonstrated the refactoring support being made available through the IDE's editing interface. The editing interface is based on the Scintilla editing component. (See also its Fox Toolkit incarnation and the FXRuby project.)
Rich Kilmer has been working on the DARPA Ultralog program. He presented his tools to use Ruby to do distributed system testing on a live system of Java agents. This was an impressive chunk of work, manually extracting the Java Debug Wire Protocol (JDWP) specification from HTML into Ruby metadata, and building on that to provide access to the Java Virtual Machine Debug Interface (JVMDI). This allows simple programmatic control of hundreds of Java agents, and allows their states to be analyzed and modified, and all of this done with about a 20,000-line Ruby framework.
A useful framework of this size shows Ruby scaling to larger projects, and would be impressive by itself, but Rich used the presentation to introduce two more things he's been working on.
The first was Alph, a GUI for Ruby that uses Macromedia's Flash player as the user interface, with Ruby controlling it over the network.
The second was the revealing of RubyGems, a way of managing Ruby add-on modules. The need for some kind of package management has been talked about since the first Ruby conference, and there had been much discussion in the past couple of years about this. Rich, Chad Fowler, and Jim Weirich decided to "just do it" in spare moments in the conference, and now they had working code to show.
I have liked Ruby ever since I first saw it, and I was pleasantly surprised at the soul of the Ruby community when I started using the comp.lang.ruby newsgroup to ask my usual newbie questions. Because the community seemed such a positive and talented group of people, I jumped at the chance of going to the Ruby conference. I was interested in both Ruby the language and the Ruby community.
It's clear that Matz is aware of Ruby's strengths and the areas where it can be changed for the better. People are successfully using the language for everything from one-liners to projects with tens of thousands of lines of code, and are finding modules in the distribution and on the Ruby Application Archive. The plans for Ruby 2 and Rite are a good sign of where we're going. Ruby 1.8 is a big step forward from 1.6, and the RAA seems to keep growing.
The community around Ruby is vital both in the sense that it sustains Ruby and that it is full of life. The Ruby Application Archive, Rubyforge, and the Ruby Garden site are active community sites. Ruby Central has allowed the Ruby Conference to bring people together, thanks to the hard work of David Alan Black and Chad Fowler.
It amazed me to see how productive people could be with Ruby; this was borne out time after time in the talks, and the creation of RubyGems over the weekend just rubbed it in.
I had a really great time people-watching at the conference, and soaking up the enthusiasm and delight that Ruby engenders. I'm eagerly awaiting details of next year's conference; if I can possibly be there, I will.
There was much typing going on at the conference, but lack of connectivity meant that people's blogs were not providing second-by-second coverage. If you want to get more of a flavor of the conference and the people there, here are some places where I expect coverage to appear:
Mike Stok works as a senior programmer at Exegenix developing products using open source software.
Return to ONLamp.com.
Copyright © 2009 O'Reilly Media, Inc.