A few weeks ago, several Test Double agents attended RailsConf 2019 in Minneapolis. They had a great time, so we asked them to share their favorite talks. Here’s what a few of us took away from the conference:
This year’s RailsConf had a number of standout sessions for me—everything from Rails at scale to frank discussions on the real-world implications of ethics and diversity in technology. However, one session in particular stuck with me: Amy Newell’s talk, Failure, Risk, and Shame: Approaching Suffering at Work.
Amy covered a heavy topic with an impressive blend of honesty, openness, grace, and humor. In the talk, Amy posits that some degree of shame and suffering at work is both natural and inevitable, but as humans we tend to compound the effects of these events through our reactions to them. By instead learning to accept these events as normal, we can start to manage how we respond to them and in turn handle them in healthier ways. The video really is a must-watch, and you can catch it here.
[Marla gave a thought-provoking talk on her experiences tranisitioning to remote work, and you may be surprised by some of the counter-intuitive insights she shares]
I’ve always had a soft spot for talks that take something that appears difficult and breaks it down into an understandable, approachable story.
Joel Hawksley’s presentation, “Rethinking the View Layer with Components”, deals with some common problems with using views in Rails. He then describes how React handles these problems through components and explores what a Ruby-ish solution would look like. His answer progresses by test-driving his desired solution, showing how to work with Rails to achieve his goal while still leveraging what Rails has to offer. The Rails team also seems to acknowledge the benefits of Joel’s approach, as support for ActionView::Component was just merged into Rails!
I’ll share three talks I’ll remember from RailsConf 2019 that haven’t been mentioned yet.
Eileen’s talk on the Herculean efforts it took to upgrade GitHub’s Rails codebase from a fork of Rails 2 all the way to the tip of Rails 6 master. We’re seeing more and more teams choosing to invest in renovating their Rails apps (as opposed to moving to some other tech stack) this year, and it was awesome to see Eileen detail a methodical approach to pulling off a major upgrade without slowing down everyone else’s feature contributions. (Shameless self promotion: if your team is struggling to find time to upgrade your Rails apps, Test Double has helped half a dozen companies with Rails upgrade initiatives this year, so consider getting in touch!)
Lee Richmond’s ⚡️
talk on his (IMO) excellent suite of tools
for building robust, conventional HTTP APIs,
Graphiti. If your team has struggled using
ActiveModel::Serializers, GraphQL, or rolling your own JSON API routes,
you should really give Graphiti a look.
Sam’s talk had RSpec in the title but was actually mostly about the folly of treating SemVer as a law of physics as opposed to what it really is: a communication mechanism for signalling intent. Sam and I both maintain a bevvy of libraries that do little else but connect two disparate things together, and the talk explores why it’s so hard to identify a “breaking change” when trying to maximize compatibility. If you think following SemVer is a trivially obvious exercise, I strongly encourage you to spend thirty minutes with this presentation.
I always enjoy when talks on different tracks cross-pollinate, and that was the case for me with Richard Schneeman’s and Caleb Thompson’s talk on tidying up ActiveRecord allocations and Nate Berkopec’s talk on profiling and benchmarking.
Richard’s talk (complete with a computer-generated animation of Marie Kondo’s pet rabbit as a guide!) focused on using object allocation as a lens for investigating potential memory hot spots in Ruby applications, and I thought his motif of whether objects “spark joy” was fun and helpful. (If an object is sufficiently necessary, useful, clean, and performant, then it sparks joy.) I was really impressed by how much Richard could learn with just a memory profiler and his gem derailed benchmarks. It was amazing to work through a bunch of real-world examples to profile Ruby programs and refactor them to use less memory! I’d tell you all about my favorite refactorings, but you should really go watch the talk.
One aside in Richard’s talk I particularly enjoyed was the history of Student’s t-test to determine if the differences between benchmarks are actually statistically significant—and the story behind this is, well, brilliant.
I have a bit of a soft spot for history-laden technical talks (Nickolas Means is particularly great at these!), so I couldn’t miss Nate Berkopec’s talk on profiling and benchmarking as explored through the Apollo 11 mission to the moon.
In Nate’s talk, he examined benchmarking (an artificial measurement of the resources a computation requires) versus profiling (a step-by-step accounting of the resource usage by the various parts of a program while performing a computation), as well as how and when to go about testing these in your own applications. I think my favorite slide was the one that said: “All performance work without measurement is premature,” which is now on a Post-It note over my desk. I found the space theme particularly engaging, especially the details around the 1201 and 1202 errors (complete with images of NASA’s original notes!) suffered by the Apollo 11 guidance computer en route to the moon (and which almost caused Neil Armstrong and Buzz Aldrin to abort the mission).
I won’t spoil the rest of the talk for you, but the gist of it is: read your production metrics, profile to find hot spots (just as Richard showed us in his talk), create benchmarks, make fixes (potentially discarding objects that don’t spark joy), deploy, lather, rinse, and repeat!
[You can check out Eric’s own RailsConf talk on interviewing here on the blog, as well!]
I enjoyed a number of talks, but two in particular resonated with me this year:
Rethinking the view layer with components by Joel Hawksley:
I always love it when we are able to take lessons learned in one area and apply them to another. In this talk Joel shows some of the work he’s done recently at GitHub to borrow View Components from systems like React and use them in Rails. This approach will be in an upcoming version of rails as ActionView::Component.
Things I Wish I Knew Before Going Remote by Marla Brizel Zeschin:
I’ve been working remote for a number of years now and feel like I’ve gotten pretty good at it. Marla’s sharing of her own experiences as a remote worker caused me to re-evaluate my own habits and helped catch a few things that I’ve been neglecting in my routine.
I’ve gotten the question a couple times, “Why do you even go to a software conference? All the good talks end up online anyway.” And during my travel on the way to a conference, I often wonder the same thing.
But in the days and weeks following, I remember why.
Being surrounded by so many people who are excited about what they do, conversing with folks who are passionate to learn and create, the (admittedly exhausting) fire-hose level of human interaction… the energy and inspiration/motivation you can absorb from that environment is hard to replicate. It always helps elevate my work, and ultimately my outlook, in surprising ways following the event.