TRIVIAL CHOICES.
When we say "convention over
configuration", we mostly mean
eliminating trivial choices.
Slide 6
Slide 6 text
■ Naming
■ Asset compilation
■ To test or not to test
■ Routing HTTP to controllers
■ File structure and architecture
TRIVIAL CHOICES.
Slide 7
Slide 7 text
MORE COMMON
CONCERNS REQUIRE
FEWER DECISIONS.
Slide 8
Slide 8 text
Rails takes a very hard line on
conventions, which forces us to solve
problems very completely. There's little
room for us to punt problems onto Rails
users.
Slide 9
Slide 9 text
CSRF PROTECTION
Slide 10
Slide 10 text
100% MANUAL.
Slide 11
Slide 11 text
{% csrf_token %}
SEMIAUTOMATIC.
Slide 12
Slide 12 text
<%= form_for @cash_transfer do |f| %>
<%= f.text_field :from %>
<%= f.text_field :to %>
<%= f.text_field :amount %>
<%= button "Transfer!" %>
<% end %> Enter Text here
AUTOMATIC.
Slide 13
Slide 13 text
Cognitive Overhead
Conventions Tools Hand-Rolled
Conventions allow you to avoid
thinking about the problem at all while
working on features.
Tools make the problem easier to solve,
but still make you think about it.
When we don't have a convention for
something, we end up forcing the
developer to learn about the problem
and choose a solution, which is most of
the cognitive overhead of solving it
yourself.
Slide 14
Slide 14 text
The common conventions of Rails
applications provide a foundation for
additional abstractions.
Slide 15
Slide 15 text
COURSE
CORRECTIONS
No interest in cosmetic, no time for
refactoring.
Interested in figuring out why my
clients don't want me to use Rails.
Slide 16
Slide 16 text
MANY PEOPLE
HAVE A PROBLEM.
Criteria for course corrections
Slide 17
Slide 17 text
MANY PARTS OF THE
SOLUTION ARE
TRIVIAL.
REST:
What HTTP structure should I use?
What names should I give my methods?
How should I generate URLs?
Slide 18
Slide 18 text
THERE IS BENEFIT IN A
SHARED SOLUTION.
Asset pipeline:
* Works out of the box
* Reduces cost of entering a project
* Concept of "Rails asset processor"
Slide 19
Slide 19 text
LEARNING ABOUT
THE PROBLEM IS
HARD.
Encodings, Security, ETags
Slide 20
Slide 20 text
FAILURE TO SOLVE
IN RAILS CORE.
What are the problems for failing to
provide solutions in Rails core.
Flip side of what I just said.
Slide 21
Slide 21 text
CRITICAL MASS.
Having multiple competing solutions
robs any one solution of the critical
mass it needs to rapidly improve.
No initial implementation is perfect,
and Rails provides eyeballs and hands.
Slide 22
Slide 22 text
USAGE.
It's tempting to say "let this feature be
a plugin, and we'll let our users flesh it
out before we include it"
This often results in several competing
solutions, each languishing with few
users, all of which have major issues.
The lack of usage can also hide
conceptual problems with an approach
(heroku deployment?)
Slide 23
Slide 23 text
INTEGRATION.
When users pick a solution on their
own, they are willing to put up with a
lot of manual work. The process of
integrating a feature into Rails to
automate it often brings fundamental
problems to light.
Slide 24
Slide 24 text
ECHO CHAMBER.
The people most likely to choose a plugin solution to a
problem also understand it the most. This means that
there is little impetus to provide completely transparent
solutions that work without complete (or any) knowledge
of the underlying problems. By making something a Rails
concern, it immediately busts the echo chamber of those
who already understand the problem.
Slide 25
Slide 25 text
TECHNICAL DEBT.
As Aaron said yesterday, when solving
these larger issues, we have a larger
tolerance for technical debt.
That said, we shouldn't throw caution
to the wind and take on unlimited
debt. At this point, we're still paying
back our last emergency loan, so let's
be more prudent now.
Slide 26
Slide 26 text
GOOD ARCHITECTURE
ENABLES FUTURE
FEATURES.
Architecting well means that we can
easily improve the feature in the
future. Many of the good things in
the Rails 3 architecture
(notifications) have only come to
fruition now.
Slide 27
Slide 27 text
FEATURES NOW + FEATURES LATER
COST NOW + MAINTENANCE
÷
Slide 28
Slide 28 text
FEATURES NOW + FEATURES LATER
COST NOW + MAINTENANCE
÷
Building a feature right lets us extend
it easily in the future with lower
maintenance costs. This allows us to
make necessary investments more
easily in the future.
Slide 29
Slide 29 text
BETS
When we correct course, we are
placing a bet about the future of our
industry.
Slide 30
Slide 30 text
BETTING ON REST.
Slide 31
Slide 31 text
■ Early support for rich HTTP semantics
■ Powerful router (request constraints, ...)
■ Content negotiation (Accept, $.getJSON)
■ Baked-in MIME types
■ HTTP caching ("Conditional GET")
■ JSON parameters
■ Security (e.g. IP spoo ng)
WINS OF REST.
Slide 32
Slide 32 text
RAILS HAS A GREAT
HTTP FOUNDATION.
Slide 33
Slide 33 text
BUT...
Slide 34
Slide 34 text
DATA
TRANSPORT
Slide 35
Slide 35 text
SQL DATABASE
Slide 36
Slide 36 text
■ Primary key: chosen per table
■ Table name: chosen per table
■ Timestamps: chosen per timestamp
■ Polymorphic tables: ad hoc setup
■ Foreign keys: chosen per relationship
■ Camel/Underscore: chosen per eld
BEFORE RAILS.
Slide 37
Slide 37 text
Because of all of these discrepancies,
you end up needing to build a map of
your database for your application.
Slide 38
Slide 38 text
"DATABASES ARE
TOO DIFFERENT"
In the early days of Rails, we heard a
lot of arguments that databases were
simply too different for AR to be more
than just a toy. We hear similar
arguments today with APIs.
Slide 39
Slide 39 text
JSON APIS.
Slide 40
Slide 40 text
■ Should responses include a root?
■ How to embed associations?
■ Include the identi er? In what form?
■ id or href?
■ Include additional/associated resources?
■ How to update in bulk?
■ Primary key de ned on server or client?
■ Moving a belongs_to record?
JSON APIS.
Just like there were questions in SQL,
there are questions in JSON APIs.
Slide 41
Slide 41 text
STANDARDIZED
CLIENT CODE.
Without standardization, we cannot
easily build standardized code on the
client.
Slide 42
Slide 42 text
We're also back to making the same
trivial decisions over and over again,
if we even realize that we are
making decisions.
Slide 43
Slide 43 text
And because we're not taking on the
problem, we're pushing the concerns
onto every client.
Slide 44
Slide 44 text
IS RAILS WORTH IT?
Since Rails doesn't provide these conventions,
people are asking "Is Rails the right tool for the job"
Even though other tools don't provide conventions,
Rails is all about CoC, so the lack of conventions
makes *Rails* feel like the wrong tool for the job,
even though much of Rails is still useful.
Rails starts feeling more like a very polished
library and less like a framework.
Slide 45
Slide 45 text
ACTIVEMODEL
SERIALIZERS.
Slide 46
Slide 46 text
What to Serialize
• Which attributes
• Which associations
How to Serialize
• Include a root?
• Associations?
• Extra data?
• Avoid duplication!
Slide 47
Slide 47 text
class PostSerializer < ApplicationSerializer
attributes :title, :body
belongs_to :author
has_many :comments
end
WHAT TO SERIALIZE.
Slide 48
Slide 48 text
class PostSerializer < ApplicationSerializer
attributes :title, :body
belongs_to :author
has_many :comments
def comments
comments = post.comments
return comments if scope.admin?
comments.where(hidden: false)
end
end
CUSTOMIZE.
Slide 49
Slide 49 text
class ApplicationController
embed :ids, include: true
end
HOW TO SERIALIZE.
AVOID MIXING
COMMON AND
UNCOMMON.
The advantage of serializers is that
it avoids mixing the common
(representation) with the unique
(attributes, associations)
This is in contrast with builders,
which put the common and unique
things in one place, so we have no
place for conventions.
Slide 56
Slide 56 text
CONFIGURABLE.
Especially for authorization, there is
a need to be able to poke under the
declarative hood. It's not all
documented, but it works.
Slide 57
Slide 57 text
class PostSerializer < ApplicationSerializer
attributes :title, :body
has_many :comments
has_many :troll_ratings
# override just default association inclusion
def include_associations!
comments = post.comments
unless scope.can(:see_hidden, post)
comments = comments.where(visible: true)
end
# override default value, but not embedding rules, etc.
include! :comments, value: comments
# conditionally include an association
include! :troll_ratings if scope.can(:troll_rate, post)
end
end
AUTHORIZATION.
Slide 58
Slide 58 text
WAS IN RAILS.
Slide 59
Slide 59 text
REVERTED. WHY?
Slide 60
Slide 60 text
EMBER-RAILS.
ember-rails was trying to build a
transparent data transport and it
was hard for arbitrary Rails
applications.
Slide 61
Slide 61 text
GENERATE A MODEL,
GET A SERIALIZER
AND EMBER-DATA
MODEL.
var people = App.Person.all();
/* GET /people */
// later...
var first = people.objectAt(0);
first.set('firstName', "Brohuda");
App.store.commit();
/* POST /person/1 { ... } */
TRANSPARENT.
Slide 66
Slide 66 text
Transport
Client Side
Serialization
AMo::Serializers solve serialization, but I
think we need a general solution for all
three.
Slide 67
Slide 67 text
BULK.
Serializers doesn't solve this, but there is a
need to define conventions around bulk
updates.
ember-data defines conventions that, if
implemented in Rails, "just work"
Slide 68
Slide 68 text
OTHER DATA
FEATURES.
Identity map; data binding to the
view; associations (including create
parent=>child=>persist)
Slide 69
Slide 69 text
CONVENTIONS FOR
APPLICATION
STRUCTURE.
Beyond "put your JS here"
Slide 70
Slide 70 text
TRIVIAL CHOICES ARE
THE ENEMY.
Slide 71
Slide 71 text
NODE?
Slide 72
Slide 72 text
Back in 1995, we knew something that I don't think
our competitors understood, and few understand
even now: when you're writing software that only
has to run on your own servers, you can use any
language you want. When you're writing desktop
software, there's a strong bias toward writing
applications in the same language as the operating
system. But with Web-based software, you can use
whatever language you want.
“
PAUL GRAHAM
Slide 73
Slide 73 text
This new freedom is a double-edged sword,
however. Now that you can use any language, you
have to think about which one to use. Companies
that try to pretend nothing has changed risk nding
that their competitors do not.
“
PAUL GRAHAM
Slide 74
Slide 74 text
TRANSPORT.
Standards and
Conventions
• HTML
• ActiveRecord
Same Language
Everywhere
• JMS
• DRb
Thinking "I need to talk with JS,
therefore I need to write JS on the
server" is pretty lazy thinking. We can
get seamlessness without insisting on
the same language everywhere.
Slide 75
Slide 75 text
TRANSPORT.
Standards and
Conventions
• HTML
• ActiveRecord
Same Language
Everywhere
• JMS
• DRb
>
Thinking "I need to talk with JS,
therefore I need to write JS on the
server" is pretty lazy thinking. We can
get seamlessness without insisting on
the same language everywhere.
Slide 76
Slide 76 text
RECAP
Slide 77
Slide 77 text
■ Good conventions save developers from
having to agonize over common problems.
■ Rails' bet on REST gave it a leg up in many
areas that are relevant to rich client apps.
■ There is still room for improvement: we can
make APIs as transparent as ActiveRecord.
■ ActiveModel::Serializers is one approach we
are looking at to get us there.
■ We can also make browser frameworks better
through the same conventions.
RECAP.