‘Don’t fork Rails’: @tenderlove at Code Genius

“Sometimes” is Aaron Patterson’s least favorite word to see in a bug report. It’s right up there with his least favorite phrase: “Can’t you just…”
He spelled both points out last Thursday night in Gowanus, at Genius’s second instance of its new event series, Code Genius.
Patterson is a developer at Red Hat who serves on the core team for Ruby on Rails, an open-source web framework. Despite the fact that its code is there for one and all to see, Patterson says, “Don’t fork Rails. You are not special.”

As Genius cofounder and CEO Tom Lehman introduced Patterson, he said, “Open source is not a competition, but if it were, he would win.”
Through 168 slides and a little over 30 minutes, Patterson took the developers gathered on Thursday night through a tour of his latest thinking on code (and his Christmas photos), which he titled “OMG! Ruby and Rails Performance!!!!!!1.”
A few of the highlights follow:

• Regression test selection. Patterson thinks running tests on code takes way too long. A part of the problem is that you modify code and it runs a bunch of tests on code that you didn’t even change. He thinks there should be a way to only run the tests that matter on code that actually changed. He also desperately wants some to steal this idea and build it up as gem, but it’s not something he can take on. He wrote more about it on Tenderlove Making, his blog.
• Object leaks. Weak references can lead to slow memory leaks, Patterson explained, though it can take a while to notice them. He doesn’t like weak references for this reason. When objects continue to be referenced, they don’t get garbage collected, which adds up to real resources over time. The code may look simple and neat, he said, but it can end up being resource-expensive over time. That’s why it’s important to always test and then verify results with another test (for example, running a memory test and checking if the savings square with a time test).
• Integration tests versus controller tests. Patterson would rather just use integration tests, but they are slow. This is on his to do list to fix. He gave a big shoutout to Basecamp dev Eileen Uchitelle for helping to sort out the problem.
• Monkey patching. Sometimes if you look at the Ruby source a dev can figure out a sneaky fix for a problem they’ve been having. However, Patterson says if you’re working from a chunk of code they’ve marked as no-documentation, they are going to change it and your patch will fail. So you’re only hurting yourself.

Before Patterson’s talk, Mat Brown, of the Genius team, gave a quick demo of the code that allows every site on the internet to be seen through the Genius annotation lens.
The next Code Genius will feature jQuery pioneer John Resig and Bocoup engineer Jenn Schiffer.