RailsConf 2012: Aaron Patterson Keynote

“Señor Software Engineer”

@tenderlove
aaron.patterson@gmail.com
 
[What Would Freddy Mercury Do] Slide
 
“How I fill out my annual review”
It’s one of those sites where you boil yourself down to a few categories
 
“Hey, your browser is not supported”
Chrome? No. 
Safari? Too new a version
Maybe IE on a Windows VM! NO. It must be IE7, not IE9
“I have no idea how to downgrade IE…?”
Levels of complexity go insane at this point. Network diagram looks like a five year old scribble. 
“Technically known as Rube Goldberg Network Architecture”
 
Let’s Talk About Failure
“I’ve made a huge mistake” 
 
Failure to Remember
 
Tokaido
Yehuda’s new project
Binary distribution of Ruby for OS X that ships with rails and dependencies
Excited about this for students (easy to get it up and running) and teachers (get to teaching faster)
Really excited about it for all developers
 
“How important is your time?”
 
Goes through a bunch of questions that come up when attempting to install from source
In order to debug you need to know all of that about shared objects, etc. 
Do you want to be wasting your time looking up the order dlopen looks in DYLB_LIBRARY_PATH?
 
Ecosystem
Yehuda’s going to have to go around and get C extensions statically compiled
Use rake compiler if you author a C extension
 
If you don’t think this is a good idea, go volunteer for RailsBridge. 
You’ll be helping people learn about Ruby on Rails but you’ll understand the issues people encounter while learning
 
Failure to Evolve

Concurrency
“Why do we have ActionMailer?”
So that we can send emails from our application
 
Linear processing, the email is in the middle of the request
Can be slow, what if it throws an exception in the email?
Best case: slower response time
 
How do we pull email out of band of the main request?
So why do we not have a queue?
 
WE do have a queue in rails called ActiveQueue
No one uses it because it has no docs, no examples, and lots of config required
 
 
The reason? AQ is zero lines of code :)
 
Queueing choices, so many of them. 
All have different interfaces
 
Interface is the most important
Implementation is secondary
 
Demand a consistent API
Queues must implement PUSH
Consumers must implement RUN
But there’s no driving force…
 
Failure to Lead

Features, and fear of Features
 
Value = Current + Potential
Cost = Dev Time + Maintenance
 
Tolerance = Value / Time
 
New developers are more likely to click the merge button
They’re not expecting the support efforts in an ongoing fashion
 
Types of features

Three types:
  • Cosmetic
  • Refactoring
  • Course Correcting
Cosmetic Features
Dubious value and unknown debt
Example: Tagged Logging
Initial implementation was not thread safe and incompatible with many log libraries
It doesn’t auto escape input
Took 18 commits and 10 authors. 
It has dubious value and unknown debt. 
Why do we need this? Maybe it’s better as a plugin
 
Refactoring Features
High value and low/negative debt
These came about by improving the architecture of our system 
Rails 4 has start and finish events with tree based structures instead of waiting for notification method to run
Refactoring gave us less code, more information, and a smaller stack size
 
Course correction Features:
High Value and Unknown Debt
Example: Asset Pipeline
We said “we have a problem in rails”
Everyone was doing it in their own way
We still have a bit of room to grow
 
Computation and Distribution
First exposure to computers were at a library
Centralized dumb terminals. Terminal access to mainframe
Distributed moved to PC processing
Internet moved us back to Client/Server model
Moving back to distributed (JS + Browser)
Browsers are getting more powerful and we need to take advantage of them
 
Problem with Course Correcting Features? We’re willing to take on high debt to get there (“Too Big To Fail”)
Because we added it to Rails, we can’t allow it to fail, because that’s the direction we need to go
 
For technical debt, there is no bailout.
Someone has to pay down the technical debt
 
Computation location is changing
And we need to be prepared.