Data / Events

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

Through 168 slides and a little over 30 minutes, Red Hat developer Aaron Patterson explained his latest thinking on code.

Aaron Patterson (@tenderlove) at Code Genius in Gowanus. (Photo by Brady Dale)

“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.”

Tom Lehman at Code Genius 2 in Gowanus, February 2015

Genius CEO, cofounder and original coder of the site, Tom Lehman. (Photo by Ethan Young for Genius)

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.

Code Genius 2.26.15 - Technical.ly Rushes -5

Patterson shares his Christmas Photos from JC Penney’s. (Photo by Ethan Young for Genius)

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.
Code Genius 2.26.15 - Technical.ly Rushes -1

The developer-only event attracted coders from all over New York City. (Photo by Ethan Young for Genius)

Companies: Genius
Series: Brooklyn

Before you go...

Please consider supporting Technical.ly to keep our independent journalism strong. Unlike most business-focused media outlets, we don’t have a paywall. Instead, we count on your personal and organizational support.

Our services Preferred partners The journalism fund

Join our growing Slack community

Join 5,000 tech professionals and entrepreneurs in our community Slack today!

Technically Media