This year for Rails Rumble, our team decided to write an app for tracking whom you’ve loaned your items to:

It was a blast, just like last year. Having James Pierce as our designer made a huge difference in the quality of our app.

Using Gawker, we recorded time lapse videos of our three sessions.

Session 1:

The fifth person in the video is our co-worker Will, who didn’t actually code anything for our Rumble app. He was there to provide some Git (and morale) support and keep Rumble Helper updated. So we didn’t cheat!

Session 2:

I forgot the timestamps on this one, but it lasted from about 9:30am on Saturday to 5am on Sunday (the last 15 seconds [3 hours or so real time] is dark… we forgot to turn the camera off). Ten points if you can spot our friends Ryan and Leah Stufflebam, who dropped off some homemade chili for us. It was delicious.

Session 3:

The last session! In total, we got about 8 hours of sleep each, drank like I don’t know how many cans of soda, ate a buttload of chips and pizza (and chili). It was a blast.

Go see our app: lend.to, and all the other Rumble apps when you get a chance!

After a meeting of our Rails Rumble team the week before the competition, I decided to undertake a little project to keep track of stuff we wanted to get done during the Rumble. I came up with Rumble Helper:

You can drag and drop items from one bubble to another so you can easily track what needs to be done.

We used it during the Rumble in combination with SmartBoard:

It turned out pretty well! Darcy was nice enough to put it up on the Rails Rumble blog before the competition. At the end, 45 users had signed up (representing 20 different teams) and 327 tasks had been created. I was happy it got some use.

It was a really good warmup for the Rumble. I worked on it solid from Friday (August 14) to about Thursday (August 20). There were several things about it that helped having experience with during Rails Rumble itself.

For next year I plan to add more features to it, like the ability to see what other teams are doing (if they made their team public, that is). There are also some Javascript issues that I need to see if I can take care of. If you leave the app open for too long, eventually the AJAX calls bloat up Firefox pretty badly.

The HTML specification dictates that unchecked check boxes should not supply a value in a form submission, which can be problematic for applications wishing to set a flag in a database based on an unchecked check box. Rails gets around this by using a trick in the check_box helper. It places a hidden input tag with the requested default value directly after the check box tag.

The reason this works is because form parameters are sent in the order that they appear. This means the hidden input value is submitted after the check box value would be, and Rails gives precedence to parameters appearing earlier in the request.

I tried this in PHP, hoping it would behave the same way. It doesn’t. It turns out that PHP overwrites earlier variables in the request with later ones. This behavior is dictated by the request_order directive (as of PHP 5.3.0, which is still in beta at the time of this post). The fix is simply to place the hidden input tag before the check box tag.

Hopefully this helps someone avoid the moderate pain I went through figuring all this out.

In one of my Rails projects, I have some views that are rendered through ERB and others through HAML. This makes it annoying to jump to a view’s spec via rails.vim, since it currently doesn’t handle custom Rcommand’s that accept multiple suffixes.

When I asked tpope today about this, he brought up a good point. Why are view specs associated with an engine type (such as ERB or HAML) by default? You should be able to convert an ERB view to a HAML view and use the same tests.

Per his tip, I renamed my views from names like new.html.haml_spec.rb to just new.html_spec.rb. Unfortunately, autotest stopped recognizing the correlation between my views and my view specs. Putting this in my .autotest file fixed the issue:

Autotest.add_hook :initialize do |at|
  at.remove_mapping(%r%^app/views/(.*)$%)
  at.add_mapping(%r%^app/views/(.*)$%) do |f, md|
    # strip off engine name
    path = md[1].sub(/\.(erb|haml)$/, "")
    at.files_matching(%r{spec/views/#{path}_spec.rb})
  end
end

I hope that helps someone.

Ever since I started using Rails two and a half years ago, there’s been something that’s nagged me about the Rails community. Only recently have I been able to put my finger on it. I’m not sure if this applies to all OSS communities or just Rails’, but it really bugs me.

Everyone’s a bandwagon jumper.

Take the whole TextMate movement, for example. Two years ago, TextMate was the editor for Rails developers. All of a sudden though, Vim is the new hotness. Apparently the exodus from TextMate became full blown after Jamis Buck switched back to Vim. And, poof! Hard-core TextMaters are suddenly hard-core Vimmers. Some of them are switching back to Vim, but others are first time Vim users and now think it’s all the rage. It bothers me.

The same thing happened with the testing movement. Rails developers are known for their outspoken opinions about testing. “You should test all the effing time.” Everyone seemed to latch onto this idea without even thinking about it. I agree, testing is good, and it helps you write very stable code, but the blind acceptance of things just seems to happen a lot in this community.

Both Vim and unit testing have been around for a while. It takes a big name in the community to bring them to attention, and then everyone and their mother’s dog starts doing it.

And then there’s Git. Until a year ago, pretty much everyone used Subversion, and then Git comes out of nowhere. All it takes is a Google video of Linus Torvalds calling Subversion users idiots, and pretty soon after that, you’re behind the times if you’re still using SVN for your revision control. Github has exploded as the place to have your code if you’re somebody.

It seems like everyone’s racing to come up with the next big idea that will be adopted by the entire community. And if someone beats them to it, the next best thing is to latch onto an idea while it’s young so that they can be one of the few riding the crest of the wave that’s about to break onto unsuspecting John Q. Programmer.

To be honest, it’s like high school all over again. It’s the rush to be popular. The only difference now is that the stage is bigger and money is involved. If some new way of doing things comes up, consider it, and make up your own mind about it. Don’t switch just so you can be one of the first to do so. The tides change so drastically so often it’s staggering. If you don’t keep up, you might be not be in the in crowd anymore, oh noez!1!one!

Of course, everyone is entitled to their own opinion. This is just the way I view it.