casperfabricius.com

I’m currently working on a report comparing the Linux Kernel, KDE, Dokuwiki and Ruby on Rails in terms of how they work and perform as open source projects. We have collected data from the mailing lists, issue tracking systems and source control systems of each project (October 2006 - September 2007), and while I don’t have anything groundbreaking to report, I do have some food for thought for the Ruby on Rails community.

These four pies clearly show that Linux - not surprisingly - is the largest projects in terms of changesets (patches committed to the code base), messages (emails sent to the core mailing list) and individual senders (different people who has sent messages to the mailing list). But in that same year, almost twice as many issues (which is our neutral term for what is called tickets in Trac) has been opened in the Ruby on Rails Trac system as in the Linux Kernel Bugzilla system, despite the fact more than 10 ten time as many changes has been accepted into the Linux code base.

“Wait a minute!” you’ll probably object if you know a bit about how things roll in Linux-land, “they use mailing lists for that stuff on the Linux Kernel, so issues are only used by a few to report bugs.” And that’s absolutely true. The activity level of the Linux Kernel mailing list is more than 30 times the one on the Rails Core mailing list, and one out four messages either contain a patch or is directly related to one.

So okay, the Linux-community handles changes in one way, and the Rails-community in another - big deal, it seems to work out for both communities. Now, web-based issue tracking systems like Trac or Bugzilla are supposed to be the “new” way to manage open source projects, right? Linux is just stuck in the old mailing list workflow, but surely that must Linux much less efficient than Rails, because there is no overview of open issues and patches, no reports and no statistics? Well, not really.

The bar chart above shows the mean time to change for each of the projects. It is calculated as the average time span elapsing from an issue is opened in the issue tracking system till it is closed again. On average, it takes a patch 74 days to get into Linux code base and distributed as part of the worlds most popular operating system for servers. For Ruby on Rails, it “only” takes 54 days, so clearly the Rails-communities way of doing thing is more efficient. Or is it?

It is almost twice as fast to get a patch into the Dokuwiki code base as into the one of Rails. “Well, that’s a fairly small project with the creator also being the main contributor, so that’s not so strange” you might say in an attempt to defend your favourite open source community. Okay, but how about KDE? You can get a patch into the KDE core more than three times as fast. Now, to be fair, this is not the entire KDE suite of applications, but only the core of KDE, so most of the contributors has direct commit access themselves. But KDE and Dokuwiki aside, shouldn’t it still be faster than 54 days on average to a patch into the Ruby on Rails framework?

“Okay, so the average is 54 days, but that’s just because a few issues are left there like forever distorting the average” you might say. Well, first of all only issues that has been opened within the year and closed with a resolution if fixed is included the metric. Second, as the histogram above shows, around half of the issues are fixed within 12 days (the cumulative percentage is almost 50 at the first high bar, and that’s 12 days, not 24 as Excel insist on putting below the bar), but the other half takes close to forever to get closed.

So food for thought I said. I’m not pointing fingers at the Ruby on Rails community, of which I consider myself to be a part, only saying that we might want to think about if using Trac for everything and only having 12 people with commit rights is the best approach? Think about it, and if you have comments, critique, ideas, please do post them here so that we might use them in the final report.

PS: The period of time ends a short while after the whole Report #12 procedure was announced, so hey, that might fix everything …

Benjamin Quorning gave a great tip at the Copenhagen Ruby Brigade mailing list the other day: How to run (Windows) Internet Explorer on your (Intel-based) Mac without having to boot up Parallels, VMWare, or any other kind of time-consuming PC-emulation software. This is made possible by the IEs 4 Linux project (no, that’s no IE 4 on Linux, it’s IEs for Linux, and IE 4 is not supported, just 6, 5.5 and 5) which provides a simple way to run IE on Linux and, as it turns out, OS X on Intel-based Macs.

While the article on the IEs 4 Linux provides one method for getting this up and running, I tend to like Benjamin’s more as it uses MacPorts, so I’m going to repeat it here for reference. A prerequisite for the tutorial is to have X11 installed, which is part of the optional developer tools that comes with OS X, and you also need MacPorts, which seems to be the best package system for Darwin at the moment.

To install IEs4Linux and its dependencies, execute these commands in your terminal of choice:

sudo port install cabextract wget wine
wget http://www.tatanka.com.br/ies4linux/downloads/ies4linux-latest.tar.gz
tar zxvf ies4linux-latest.tar.gz
cd ies4linux-*
./ies4linux

The first line installs several components required to run IEs4Linux, most importantly Wine, a framework allowing many Windows applications to run on Unix-based systems, including OS X. The other lines download and start the impressively user-friendly installation of IEs4Linux. After completing the installation, Benjamin explains that to run Internet Explorer, you must startup the X11 console (/Applications/Utilities/X11.app) and execute these commands:

export PATH="/opt/local/bin:/opt/local/sbin:$PATH"
~/bin/ie6

That’s a bit too inconvenient for my taste, since want to be able to place a link to IE directly in my Dock, or run it by executing a simple command in Quicksilver. So I have created a shell script in my home directory (you could also place it in the Applications directory if you like that better) called ie6 with the following contents:

#!/bin/sh
open-x11 .ies4linux/bin/ie6

I also need to make it executable by running chmod +x ie6 in the terminal. Now this gives me the ability to execute the shell script from terminal, to call it from Quicksilver (by writing ie6), and to drag it to the right/lower part of the Dock (the part with the trash can in it) with an ugly generic document icon. I want it in my Dock with a nice high quality Internet Explorer icon so I can start just like any other application, and for that purpose I wrapped the shell script as an application:

