Modernizr: Why We Do The Config We Do

In The Rails View (page 23 for those of you following along at home) we cover how to roll your own version of the Modernizr library, but we don’t really dive into which items you want to use in that library. The list of potential items keeps growing and can be somewhat overwhelming at times. We can’t possibly cover every piece of this framework, so if there’s something you’re curious about, we suggest that you deep dive on the Modernizr documentation.

How does Modernizr do the things it does? Well, in the documentation it’s explained as:

For a lot of the tests, Modernizr does its “magic” by creating an element, setting a specific style instruction on that element and then immediately retrieving it. Browsers that understand the instruction will return something sensible; browsers that don’t understand it will return nothing or “undefined”.

Let’s look at the options on the custom build page and see what we may need.

The Core

The core pieces that we absolutely need are actually listed under the “Extra” heading on the right side of the grey area. The html5shiv is a tool that allows “the use of HTML5 sectioning elements in legacy Internet Explorer, as well as default HTML5 styling in Internet Exporer 6-9, Safari 4.x (and iPhone 3.x), and Firefox 3.x.” The end point of the shiv is that it allows us to use HTML5 elements in almost any production site by telling the DOM that they exist and letting us print and style those HTML5 elements. If you need printing, you need to select the “w/printshiv” option.

The other part of the Modenizr core is YepNopeJS, which is a simple javascript that detects for a condition (if something can be handled by the browser) and applys one class if yes and another if no. It can be used in its native form to serve certain files based on that condition. This loader is optional and around 3k in size. It gives you access to the Modenrizr.load() function, so if you want that, you need to have this checked.

We also use Media Queries in many of our sites, so we want to turn that on as well. That covers the “Extra” section (which I would call the “core” section) and from there, it’s not too complex. This is effectively Respond.js, so if you want to use that outside of Modernizr, you can do so.

The last is “Add CSS classes” and it will add CSS classes to your HTML tag for the page. If you want to do support detection for CSS3 features, you need to check this.


The CSS3 section contains detection and support for various CSS3 elements. If you plan to use them, you should include them. For the book, you really only need @font-face, CSSGradients, box-shadow, and rgba(). The rest are fun to play with, and as your view skills grow you will find yourself using many of these.

The HTML5 area is actually not the HTML5 tags, as those were activated with the HTML5Shiv discussed in “The Core” above. This area includes those elements that are more part of the extended family of technologies that make up “HTML5”. The only things we discuss in the book are the Input Attribtutes and Input Types (both discussed in the Forms chapter).

Remember that each item you add increases the size of this file and is another test that is running on each page load.

Misc. & Add-ons

At this point, if you’re diving into these items, you’re probably pretty familiar with polyfills, modernizr, and the like. This gives you access to some of the more complex (or just fun) items available in some browsers. If you’re interested in switching to box-sizing: border-box then you probably want to check that polyfill off.

For almost anything that can be detected, someone has created a polyfill for it. Remember, if you don’t need to support older browsers, then many of these things are simply noise.

Finally for further reading, The 2010 article by Faruk Ateş entitled “Taking Advantage of HTML5 and CSS3 with Modernizr” at A List Apart is an excellent resource on pragmatically approaching the use of this tool.

Good luck!

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:
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: The Future of Sass

Talk by @hcatlin

Where he’s been?
Was doing lots of cool stuff, but not telling anyone
Burn out.
Wikipedia iPhone app
1.8 billion monthly page views
Dictionary app
Search as you type & sound-alike
Sass is all headed up by @nex3 and @chriseppstein
Let’s clear some things up
.scss is the extension to Sass files
Indented Sass will remain supported, but scss is the markup style
It’s Sass not SASS
It’s a “backronym” not an “acronym”
Sass 3.2

Placeholder Selectors
#context a.%stronglink {
  color: red;
  font-weight: bold;
.highlight {
  @extend %stronglink;
#context a.highlight {
  color: red;
  font-weight: bold;
% in selector will never print out. So you can start with that and use it elsewhere in your file.
Mixin Content
aka “Blocks for Mixins”
@mixin iphone {
  @media only screen and (max-width: 480px) [
@include iPhone {
  body { color: red; }
@media only screen and (max-width: 480px) {
  body { color: red; }
@content is effectively the same as “yield”
Load Paths

Initialized via ENV[“SASS_PATH”]
Great for a shared library trove
Compass will use this in the future
1.8.7 is now the minimum Ruby usable
&foo is gone, but & foo is ok (must have a space)
Use @extends instead of this
“One More Thing”
Pros and Cons
Sass is (pros):
  • Mature
  • Advanced (not many undoable things)
    • Units
    • Functions
    • Selector inheritance
  • Accessibility 
    • getting designers to use command line, setup GUIs on the side, difficult to get up and running
    • Less won on this one with Javascript drop and run
  • Speed
    • Moovweb has over 50k lines of Sass
    • average 30 seconds to compile, caching helps here
Announce: SassJS (kidding)
Really: libsass; implemented Sass in C.
Aaron Leung (@akhleung) built this
C interface, C++ internals
Statically linkable
Simple interface
Sass 3.1 features currently, 3.2 coming eventually
Development was sponsored by Moovweb
Less than 2 months in
More features than expected
Adapters needed!
Mixins just work
Variables are good
Most conversions
Simple interpolations (some edge cases don’t work)
Most functions work (problems with color functions)
Coming soon (0.2+)
Selector inheritance
Full Interpolation
All units
Color functions
Control directives @if
Callback API
Benchmarks MUCH faster. ~100 Milliseconds compared to seconds
./bin/sassc interpolation.scss > file.css
SassC is an executable project wrapper around Libsass
Plan to have SassRuby, SassPython, and SassJS all wrap around libsass
SassPython and SassJS don’t exist yet, but the they are wanted
SassGo is another he wants
Integrating C API

struct sass_context* ctx = sass_new_context();
ctx->input_string = “div {width: 30px;}”;
ctx->options.output_style = SASS_STYLE_NESTED;
[overview of C structs]
Make web design have the same level of tools of software development
How you can help
Color Functions (if you know C/C++)
Help on SassRuby

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]

Date Picker has landed in Chrome

If you’re playing with Chrome Canary or Chromium, you can now abuse some new HTML5 form element hotness: the Date picker.

<input type="date" min="2010-08-14" max="2012-08-14" value="2010-08-14"/>

This will give you a pre-styled element that looks like this:

example image from the author

You will notice that dates that fall before the “min” range are disabled and that the “value” uh, value shows up as a highlighted, pre-selected date.

Paul Irish replied in the comments that this does not currently support styling as there’s great discrepancies between how different browsers (mobile vs desktop) handle these elements, so if having those stylings is important to you, you probably want to stick with jQuery for now.