The Doppler Effect

Today, I read a blog entry which, at first, I thought was a cruel joke. David Heinemeier Hansson, the creator of the wildly-popular Ruby on Rails web application development framework, announced that the widely-perceived-as-competetitor framework Merb codebase would be merged into Rails' codebase for Rail's next major release, version 3.0.

Only half believing this announcement, and being a savvy internet user, I did my research to see who else was talking about this huge development. The first evidence I stumbled upon was on the blog of Yehuda Katz, Merb project founder and lead developer. As the day progressed, I found more and more posts by core developers on both projects acknowledging the announcement.

For several reasons, the least of which is the pending new features coming in Rails 3.0, I'm very excited about this news. What makes me most excited about this development is the human factor. Two teams of developers, often perceived as competitors in their philosophy, product quality and mindshare, realized that competition in this case was less than ideal. By taking the best ideas from both projects, and merging them into one, the entire Ruby web-development community will benefit. Instead of continuing to take jabs at one another on their blogs and twitter and in conversation at Ruby conferences, they've agreed to pool their talent and create something great. They've recognized that their "enemies" should be their friends.

I've been developing on top of the Ruby on Rails framework since January of 2005, after watching the original 'Creating a weblog in 15 minutes with Ruby on Rails' screencast. I think it's great. I'm looking forward to it being made greater.

Ooops! Today, I accidentally copied over some program files I'd been working on. I hadn't checked the code into the version control repository yet, and hadn't backed it up, either. I began recreating the functionality that the new, now non-existent code had implemented.

A few lines in, I had an AHA! moment... on Wednesday, I had been quite proud of the solution I'd come up with for entering a custom value into a <select> form element, and I wrote a blog entry about how I did it. In that entry, I included a few chunks of the source code, so that other developers could get an idea of how I implemented my solution.

Yay! It turns out, those few blocks of code are about 90% of the work I'd overwritten. So, I just went back to that blog entry, and copied the code blocks and pasted them back into the old files. BAM!

I came up with and implemented what I think is a pretty nice way of allowing users to specify a value when the appropriate value does not appear in an HTML form <select> tag's value list. In this particular application, the user may also dynamically add fields to the form to accommodate multiple entries of the same type, in this case band and crew members and their roles.



Clicking the Add a member link causes a new, blank pair of fields to appear:



Here, Billy Butt Coconut's role in our band is not an option available in the list, so I'm selecting Other.



Now, I'm alerted to specify what role Billy plays in our band. He's the Dog, and integral part of the stage show.



As a form of feedback to the user, I manipulate the value of the selected form option to read "Other (Dog)".



After the form is submitted, the server-side application compares the submitted role name against the pre-defined options list. If there's not a match, it adds the newly-specified role name to the top of the appropriate select menu.

( code behind the cut )