Building RailsPerf, a toolkit to detect performance regressions in Ruby on Rails core

At RailsConf, in Atlanta, USA

Performance regressions in edge Rails versions happen quite often and are sometimes introduced even by experienced Core committers. The Rails team doesn’t have any tools to get notified about this kind of regressions yet. That is why I’ve built RailsPerf, a regression detection tool for Rails. It resembles a continuous integration service in a way: it runs benchmarks after every commit in Rails repo to detect any performance regressions. I will speak about building the right set of benchmarks, isolating build environments, and I will also analyze some performance graphs for major Rails versions.

Please note that the videos are currently available only for the talks presented in Room 202. There were five other tracks, and the recorded videos will be published soon. Thanks go to Confreaks for recording all Rails talks!

DHH’s Keynote

David’s keynote, a must-watch:

David announcing Rails 5

David announcing Rails 5

Yaroslav: First and foremost, it’s hard not to /facepalm after seeing this:

As a team member of the Ruby NoName Podcast, a Russian Ruby-and-everything-related podcast, I did an interview with Aaron Patterson on his visit to Moscow for RailsClub’2014, a Russian Ruby on Rails conference. The interview is available here (English sound, Russian subtitles).

One of the topics (that, of course, just had to be discussed) was if Rails is still led by Basecamp development; and yes, Aaron confirmed—it’s still pretty much “Basecamp Rails” (and there will be no attempt at making, say, “RedHat Rails”, following Aaron’s new job at RedHat). David is the one calling the shots, plain and simple. While it’s been known for a while now, it’s still surprising—and it’s not a good kind of surprise—to see that while one of the most important Rails maintainers is trying to make a good Node-like API for Rails, the announcement of a full-stack Websockets support can be completely sudden even for him!

Second, the Rails 5 announcement itself. Mad props go to David for walking the audience through the thought process and decision-making process in deep. While both of main announcements (ActionCable and Turbolinks 3) do sound promising, it’s still impossible to try ActionCable out at the moment of writing (the release is due in a couple of months, I think). The Turbolinks 3 gem seems to be merged into the repository, and we are going to try it out a bit later.

The biggest problem with Turbolinks so far, of course, was its “resentment” to all and any JavaScript frameworks. An alumni of Evil Martians, Sasha Koss, tried to solve the problem with the jquery.turbolinks plugin, but wasn’t successful much. Still, the biggest question to Turbolinks 3 stays: it’s not about the increased list of features (they do look great for quick development and prototyping — as opposed to starting an application with a full-blown SPA approach), but if Turbolinks still breaks all cooperation attempts with other JavaScript frameworks. Even with the most basic applications you would eventually kill all Turbolinks-related code and switch to do-everything-yourself approach as it would be faster and cheaper than integrating Turbolinks with other frameworks. I hope that it is no longer the case, but I’m not too optimistic.

To finish, the pros and cons of these two new announcements (not talking about the --api app generator switch, that is in no way new) are that they are surprisingly not that important for Rails future.


Explore more events

Contact us

We’d love to hear from you! We’re not really all that evil, and we love discussing potential projects, intriguing ideas, and new opportunities. Complete the form below or drop us a line at

Martians at a glance
years in business

A product development consultancy that works with startups and established businesses, while also creating open source-based products and services