Rails As She Is Spoke

A presentation I gave at the LA Ruby meetup in May 2013.

Transcript

1. this might be a little advanced I might go kind of fast
3. ENGLISH AS SHE IS SPOKE
4. ENGLISH / PORTUGESE PHRASEBOOK
5. UNAUTHORIZED TRANSLATION
6. FRENCH / PORTUGESE PHRASEBOOK
7. PEDRO CAROLINO
8. SPOKE NO ENGLISH he definitely spoke no english
9. SPOKE NO FRENCH it’s possible that he also spoke no french
10. a sampling of familiar phrases
12. so I did this
13. s/DHH/Rails/g caveat
14. a book about all the ways Rails gets OOP wrong and why it works anyway caveat
16. GILES BOWKETT but I am not Pedro Carolino.
17. SPOKE SOME RAILS I knew this language that I was writing about
18. url_for # Rails 3.2 for instance, I knew this interesting fact
19. 5DIFFERENT METHODS NAMED url_for (in Rails 3.2) 5 different methods with this same name
20. 0CLASSES NAMED URL (in Rails 3.2) 5 different methods with this same name
21. module Foo1 def url_for # url logic end module Foo4 end def url_for # url logic module Foo2 end def url_for end # url logic end module Foo5 end def url_for # url logic module Foo3 end def url_for end # url logic end end this happens five times
22. class URL # url logic end this does not happen once. and it does seem like the simplest question ever
23. SHOULD A WEB FRAMEWORK MODEL URLS? that does seem like the simplest question ever
24. MAYBE NOT ...
25. “In Ruby, everything is an object and this unembarrassed object- orientation gives Ruby much of its power and expressiveness. […] In Rails, however, sadly, there are large swathes which are not object oriented, and in my opinion, these areas tend to be the most painful parts of Rails.” this is mostly true, especially if you’re talking about weird corners of the Rails internals
27. url_for :controller => :foo, :action => :bar, :et => :cetera
28. url_for controller: foo, action: bar, et: cetera
29. (url_for (controller foo) (action bar) (et cetera))
30. LISP-LIKE ...
31. “In Ruby, everything is an object and this unembarrassed object- orientation gives Ruby much of its power and expressiveness. […] In Rails, however, sadly, there are large swathes which are not object oriented, and in my opinion, these areas tend to be the most painful parts of Rails.”
32. “In Ruby, everything is an object and this unembarrassed object- orientation gives Ruby much of its power and expressiveness. […] In Rails, however, sadly, there are large swathes which are not object oriented, and in my opinion, these areas tend to be the most painful parts of Rails.” I mostly agree with this. but only MOSTLY.
33. (url_for (controller foo) (action bar) (et cetera)) this code here is...:
34. NOT PURELY OBJECT- ORIENTED
35. NOT THE MOST PAINFUL PART OF RAILS EITHER when you ignore a really obvious, practical OOP choice like creating a URL class, and you instead create Lisp-like code, you’re probably going to be able to get away with ignoring the obvious, practical OOP choice.
36. OOP VS HACK CITY most people, when they talk about object-oriented principles, they contrast with code that has no structure at all.
37. OOP ALWAYS WINS so in these discussions, oop always wins.
38. NOT FAIR! but it’s not a fair game.
39. OBJECT- ORIENTED Ruby is very object-oriented
40. FUNCTIONAL PROGRAMMING Ruby also has terrific support for functional paradigms and is intended to be a multi- paradigm language
41. (url_for (controller foo) (action bar) (et cetera)) this itself is not functional programming, but it does show the influence of Lisp cascading down from Ruby into Rails.
42. matz, creator of ruby
43. matz, creator of ruby
44. matz, creator of ruby
45. here’s an email from Matz explaining how Lisp influenced the design of Ruby
47. this itself is not functional programming, but it does show the influence of Lisp cascading down from Ruby into Rails.
48. so you may remember I wrote a book
49. a book about all the ways Rails gets OOP wrong and why it works anyway and it’s about Rails getting OOP wrong
50. a book about why Rails uses OOP at times but chooses not to at other times except it’s really about this
51. ENGLISH AS SHE IS SPOKE so going back to english as she is spoke
52. It isn't the season for them, but the apricots will soon be ripe. english
53. It is not the season yet; but here is some peaches what does ripen at the eye sight. as she is spoke
54. It is not the season yet; but here is some peaches what does ripen at the eye sight. peaches aren’t even the same food as apricots
55. It is not the season yet; but here is some peaches what does ripen at the eye sight. just plain doing it wrong
56. RAILS TESTING and that’s what Rails testing is like
57. there’s a guy called Michael Feathers. he wrote one of the best books on code ever.
58. there’s a guy called Michael Feathers. he wrote one of the best books on code ever.
59. there’s a guy called Michael Feathers. he wrote one of the best books on code ever.
60. A test is not a unit test if: • It talks to the database • It communicates across the network • It touches the file system • It can't run at the same time as any of your other unit tests • You have to do special things to your environment to run it. and he said this about testing
61. A test is not a unit test if: • It talks to the database • It communicates across the network • It touches the file system • It can't run at the same time as any of your other unit tests • You have to do special things to your environment to run it.
62. A test is not a unit test if: • It talks to the database has anyone in here ever written a unit test which talked to a database?
63. When you pull the database, sockets, or file system access into your unit tests, they aren’t really about those methods any more; they are about the integration of your code with that other software. and he said this about testing
64. When you pull the database, sockets, or file system access into your unit tests, they aren’t really about those methods any more; they are about the integration of your code with that other software. and he said this about testing
65. INTEGRATION TESTING the good news is that this is an actual thing. integration testing is a thing and a thing worth doing.
66. “INTEGRATION TESTING” the bad news is that Rails already uses this term to describe something else
67. I’m not even going to get into all the ways Rails gets testing terminology hopelessly confused
68. but if you’re curious you should check out “fast rails tests” has anyone here ever had problems with slow Rails tests?
69. COREY HAINES: “FAST RAILS TESTS” you should google it
70. 10 he had specs that ran in 10 seconds with Rails
71. 0.39 he took Rails out of the picture and wrote true unit tests in the Michael Feathers sense. they ran in 0.39 seconds.
72. DECOUPLING THE FRAMEWORK the theme here is decoupling the framework from your application
73. destroy all software
74. DESTROY ALL SOFTWARE: “FAST TESTS WITH AND WITHOUT RAILS” you should google it
75. 6 he had specs that ran in 6 seconds with Rails
76. 0.15 he took Rails out of the picture and wrote true unit tests in the Michael Feathers sense. they ran in 0.15 seconds.
77. he also gave this terrific free presentation 8 controller responsibilities just on this slide
78. DECONSTRUCTING THE FRAMEWORK that talk is called...
79. love love love
80. love love love
81. SINGLE RESPONSIBILITY PRINCIPLE Rails breaks this like crazy
84. copeland gives another example
85. class UsersController < ApplicationController def create @user = User.new(params[:user]) respond_to do |format| if @user.save UserMailer.deliver_welcome_email(@user) end end end end
86. class UsersController < ApplicationController def create @user = User.new(params[:user]) respond_to do |format| if @user.save UserMailer.deliver_welcome_email(@user) end end end end
87. class UsersController < ApplicationController def create @user = User.new(params[:user]) respond_to do |format| if @user.save UserMailer.deliver_welcome_email(@user) end end end end
88. class UsersController < ApplicationController def create @user = User.new(params[:user]) respond_to do |format| if @user.save UserMailer.deliver_welcome_email(@user) end end end end 1: CREATE NEW USER INSTANCE
89. class UsersController < ApplicationController def create @user = User.new(params[:user]) respond_to do |format| if @user.save UserMailer.deliver_welcome_email(@user) end end end end 2: SAVE USER TO DATABASE
90. class UsersController < ApplicationController def create @user = User.new(params[:user]) respond_to do |format| if @user.save UserMailer.deliver_welcome_email(@user) end end end end 3: SEND A WELCOME EMAIL
91. class UsersController < ApplicationController def create @user = User.new(params[:user]) respond_to do |format| if @user.save UserMailer.deliver_welcome_email(@user) end end end end 4: RENDER A TEMPLATE ? which isn’t even in the code anywhere
92. TESTING: RAILS IS JUST WRONG but here’s the thing
93. EVERYONE KNOWS IT nobody who is good at Rails takes the Rails testing approach seriously with the exception of DHH. it’s a joke.
94. BUT RAILS POPULARIZED TDD that’s worth something. before Rails it was hard to even persuade a lot of people to take TDD seriously in the first place. now everybody knows they need to do it. so maybe there’s more to the story.
95. worse is better. it’s a thing. google it.
96. RAILS VS SRP and maybe Rails is right about SRP too
100. CLASS != OBJECT why did he say class? we’re not talking about class-oriented programming. we’re talking about object-oriented programming.
101. the history of object-oriented programming is dominated by clumsy, class-based languages like Java, where that distinction was immaterial. but with Ruby, we have more flexibility.
102. There should never be more than one reason for a class to change. let’s talk about how to parse this sentence
103. There should never be more than one reason for an object to change. and compare it to this sentence
104. foo = String.new class << foo def bar 42 end end foo.bar # => 42 this is 100% valid Ruby where you add a method to an object without adding it to a class. I hope it’s obvious that transformations of this nature do not make it effortless to reason about your software coherently.
105. class UsersController < ApplicationController def create @user = User.new(params[:user]) respond_to do |format| if @user.save UserMailer.deliver_welcome_email(@user) end end end end you never see this on day-to-day Rails work, but the code which gets @user from here out into your view is working at a similar level of crazy
106. class UsersController < ApplicationController def create @user = User.new(params[:user]) respond_to do |format| if @user.save UserMailer.deliver_welcome_email(@user) end end end end you never see this on day-to-day Rails work, but the code which gets @user from here out into your view is working at a similar level of crazy
107. class UsersController < ApplicationController def create @user = User.new(params[:user]) respond_to do |format| if @user.save UserMailer.deliver_welcome_email(@user) end end end end you never see this on day-to-day Rails work, but the code which gets @user from here out into your view is working at a similar level of crazy
108. There should never be more than one reason for a class to change. that’s not this
109. There should never be more than one reason for an object to change. it’s not this, either
110. There should never be a really weird reason for an object to change. it’s outside the entire universe of the Single Responsibility Principle
111. CLASS == OBJECT in Java you can treat these terms identically. in Ruby, you can’t.
112. CLASS != OBJECT CLASS == OBJECT in Java you can treat these terms identically. in Ruby, it might not be as wise.
113. CLASS == OBJECT CLASS != OBJECT the irony of course is that the way the languages work is exactly the opposite
114. Class.is_a? Object # => true // you can’t even // ask, but the // answer’s no
115. this is another iceberg
116. I like icebergs, because they keep penguins busy. and I love penguins!
117. but here we have to summarize.
118. DYNAMIC LANGUAGES the point is that dynamic languages may require different rules
119. Class.is_a? Object # => true in Ruby you may actually have to differentiate between the reasons for a CLASS to change and the reasons for an OBJECT to change
120. Class.is_a? Object # => true # redefine class # Foo to be class # Bar Foo = type(‘Foo’, (Bar)) in Python you can change an object’s class at runtime, or redefine a class to be another class
121. __class__ python exposes a __class__ semi-secret variable and if you know what you’re doing you can basically do anything you want with it. it’s a little bit crazy.
122. don’t even get me started on JavaScript.
123. I love JavaScript.
124. 3.weeks.from_now here’s another example
125. class Fixnum def weeks end end Rails implements that by adding a method called weeks to Fixnum
126. A NUMBER IS RESPONSIBLE FOR REPRESENTING ITSELF AS A SPAN OF TIME
127. EPIC SRP FAIL
128. “In Ruby, everything is an object and this unembarrassed object- orientation gives Ruby much of its power and expressiveness. […] In Rails, however, sadly, there are large swathes which are not object oriented, and in my opinion, these areas tend to be the most painful parts of Rails.” again I have to disagree!
129. NOT PURELY OBJECT- ORIENTED again
130. NOT THE MOST PAINFUL PART OF RAILS EITHER but a really nice convenient API
131. 3.weeks.from_now this is what we use today
132. # 3 weeks from now Time.now + (3 * 7 * 24 * 60 * 60) this is what we used to do
133. There should never be more than one reason for a class to change. so this, to some extent, is classic thinking, but also, to some extent, legacy thinking. it’s a good rule of thumb. you should DEFINITELY give it serious consideration and it very often leads to good code. but you can’t be fanatical about it either. OOP zealotry is not the way to understand Rails.
134. CONFUSED? by the way I apologize if this presentation is confusing
135. this is also confusing we talk a lot about idiomatic ruby, but we don’t talk enough about idiotisms
136. IDIOTISMS the best way to talk about idiotisms would be to talk about ActiveRecord
137. this is another iceberg
138. I think I mentioned I wrote a book
139. 100% LEGIT CHAPTER TITLE... this is true
140. “WHAT THE **** IS THE DEAL WITH ACTIVERECORD?” this is true
141. IDIOTISMS apologies for the bad language, but ActiveRecord is full of idiotisms
142. INHERITANCE: IT’S A FACTORY ActiveRecord hides an absolutely classic example of the Factory design pattern inside its inheritance mechanics for no other reason that I can ascertain, other than that it happens to look cool
143. INHERITANCE: STI, WTF single-table inheritance also breaks Ruby inheritance in ActiveRecord models broken going up, broken going down
144. 10s -> 0.39s if you want fast development, you need ActiveRecord out of your domain models
145. 6s -> 0.15s and plenty of very successful Rails hackers take ActiveRecord out of their domain models
146. class User < ActiveRecord::Base # domain logic # database interaction end you might start here
147. class User # domain logic end class UserRecord < ActiveRecord::Base # database interaction end and end up here and it’s a huge improvement if the previous version was thousands of lines long - which happens!
148. but there’s a problem. this is the Active Record pattern
149. Active Record (DESIGN PATTERN) ActiveRecord (RUBY GEM)
150. the essence of Active Record the pattern is that you couple domain logic to database access
151. 10s -> 0.39s but that’s not what Corey Haines does
152. 6s -> 0.15s it’s not always what Gary Bernhardt does either
153. Active Record (DESIGN PATTERN) ActiveRecord (RUBY GEM) these guys use ActiveRecord without using Active Record. and when people try and talk about that technique, they get tied up in knots.
154. Should we use Active Record (DESIGN PATTERN)? because some people will answer this question NO
155. Should we use ActiveRecord (RUBY GEM)? even though they answer this question YES - AT THE SAME TIME
156. “ACTIVE RECORD” if you can use ActiveRecord (the gem) without using Active Record (the design pattern), then it’s not really Active Record (the design pattern).
157. LIES AND PROPAGANDA maybe Rails is trolling us
158. GENUINE CONFUSION maybe Rails is genuinely confused
159. IMPECCABLE DEV UI either way, Rails provides fantastic user experience
160. IMPECCABLE DEV UI so we love Rails
161. here’s david heinemeier hansson presenting the revolutionary idea that if you want to put a button on the screen, your code should just be like, “button.”
162. and we love him too
163. WRITING CODE CAN BE EASY IF WE MAKE IT EASY this is one of the amazingly obvious insights behind Rails’s success. and the way you make it easy is by writing code! Rails is full of code which exists purely to make the experience of building applications a PLEASANT one. and that is SO IMPORTANT.
164. ask stripe! it’s their entire business model. make it enjoyable to develop applications.
165. 1. MAKE IT FUN TO BUILD STUFF 2. ??? 3. PROFIT!
166. DEVELOPER USER EXPERIENCE MATTERS one of the most important lessons of Rails is that crafting a productive, enjoyable user experience for the developer is an incredibly effective move
167. so by the way, I wrote a book
168. FREE and you can have it for free, tonight only
169. but I didn’t want it to go on twitter. plus I forgot to set it up.
170. gilesb@gmail.com railsoopbook.com so email me about it. CAVEAT! you have to email me tonight. if you don’t remember until tomorrow, sorry, no deal.