Download IE6 application

• Requires IEs4Win to be installed in the default location (~/.ies4win)
• Must be dragged to the Applications directory in your home directory (create one if you don’t have one), not to the general Applications directory (this is due to my limited shell scripting / X11 abilities, ~ didn’t seem to work as a reference to the home directory in X11).

I’ve only written two blogs from RailsConf Europe this year, one about Dave Thomas’ keynote; The Art in Rails, and one about David Heinemeier Hansson’s keynote, which has temporarily many-doubled the traffic to my blog after being referenced in Signals vs. Noise - thanks, Jason!

But those two keynotes was far from the only sessions I attended worth blogging about, and I have been taking 2-6 KB notes from each and every session. Sadly though, I can’t seem to find the time to write a full article about each of them right now, albeit now is the time people want to read about the conference. So I thought I’d put out my notes from most of the sessions I attended (those worth reading), with a little description with each of them. There are also select presentation slides available.

A Half-day of Behavior-driven Development on Rails
I enjoyed being taught the concepts of Behavior-driven Development by the creator of BDD, Dan North, as well as I enjoyed getting the rspec plugin explained by its creators, Aslak Hellesoy and David Chelimsky, although I noticed they had given up on trying to pronounce the name of the plugin “respec’”, as Aslak tried in vain when he was interviewed for the Ruby on Rails podcast.
Download notes

Caching in a Multilanguage Environment
Benjamin Krause has been kind enough to write two plugins for handling multilanguage routing and multilanguage caching (link doesn’t seem to be available), respectively. In his talk, he explained why current Rails routing and caching is inefficient for multi-language sites, and the rationale behind his design decisions in the plugins.
Download notes

Meta-Magic in Rails: Become a Master Magician
Dr. Nic put on a great show explaining Ruby meta-programming, stressing that introspection is the ability to look at your own code, while reflection is the ability to change your on code dynamically. He also compared Perl to a puppy (fun, but with no understanding of itself), Java to Keith Richards (not so cute anymore) and Rails to Neo (knows about and can change his environment). Finally, the good doctor demonstrated a quite useless, though fun, plugin he had created written by Chris Shea; guessmethod, which attempts to catch and correct misspelled contant and method names dynamically.
Download notes

The Forgotten Child: Powerful CSS with Rails
At the other end of the frontend-backend scale, but just as entertaining, Geoffrey Grosenbach talked about the possibilities of generating CSS. A simple approach is to add CSS as a format recognized by Rails and then generate stylesheets using ERb, but the Rails Podcast author also explained about the opportunities of SASS, a powerful Rails plugin for simplifying, beautifying and DRYing up stylesheets.
Download notes

Lightning Talks
A cancelled talk opened up the possibility for a lightning talk session, and several of the core team members was on the spot. Marcel Molina started out, demonstrating his forthcoming plugin render_with_presenter, and did an many ways a better job of explaining the presenter pattern than Jay Fields did the following day. As a seemingly more advanced alternative to the Comatose CMS plugin; Sandstone (to be released as open source) was also introduced, and Tobias Lütke did a good job of explaining the benefits of using Liquid as a Rails renderer.
Download notes

Best Practices
Core team members Marcel Molina and Michael Koziarski stressed that while there a plenty of resources telling you what you could do in Rails, they wanted to tell us what we should do. The things they said made a lot of sense (especially the notion of Skinny Controllers - Fat Models), and reminded me that I should probably spend more time learning best practices from The Rails Way.
Download notes

Building Webapps in Europe: Economy, Methodology, and Tips
Nicolas Paton’s was a bit disappointing to me, as most of the things he said was pretty much common sense. I hold a lot of sympathy for the guy though, as his nervousness was quite visible during his talk - and thumbs up for bringing attention to differences between development in US and Europe.
Download notes

Ruby on Rails Security
Heiko Webers of RoRsecurity.info brought our attention to potential security issues not only in our Rails code, but also in the web server and database. The biggest take-away from his talk for me, though, was his mention of three plugins: WhiteListHelper for allowing only select tags in user-generated content, SafeERb reminding you to sanitize all your output of user-generated content and ActiveForm, which allows you to validate e.g. a search query using the ActiveRecord validators.
Download notes

Browser-based Testing of Massive Ajax-using Rails Applications with Selenium
I’ve known for a while now that I ought to improve my test base with Selenium tests, so Till Vollmer’s talk was a nice opportunity to get more into the testing framework. One of Till’s important points was that you’ll have to write your own test helper methods in order to get readable tests when testing massive Ajax applications like his Mindmeister. I also want to mention Cross Check of Neal Ford’s javascript testing talk in this context, as this application are able to emulate most known browsers - including their many bugs and differences!
Download notes

Functional JavaScript Development with Prototype
Ben Nolan managed to explain a lot of important javascript concept through his fast-paced tutorial. I for one didn’t know about javascript binding contexts before this talk, but it explained a lot of previous experiences to me! Whether you like Ben’s functional and very compact style when coding javascript, his tutorial was definitely enlightening and enjoyable.
Download notes

Teaching Rails at a University
While Carsten Bormann’s about his course in agile web development using Ruby on Rails on a German university didn’t attract a very large crowd, those of us who was there were definitely glad to hear the news that it is possible to bring Rails into such old and dusty institutions as universities. I for one feel inspired to attempt to bring it into my own school, Copenhagen Business School, because really Ruby is much better suited as first programming language than Java and C#, I think.
Download notes