RailsConf 2012: Presenters and Decorators

Mike Moore /@blowmage 

Rails is a diverse community, there are lots of approaches
There are flaws in this, as in any singular approach
Presenters should ease pain
You shouldn’t start with these, but implement them when you feel pain
Components (bad smell)
New developer wants to go change the dashboard and this is all he finds:
<%= render_component(@component) %>
Okay, let’s let’s look for this method. 
This method renders a partial.
The partial has:
<%= render_component(component) %>
It’s actually in component_helper.rb
Keep drilling down, find something in a builder in lib/dashboard_component_builder.rb
CallsPostItemComponentBuilder, which inherits form ComponentBuilder
There is still no build list (which is what we’ve been looking for)
Maybe it’s in the ComponentBuilder class. 
This lives in app/components/component_builder.rb (why?)
So _this_ builds the list! Yay!
post_item_component.rb defines off Partial Component and references another partial of posts/post_item
PartialComponent… do we have a render call? 
“This is MetaProgramming, and it’s incredibly difficult to understand”
They dynamically create a new class, etc etc. 
[Continues to drill down the insanity]
Totally not a productive flow
“Wont’ someone please think of the new developers?!”
Not newbies, but people not familiar with the app
There is no excuse for the component example. That’s awful code. 
You should only use presenters when the pain that the presenters solve is exponentially more than the pain they create.
You want more benefit than  cost.
View is a total bike shed
A bike shed is when you have a lot of people arguing about the cosmetic detail of how something is going on but it doesn’t really matter
[Typical presenter example]
Local assigns, lots of conditional content
A lot of things get stuffed in the model
Does your domain really need these? 
This is not domain logic. it’s front end presentation logic
The model is not the location for this. 
Alternatively, we could create something in /lib
We have something that we can test without confusing the rest of User.rb
Typically, a presenter is something that knows about your models for view logic.
Extract those local assigns OUT of your view
We have some libraries that do this for us:
ActiveDecorator github.com/amatsuda/active_decorator
Decorators move things into the app/decorators directory
It helps. 
Typical Serialization Example
Post controller post#show
JSON delivery with RABL file
“I look at this and say ‘how am I going to test this?'”
The only way is an integration test, and it’s a lot of work to set that up
ActiveModel::Serializer looks for the rendering of JSON and intercepts it. 
This is where most people stop with presenters.
But is that all?  
Let’s take a look at some design patterns.
Decorator Design Pattern
Attach additional responsibilities to an object dynamiclaly Decorators provide a flexible alternaitve to subclassing for extending functionality. 
Mediator design pattern
Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly and letsvyou vary their interaction
Not every presenter is a mediator, and vice versa
We have a presenter spectrum between views and models. Presenters go anywhere between. Decorators are more model side of the spectrum
Presenters is more on the view side (at least 5 years ago that’s what it was called)
Where did it come from?
Calls out Martin Fowler’s work
Enterprise Application Architecture book
Presentation Model
[definition from MF’s site]
Presentation is a “representation of the state of the view”
A true presenter is a Presentation Model, or as close as we can get in the Rails community.
[A slightly better example]
complex conditionals are dangerous to expose. How do we move them?
How do we get there?
[A better example]
How, When, What of the display for categories
Creating different presenters  for public, private, etc
Controller has logic to determine which presenter is used
Makes it testable.
Do not start with presenters. 
ONLY use this when you feel pain, e.g. can’t verify flows, etc. 
There is overhead. Should not be the same as components if we do it right.
But there is overhead when dealing with presenters.
JEG, II quote on how bad presenter code can be
[Thanks for pimping the book, Mike!]

RailsConf 2012: Aaron Patterson Keynote

“Señor Software Engineer”

