extremely defensive coding - rubyconf edition

Transcript

1. Extremely Defensive Coding
2. a!/samphippen
3. Who is having fun?
4. Who is here for their first time?
5. I want to start with a story
6. “When is it OK to override the methods on object?”
7. I umm’d and ahh’d for a bit
8. I gave a half explanation and then asked them if they understood
9. I eventually came to an answer to do with consistency
10. Do it when it makes your object more consistent with Ruby, not less
11. e.g. an == on a data object
12. What makes a gem good?
13. Internals?
14. Internals?
15. Interface?
16. Interface? ✅
17. More convenient than if I did it myself
18. And it stays convenient
19. And it can be used by everyone on a team
20. And it works with a wide range of Ruby codebases
21. RSpec
22. RSpec Definitely always convenient
23. RSpec Definitely always convenient
24. User story
25. As an RSpec user
26. When I stub an object
27. I want the original method to be on that object after the example
28. So that my objects aren’t broken by my test suite
29. As an RSpec user
30. When I stub an object
31. I want the original method to be on that object after the example
32. So that my objects aren’t broken by my test suite
33. How does that work?
34. allow(cat).to receive(:meow)
35. Takes the meow method off cat
36. Saves it
37. Executes test
38. Puts the method back on the original object
39. How do you save a method?
41. Method object
42. Put it somewhere else
43. Put it back at end of test
44. The end
45. The end
46. Defensive coding
47. RSpec::Support .method_handle_for
48. Simply invoking the method method is not good enough
49. Some scenes may have been altered/accelerated for your viewing pleasure
50. Let’s have some questions !/samphippen sam@funandplausible.com
51. Users Lie
52. def method ‘get’ end
53. Users can redefine anything at any time in Ruby
54. and that’s fine
55. Let’s have some questions !/samphippen sam@funandplausible.com
56. Let’s have some questions !/samphippen sam@funandplausible.com
57. Instance method object Method without a target object
58. Comes from a class/module not an instance
59. Grab the Kernel implementation of #method
60. Let’s have some questions !/samphippen sam@funandplausible.com
61. Let’s have some questions !/samphippen sam@funandplausible.com
62. Users can and will redefine core methods at any time
63. Instead we use Kernel’s implementation
64. Nobody screws with Kernel
65. Ruby interpreters lie
66. Some objects do not have Kernel in their inheritance chain
68. Let’s have some questions !/samphippen sam@funandplausible.com
69. Let’s have some questions !/samphippen sam@funandplausible.com
70. Let’s have some questions !/samphippen sam@funandplausible.com
71. Rebinding module methods
72. c
73. c
74. RSpec does not support Rubinius
76. We tried, we really really tried
77. So anyway, dealing with module methods
78. Let’s have some questions !/samphippen sam@funandplausible.com
79. Let’s have some questions !/samphippen sam@funandplausible.com
80. Let’s have some questions !/samphippen sam@funandplausible.com
81. Let’s have some questions !/samphippen sam@funandplausible.com
82. Let’s have some questions !/samphippen sam@funandplausible.com
83. Let’s have some questions !/samphippen sam@funandplausible.com
84. Let’s have some questions !/samphippen sam@funandplausible.com
85. Let’s have some questions !/samphippen sam@funandplausible.com
86. Let’s have some questions !/samphippen sam@funandplausible.com
87. Let’s have some questions !/samphippen sam@funandplausible.com
88. Ruby interpreters behave differently.
89. Let’s have some questions !/samphippen sam@funandplausible.com
90. Sometimes users don’t lie
95. `method': undefined method `foo' for class `Foo' (NameError)
96. This is a catch 22
97. Solution: trust but verify
101. Let’s put it all together
103. Wrapping up
104. This is why I love RSpec
105. Please file bugs
106. Your gem should be defensive
107. Users lie Redefinitions come from anywhere, expect them
108. Ruby interpreters lie Your code will run on non-MRI, old MRI, etc
109. Sometimes users don’t lie Users are weird, trust but verify
110. What makes a gem good?
111. Internals?
112. That explanation made no sense
113. Internals?
114. Interface?
115. allow(cat).to receive(:meow)
116. You get the complexity of RSpec working with any object for free
117. You probably didn’t even know it was there until I just told you
118. Interface? ✅
119. Gems
120. Gems provide strong abstraction boundaries
121. Done badly they cause an even more extreme mess
122. Done correctly they hide huge complexity behind well defined barriers
123. Defending against users helps your gem be convenient
124. Write defensively, and your users will never know what’s inside the box
125. Remember the story?
126. This talk is born out of Ruby’s power
127. We need our code to defend today, against the mistakes of our tomorrow
128. Let’s have some questions !/samphippen sam@funandplausible.com
129. Let’s have some questions !/samphippen sam@funandplausible.com
130. Minitest Mock is 169 lines of code
131. I just showed you more code than that
132. For a tiny feature that isn’t a complete mocking library
133. and that’s fine
134. Please check out https://browserpath.co
136. Let’s have some questions a!/samphippen sam@funandplausible.com