I had the pleasure of attending RailsConf 2015 this year with my company Hired.
It was exhausting.
That’s the biggest thing I learned - I haven’t been to many tech conferences, and I’ve only once been paid to fly somewhere else on business. The factors added up, and I spent nearly every minute tired, exhausted, and not so functional.
- 5-hour flight on Monday
- Jet lag
- Being out of my familiar places
- Going to talks all day, and trying to learn something at each of them
- Socializing during any breaks or downtime
- Syncing up with the team
- Trying to bang out some code here and there
- The Hired semi-official after party on Weds
For an introvert like me, that kind of chaos took everything I had.
The upshot was, there were some great talks, and I met a lot of cool fellow Rubyists. We bounced ideas and war stories off each other during lunch & breaks, talked about our respective companies, and made the place more of a community than a business conference.
Favorite Talks
The videos are up on ConFreaks, who are by far the best conference-talk recording people I’ve ever seen. Some of my favorites:
- Don’t Be a Hero: Sustainable Open Source - a great intro to not having a bus problem in your open source project.
- Intro to Introspection Features in Ruby - not really an intro, this was some high-level talk. I knew maybe half of this stuff.
- Aaron Patterson’s Keynote - insight into how @tenderlove identified and attacked some problems in Ruby’s
require - Intro to Rails Security - no video yet, but check back later. Again, not exactly an intro - he mentioned some vulnerabilities I didn’t know about, and kinda sold me on Brakeman
A few of my notes
-
DHH’s motivation on Rails is making a framework for small teams the does 90% of what you need. Twitter took this as him crapping on microservices and front-end frameworks, which he did a little bit. I respect that motivation, as that’s what let me pick up Rails and do cool stuff with it in the first place. And for small teams (<100ish) it allows everyone to be self-sufficient.
-
He mentioned Writeboard as a terrible experience developing a microservice. Couldn’t agree more - it was a PITA to use. I’ve gone down a similar path with at least one team, and the added overhead becomes awful.
-
If you’re running an open source project, respond to ALL pull requests within 48hrs. If you wait more than a week, they’ll never contribute to you again.
-
Don’t hoard the keys to your open source project - make sure someone else has access to the domain, can publish the gem, etc.
-
Kubernetes is pronounced kübêrnêtēs - thanks to Aja “Thagomizer” for the clarification. And the quick intro to Rails on Docker.
-
Model callbacks in Rails 5 will not halt the callback chain unless you explicitly
throw(:abort). For a ridiculously long discussion why, check out this ginormous PR. -
From Koichi - keyword params are still 2x slower than normal params (30x slower on Ruby 2.0)
-
I left the “Crossing the Bridge” talk on Rails with client-side js frameworks. The architecture he outlined (
ActiveRecord,ActiveModel::Serializers,ng-rails-resource) is terrible. 20x the overhead of server-side rendering, and your client-side app ends up a disastrous mess. -
I did get to talk to Mike Perham, the creator of Sidekiq. We had an interesting chat about memory usage and ruby GC. I was hoping that the OS would clean up memory used by a separate thread – ie, ending a sidekiq job cleans out memory much faster than letting ruby’s GC run. Unfortunately, that’s not the case, and there’s still no real way to predict when ruby GC will run, short of calling it manually.