[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
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?
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

“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.

RailsConf 2012: DHH Keynote


Over the past decade we’ve managed to keep a lot of people interested and active in the framework because we’ve been able to make almost constant progress.

Looking at some examples of past pain

  • Cobol
  • Java

Tell the Java programmers “Have You ever tried Shoes without Shoestrings” (Kanye sample)

We stay interested because “We make the kind of progress that makes people uneasy”

2002: REST
“I have to write routes now?”
Now we take it for granted that it’s just something that we do.

RUBY 1.9
This is the progress where we’re not even there yet
“What about all the software we have to rewrite? This is a hassle!”

[chuckles and applause from audience]
When it was introduced by Yehuda and Carl, a lot of people were not happy
Removed the pain of app setup for DHH

Upgrading to Rails 3 was hard.
It’s not just upgrading the gem.
“Why do we need Rails 3? Why do we need to change all these things?!”

It can get worse:
One of the things that made DHH most interested in working on Rails in the last two years.
A huge step forward in managing assets
“Why do we need the AP? I already have my system of five gems hobbled together?
“What’s wrong with /public?”

When you talk about progress in the abstract, it’s very easy to say “YES”
When you talk about progress that affects your world, it’s harder to say yes.

Lots of people used to writing JavaScript in a certain way
“I am used to my semicolons!!” [chuckles]

It all boils down to:
“The old one was better!”

e.g. frustration with the trackpad scrolling direction in OS X

Not all forward movement is progress
“Plenty of things you can bolt on that just add drag” [image of cheesy spoiler on a car]

How are we measuring progress? If you only look at the stopwatch, it’s not everything, but it can be a good bellwether of what’s happening


Person.find(:conditions => {:name => "David"})



Ruby 1.9 plus improvements to ActiveRecord. Much better.

Skepticism is ok, but when you go from curious to suspicious about new things, this is where bad things happen.
Becomes a negative approach to technology
It’s not just black and white, but a graduate change

Look at when people started using rails and when they switched from curious to suspicious as a broad base.
Which “vintage” of Rails are you?

Two theories:
“A conservative is a liberal who got mugged”
“Everybody likes the cutting edge until they cut themselves”

Adopting a new piece of technology and lost data, introduced a bug, or upgrading took longer than expected.
Went from being all happy about new stuff to “oh fuck. new stuff.”

Devs get chewed out “If it ain’t broke don’t fix it”
Boss/client/mental berates you: “THIS CAN NEVER HAPPEN AGAIN”
Overreaction [Image of the TSA crotch grab]

The other reason people have issues with progress: “GETTING OLD”
Not old in regards to age.
This is about the mental pattern that happens in your brain that turns your brain old in the patterns of thinking
A few people hang on to their early ideals, but there aren’t many old hippies
You turn into “Mr. Mature” who has something to lose.
“I spent all my time learning programming languages. NOW I know. Don’t tell me how things are…”

That’s the flip side of nice things.
“Don’t rock the boat too much, it’s going just in the right direction”
IN real life the hippie to mr. mature takes about 30 years.
In technology, the half life is three to five years.
Once you go to suspicious, hard to go back to curious

“Loss aversion is the pillar of conservatism”
Not political terms, but mental frames of mind.

[Video of Bill Clinton saying he experimented with pot and didn’t like it]
“Now you’re Mr. Mature, so it doesn’t suit you to admit that fact”‘

“Won’t somebody please think of the children?”
Children => “Newbies”
We have the same tendency in Technology
“All this progress is just overwhelming. Their little brains are going to go POOF!”

That’s how you come up with products like “Easy bake”
Something where the kids won’t burn themselves
They can experiment and won’t hurt themselves
“Have you ever eaten a cake that came out of an Easy Bake? They’re fucking disgusting”

DHH’s wife wanted one and her mom said no
Because they had a real oven. It’s dangerous, etc.
She actually learned a valuable skill and by the time she was 11, she was actually baking.

We need to do the same thing for actual newbies.
Progress can be hard and frustrating.
“That’s OK. It’s supposed to be. You’re learning valuable life skills that you can take on and actually use for something.”

“If we dumb things down for the newbies, we just teach them to make crap cakes.”
No one is interested in that.

“The key thing you need to learn and understand in education is that there is no speed limit.”
Derek Sievers “There is no speed limit” post from a few years back.
If people set a high expectation, it’s a natural expectation to live up to that.
If you set a low expectation, people will only rise to that level.

DHH built rails not because he thought he could, but because nobody said “you can’t”
He was moving at the pace that Derek describes. It’s an intoxicating pace that is the peak of what you can do.
Too many people put others down to a low level, which slows down the learning process

Return to being a pioneer.
You don’t need to burn the nice stuff, but refocus and reframe your mind and approach.

“Great products are made by people who use them.”
“I only care about tools that I actually USE”
Think about that when the discussion arises to dumb things down to get people onto Rails (newbies)
In direct conflict to the actual users
Only way to get newbie tools done is to pay people to do them [sounds like commentary on the recent rails drama -ed]
The path forward is NOT to get two tracks and to dumb things down for newbies

Progress is painful
It’s hard to learn new stuff when you don’t know it.
It’s harder to learn new stuff when you have to throw out understood conditions
But it hurts less if you accept that progress and change is the constant

Rails 4 will change and break things.

“I will not fear change, I will not fight progress”
Stay Young
Stay Curious
Stay Hippie, my friends. [dos equis guy]