RubyConf 2004, Day 2
The second day started off with Patrick May talking about his web framework Narf. Narf is a fairly low-level library that offers a lot of convenience methods for handling CGI responses and requests. It has test methods that relieve you of the need to parse HTML yourself, and it allows you to submit a form in your test code and check the results. It also works with mod_ruby, FastCGI, and Webrick, and comes with a solid test suite that will make it easy to plug into even more servers in the future.
Patrick's talk was a sort of grab-bag of topics. He talked about using a tarpit to waste the time of wiki spammers on the wiki for his art collective Open Ground. Basically you make spammers think that their edits are happening, but don't show those edits to anybody else. He also pointed people to HTMLArea, which takes a normal textarea and makes it into a rich-client editing tool.
One side note: I'd seen a rough version of this talk in August at Ruby NYC, and I think it's safe to say that one advantage of having a local Ruby user's group is getting a chance to practice out your talk with a much smaller group before the big international conference.
Next, James Britt talked about ruby-doc.org, going over its history and possible improvements for the future. He's trying to think of the best way to do less work in making the archives and resources searchable, and this led to a lot of discussion about how to harness the efforts of other people—readers, doc writers—to help ease the categorization process. Also, he said that one of the best things about PHP is the way that individuals can attach comments to individual nodes of the documentation, and that he'll be working on stealing that.
David Hansson finished up the troika of web talks by talking about Ruby on Rails. Obviously there's a lot of interest in Rails, and this may have been the most anticipated talk of the conference. Mostly David's talk was less about specific examples and more about philosophy of designing Rails and dealing with what seems to be a growing community of Rails users. I was a little disappointed to hear that ActiveRecord isn't really designed for people to use with pre-existing data. 99% of the work that's out there is legacy, and if I only accepted work where I could control the database schema, I'd be bankrupt. But then, I suppose that's why I wrote Lafcadio, and ActiveRecord seems to work fine for lots of people so maybe I oughta just shet my mouth.
When we broke for lunch, David Black announced that with the formation of Ruby Central as a full-on non-profit agency, the wheels are turning to allow programmers to get paid for work on certain Ruby libraries. Also, yesterday's challenge to help NASA compile Ruby on an IA64 was met by Charlie Mills.
Jim Weirich talked about RubyGems next. Yesterday, he had announced that there were 99 libraries with gems on Rubyforge, and that if there was a 100th by the time he gave his presentation he'd mention it: The 100th lib is GenX4r, a wrapper for Tim Bray's XML generation library GenX. Considering that RubyGems was created a year ago at RubyConf 2003, having 100 libraries out in the format is a pretty impressive number.
One killer feature of RubyGems is that when you install executables, RubyGems actually creates a fake executable that dispatches to the real version—and which can switch at runtime between versions through a command-line option. Another feature allows you to require libraries by version number, so you can say that an application requires, for example, Rails 0.9 or greater. And there's this funny version number comparison operator ~>, which means "greater than but not too much greater than". There isn't a lot of consistency across the meaning of version numbers, so I'll be curious to see how this works out in practice.
Jim also dropped some good hints for using RubyGems effectively, particularly if you're writing a large application. Keeping all your external dependencies in one file will reduce the overall dependency on RubyGems. And once you've done that, you should think about organizing those dependencies to make it easier to allow future users to deal with problems regarding version resolution.
There are also a few Gem viewers coming down the pipe: Rich Kilmer is working on a Windows GUI-based viewer, and Paul Duncan is working on a similar project using GTK.
Koichi Sasada spoke next, discussing his efforts to write YARV, which might become the next Ruby VM. His English is fairly poor, but he still managed to communicate a lot of information and do it with a lot of humor as well. He showed a lot of benchmarked samples comparing YARV with the current VM, and in certain cases the speed improvement was dramatic.
Afterward Nathaniel Talbott talked about his plans for the second version of test/unit, the standard test library for Ruby. He showed a pretty cool way to embed tests in production classes so that these tests can be pulled out automatically to provide examples for RDoc, and a bunch of convenience methods to allow you to do even less typing in setting up your Ruby test cases. Boy, we Rubyists sure hate typing. He also pointed out how much testing there is in the Ruby community: Almost all the libraries out there come bundled with tests.
Then the internet went down, which made me cranky and irrational. I like to think I'm quite charming that way.
Shashank Date pre-announced the upcoming Artima Rubyzine, which will be an online journal for Ruby programmers, complete with an ad sales department and (some) money being paid to writers and editors. He didn't mention whether or not writing for Rubyzine will get you the sexy ladies, but I think that pretty much goes without saying.
After dinner, Brad Cox, the inventor of Objective C, gave the keynote. The first part of his talk was about the history of Objective C, which he said was never the goal itself. Instead, the language was created while looking for ways that people could work in collaboration instead of in isolation.
The second part of Brad's talk was a pretty controversial proposal to meter software libraries so that clients would pay for using the software, not for buying it. The impetus for this idea was the notion that quality would be higher if a programmer's economic self-interest was more closely tied up with the self-interest of his customers. Personally, I agree that software quality is a big problem, but Brad's proposal was close enough to things like DRM that it ended up spurring this avalanche of a discussion about intellectual property, the digital commons, Lawrence Lessig, and everything else.
Now it's almost 1 a.m., and there are about 20 of us in the lobby, chatting and typing away. There's a security guard here, too, which makes me think that we should negotiate a discount with the hotel every year. We can just say "If you put WiFi in the lobby, you won't need a security guard, because anybody who's looking for trouble at 1 a.m. will see a lobby full of people and go somewhere else." (That's a little Jane Jacobs for those city planners among you. Did you like that? Sure you did.)