RailsConfEurope, part 1
RailsConfEurope was not only my first Rails conference (although I did go to 37signals "Building of Basecamp" workshop) but, actually, my first professional conference event ever. Here are some highlights, in roughly chronological order:
Berlin By Train
It took us roughly 6 hours to get to Berlin by train from Utrecht. Which is not too bad: Google had estimated 8 hours. One of the nifty things about traveling by train, is that there are power stations on the train. When we weren't interested in staring at the beautiful scenery, we could watch movies on our laptops, with no worry about battery charge.
The schedule at this conference seemed a bit strange to me, with a slate of largely optional/tutorial sessions on Monday, it felt like it was lacking a "kick-off event", to start things and pull everyone together. The Berlin Ruby User Group put together a "bratwurst-on-rails" night on Sunday, and heroically filled this void. I was substantially impressed with how well it turned out! There was no shortage of brats, the beer was good, and the cupcakes were fantastic! What a great way to kick off the conference!
The New Berlin
Instead of going to the optional (and additional cost) tutorial sessions Monday, I went sight-seeing with Liz. It had been almost 10 years since I've been in Berlin, and it was amazing to see how much has changed since them. Although I'd spent a lot of time in Berlin before, I wasn't sure how I felt about the city. It had been a quirky destination spot for so long ("Come see the walled city!"), to then become a city under siege by construction equipment, to… what now?
For example, Potsdamer Platz used to be a destination for construction-site fans, it's now the site of an enormous "Sony Center", shopping mall, and theater complex. All over Berlin, there's a sensation of a city that's "all grown up" — it feels every bit the modern European metropolis today that it never quite managed before.
Also, the new (to me, anyway) Holocaust Memorial is astonishing. It's a seemingly simple design, with coffin-like blocks in rows across a wide square. As you walk in among the blocks, there's a trick of depth, and you actually begin to sink in as you walk, until they tower over your head (even mine!) It's hard to put into words, because the act of walking among the blocks is such a vital part of the experience, but it's simply phenomenal.
I also very much enjoyed the Pergamonmuseum – a museum of ancient Greek, Roman and Byzantine artifacts – and it's included Museum of Islamic Art. The Pergamon itself is enormous, but the Ishtar Gate is an experience.
Dave Thomas' Keynote: "Art"
Dave Thomas' keynote was interesting enough, but didn't strike me as very deep. Apparently, he wanted to do a talk about "Engineering" and play up the cultural stereotype of "Germans as Good Engineers", but swerved into a talk about the influence of Art, Artistry and Artisans on Software Development.
I did pick up a few interesting details:
- Everyone (I assume) has heard the (apocryphal) story of the Space Pen (US spends millions of dollars on a super-pen, Russians just use pencils). According to Dave (and Wikipedia backs him up) this isn't true: NASA was using pencils and the Fisher company privately financed the pen development and sold it to NASA at retail. The "lesson" of the apocryphal story is to avoid Functional Fixedness; Dave's point with the story is to sell something your client really needs.
- Dave's "Robot Camera" Story: So, this company has this Robot Camera Thing — it pans and zooms until it locates a face, then it takes a picture. They sell it to some Departments of Motor Vehicles, because they take lots of pictures. (Dave apparently worked on the database storing the pictures.) They run into some odd problems: citizens with grossly mismatched photos, even smiley faces on their driver's licenses! It seems the camera might fail to take a picture of Citizen #12 and capture an image of Citizen #13 instead, throwing off the pictures for the rest of the day, and that some DMV operators had figured out that the camera could be tricked into taking a picture of a Sharpie-drawn smiley-face. The "lesson"? Don't be too clever (I think?)
The general topic was a preview of Rails 2.0, and a general discussion of the influences shaping some of the decisions going on with the changes in the new version. I don't envy DHH much, here: it can't be easy to manage such a large, high-profile open source project, and I'm not saying I could do it any better, but…
Maybe it's just me, but I'm not all that thrilled by "previews of the new thing". I guess I'm as interested in the new shiny toy as the next guy, but I want tools that work, work now, and work as advertised. I'm not running Edge Rails on client projects, so I won't get (m)any of the new features until the official release, which may well be months from now. Oh well…
I might be the only one who thinks so, but it seems there's some conflict in how much community involvement DHH wants with Rails. On the one hand, it's long been clear that this is "opinionated software" — Rails is David's toolbox, and it's open source in the sense that we all get to use it. On the other hand, there's an obvious desire not to develop the sort of problems faced by closed, proprietary languages at Sun or Microsoft.
Examples: During Q&A, someone asked his opinion on merb : "wish they'd send patches, instead of starting another project". Later, different question: "Have you considered using de-centralized source control, such as git, the perception is they make patches easier to create?" Answer: "No, primarily because we want to discourage large patch sets." Other question: "I've been watching this bug for a year, any chance it'll make it into a release before 2.0?" Answer: "I've declared bankruptcy on all our old bugs, please re-submit under Report #12."
Oh, and no discussion at all about my pet peeve issue with Rails 2.0: all the "remove to plugin" business. (Why? Because, as far as I'm concerned, one of Rails' greatest strengths is consistency of approach by different developers. And the "it's all baked-in" argument, to boot. It seems to me that we're moving away from that rapidly. Oh well.)
Session 1: "Caching in a Multilanguage Environment" (omdb.org's Benjamin Krause)
Rails' page caching options are powerful tools for speed, but can be complicated when used in a multilingual environment. I have a client project that involves both issues, so I was very interested in this talk. Ben did a great job, highlighting the technical issues and presenting an overview of his solution. I particularly liked his use of mod-rewrite voodoo and a cookie to allow Apache to serve the cached page based on a browser's "Allow Language" headers. The slides include links to Ben's plugins for language-aware routing and caching. Plus, Ben resurrected the cache-test plugin, and modified it to work in his app's multilingual environment. Nice!
Session 2: "Meta-Magic in Rails" (Dr Nic Williams)
Nic is a funny guy, and he gave a funny talk to a packed room (with a dozen or more standing), with very little new information if you've ever done any meta-programming with Ruby before. Still, the finale was great: a method-missing hack that resolves your typos.
I suspect Nic Williams and Damian Conway would get along famously. Better yet, a panel discussion with the two of them could sell tickets.
Session 3: "Really Scaling" (Twitter's Britt Selvitelle)
Twitter is one of the more public of the "major-league" Rails apps, and due to some unique domain constraints, most of the traditional approaches to scaling weren't as helpful as one might hope. The "mantra" here is "Don't worry about scaling before you need it. Only worry about the stuff that matters. Gather lots data before you work on anything." For the latter, Twitter uses a nifty around-filter that outputs benchmark data in a comment at the end of every HTML page served.
There was also much emphasis on memcache and using daemons for any long-running processes. Also, a nice section on "being nice to the DB", including writing custom SQL ("SQL isn't dirty") when ActiveRecord's defaults spend too much time in the database and – in general – writing ugly code, if you have to, if that's what gets the job done.
Session 4: "Rubinius, Improving the Rails Ecosystem" (Engine Yard's Evan Phoenix)
As I don't actually have a degree in Computer Science, I found Evan Phoenix's talk on Rubinius a bit beyond my understanding, but very interesting in the bits that I could follow. Rubinius is a project to write a new interpreter/virtual machine for Ruby (see YARV, Parrot, etc.) The project isn't finished, but it's gaining ground, and already fairly impressive. Fun tidbit: the Rubinius folks are writing RSpec tests against Ruby 1.8 (which they then can run against Rubinius, to see how close they are) — these tests are being shared/co-developed with other related projects, including JRuby, and have reportedly been used to catch bugs in Ruby 1.9. Sweet!
Dr. Roy T Fielding's REST Keynote
Dr. Fielding gave an interesting, if awkwardly academic, keynote speech, expanding on his thesis work on REST. Since REST has been a major focus of recent developments in Rails, I think many were hoping for a more technically-oriented talk, but I found the details about early developments of HTTP fascinating. For example: when Fielding describes himself as a "Web developer" he literally means that he developed the Web, as in writing the HTTP spec, or maybe implementing it in Apache.
From Fielding's anecdotes, I began to see that Apache's phenomenal early success as the "defacto" Web server was because many of the people working on the developing HTTP specification were also working on the Apache project, creating what must have been a tremendous "try it out / think it out" synergy.
That's all I've got for now, more to come tomorrow.