RailsConf 2015 Recap and Thoughts

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:

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

As a team member of the Ruby NoName Podcast, a Ruby-and-everything-related podcast, I interviewed Aaron Patterson on his visit to RailsClub’2014. 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.

If Turbolinks does annoy you (from my point of view, that is true for most Rails teams), just don’t use it — it does not matter much. If you like the approach and have an “allergy” for JavaScript as a language and for any JavaScript framework as a consequence of that — the update is definitely for you. I still wonder about how usable exactly ActionCable would be, but the truth is, a lot of Rails applications are already utilizing more than one language at the backend, and people (our team included) have been implementing WebSocket backends for a number of years now. You could go with Node.js, Erlang, a JVM-based language like Scala, Go, or whatever the favor-of-the-month language is. So far, it does not sound like ActionCable would fundamentally change the way things are in that department.

Ruby on Rails continues to be the best full-stack web framework on the market — miles ahead of competitors — even when used as a mobile API backend, an SPA backend, or a base for a simple microservice. Unfortunately, the new features introduced in the talk are not new in a fundamental way and they don’t define the future of a framework.

You can also check out a couple of other write-ups regarding the talk by DHH — an optimistic one and a depressing one.

Kir: my notes below summarize the most notable talks (in my humble opinion, of course), and they are listed in the order the talks were presented.

Riding Rails for 10 years

A Great talk by John Duff on how did the Shopify app codebase change since Rails 1.2 to 4.2. I did enjoy the slides about how the API has changed version by version and about their Rails upgrade story. This is why I like the Shopify team: they probably have the second oldest Rails app (Basecamp being the first) with up-to-date codebase, and up to 150 developers working on the app at the same time.

Scaling Rails for Black Friday or Cyber Monday

Another talk by a Shopify developer, Christian Joudrey, was as good as the “Riding Rails for 10 years”. There are not so many companies that share such experience about scaling Rails — for just one day, the Black Friday — and Shopify is one of them. The main idea behind the ability to serve more clients is to reduce Unicorn response time or add new workers. Christian demonstrated their gem for caching that they use at Shopify, called “identity_cache”. I was surprised to learn that people do put serialized ActiveRecord models into Memcache to cut down DB hits; this was one of the solutions Christian did mention.

Better callbacks in Rails 5

This talk by Claudio Baccigalupo was one of my favorites. He is a member of Rails team, and he worked a lot on “rethinking” callbacks in Rails 5. Here is an example of how behavior of returned value will change:

class User < ActiveRecord::Base
  before_save { |u| u.admin ||= false }
end
# rails 4:
User.create! # => ActiveRecord::RecordNotSaved
# rails 5:
User.create! # => true

There is also a new shiny abort method if you’d like to prevent the saving of the record inside the callback in Rails 5. I’ve asked him a tricky question: basically if we should teach new Rails developers how to use callbacks properly and how to avoid “callback hell” in ActiveRecord models. We’ve decided that maybe it’s time to think about a Rails Guide containing “best practices” of using callbacks and about separating logic between MVC layers.

Processes and Threads — Rescue vs. Sidekiq

Before I came to the talk, I expected James Dabbs only to cover differences between these two queue processors by making some comparison table. But, in fact, he did demonstrate all the internals, how do forking and threads work in Ruby and what are the basic concepts. Also, during the session, he demonstrated stack calls by jumping into the code with the pry gem in both Sidekiq and Resque.

Aaron’s keynote

All Aaron’s talks are awesome. He has a great talent to combine jokes, ideas and code in a single keynote. On this RailsConf he opened the second day by talking about RubyGems/Bundler performance, about how require works in Ruby and how are we going to deprecate controller tests with integration tests — that will be even faster than the controller tests we have now.

How Rust helped Us Write Better Ruby

This talk was about how does Skylight (a Rails applications profiling and monitoring service, founded by Yehuda Katz) use Rust for their report agent. The agent ships with the skylight gem and used by client Rails apps to track performance and report it back to Skylight. Skylight did choose Rust to make the report agent to be able to serve thousands of requests per second and to avoid GC pauses inside this agent. In the talk, Yehuda and Tom did demonstrate a few examples of Rust memory management and how powerful it can be.

Designing a Great Ruby API — How We are Simplifying Rails 5

This talk was on the last day of RailsConf. I’ve met Sean Griffin at the speakers dinner on Monday, the day before the conference — when he told me about his topic and I’ve been looking forward to watching his talk since that moment for 3 days.

Sean talked about a lot of ActiveRecord refactoring in Rails 4.2 made by him, about how he changed typecasting and how we are going to make it even better in Rails 5 by shipping the Attributes API.

Nothing is Something

The last talk on the 3rd day by Sandi Metz was as great as any of her other talks you’ve ever heard. Sandi started by demonstrating Smalltalk ideas that we have in Ruby, and then talked about why inheritance is sometimes not the best solution, and about how we can use advantages of the NullObject pattern in Ruby. I enjoyed all 600 slides with code, and I can say that it was the most “code-oriented” talk at the conference.

My talk

I’ve been preparing for my RailsConf talk for almost three months (five months if we count the benchmarks implementation), and it was one of the most exciting experiences in my life this year. It wouldn’t be possible without help by @yaroslav, @samsaffron, and @tgxworld. Thank you guys!

I’ve had the most exciting three days in Atlanta, and I’m looking forward to visiting the next RailsConf — in Kansas City: