Slide 1

Slide 1 text

The Next Five Years RAILS

Slide 2

Slide 2 text

THE LAST FIVE YEARS

Slide 3

Slide 3 text

WHY DO WE LIKE RAILS?

Slide 4

Slide 4 text

"CONVENTION OVER CONFIGURATION"

Slide 5

Slide 5 text

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.

Slide 50

Slide 50 text

{ posts: [ { "id": 1, "title": "First", "person_id": 1 }, { "id": 2, "title": "Next", "person_id": 1 }, { "id": 3, "title": "More!", "person_id": 1 } ], people: [ { "id": 1, "name": "Yehuda Katz" } ] } AVOID DUPLICATION.

Slide 51

Slide 51 text

ANY CONVENTION IS BETTER THAN NO CONVENTION.

Slide 52

Slide 52 text

DEMO.

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

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.

Slide 62

Slide 62 text

REST ADAPTER.

Slide 63

Slide 63 text

App.store = DS.Store.create({ revision: 4, adapter: "DS.RESTAdapter" }); REST ADAPTER.

Slide 64

Slide 64 text

App.Post = DS.Model.extend({ title: DS.attr('string'), body: DS.attr('string'), comments: DS.hasMany(App.Comment) }); App.Comment = DS.Model.extend({ body: DS.attr('string'), post: DS.belongsTo(App.Post) }); MODELS.

Slide 65

Slide 65 text

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.

Slide 78

Slide 78 text

THANKS! @WYCATS