Be Awesome By Being Boring

Boring technology is awesome. The more boring, the better. It's less shiny, but you get to spend all your time writing code and building new things that actually work, and that's the most exciting part anyway!

Come to this talk and you'll walk away armed with simple, proven tools that can save you countless hours of wrestling with problems that have been solved for decades. We'll cover specific examples of existing network protocols and unix utilities that can serve the same purposes as trendy new approaches, letting you get on with the business of writing the code you actually want to write instead of spinning your wheels trying to integrate a bunch of bleeding edge technologies. On the other hand, sometimes you really do need something new, so we'll discuss the limitations of the simple solutions, and explore some criteria to evaluate whether the benefits of throwing in the new hotness outweigh the risks, as well as strategies to mitigate those risks when it does turn out to be warranted.

Embrace boring. Build simpler, more reliable code, and experience the joy of shipping a working product in less time than it takes to get your Mongular DirectiveBase talking to the ClojThrift.js componoids (much less writing any actual code).

If you would like the original Keynote file with the speaker notes, you can find it at taterbases.com.

Transcript

1. Be Awesome By Being Boring John Hyland
2. Table of Contents I. Introduction II. Boring Technology is Best Technology III. When To Use Shiny Tech IV. How To Handle The Hotness (if you must) V. Conclusion
3. I. Introduction
4. Hi, I’m John.
5. Hi, I’m John. (Senior Beardy Man / Boring Old Guy)
6. II. Boring Technology is Best Technology
7. “Standard is better than better.”
8. It’s stable.
9. It’s well understood.
10. It’s easy to hire for.
11. It’s easy to hire for. (You probably already have.)
12. It’s easy to google.
13. It’s easy to google. (In fact, most of the problems you would have googled are already fixed.)
14. It’s easy to google. (See above, re: “It’s stable.”) (In fact, most of the problems you would have googled are already fixed.)
15. It’s interoperable.
16. It just works.
17. Hot new technology can burn you.
18. Nobody at your organization knows how it works.
19. It might change out from under you.
20. There may not be standard usage patterns.
21. ⌂
22. ⌂
23. ⌂
24. ⌂
25. ⌂
26. ⌂
27. ⌂
28. ⌂
30. ?
31. There won’t be any tooling for it.
32. There won’t be any tooling for it. Or, if you’re lucky(?), there might be some bad tooling.
33. It’s going to be a security wild card.
34. It’s going to have more bugs.
35. It’s going to have more rough edges.
36. It might turn out to be Mongo.
37. III. When To Use Shiny Tech
38. Context Matters
39. The Spectrum of Acceptable Shininess
40. Personal side projects
41. Go nuts! The shinier the better!
42. Internal Tools
43. Great for dipping your toe in the exciting water.
44. Customer-Facing Production Code
45. Only if you need it to solve a specific problem.
46. "I think it's a better fit" is never good enough.
47. When you have a problem there is no boring solution to.
48. When the new hotness is just so darned hot that it’s worth it.
49. IV. How To Handle The New Hotness
50. (if you must) IV. How To Handle The New Hotness
51. Roll it out slowly.
52. Standardize your usage.
53. Use it for the purpose it was meant for.
54. Problems don’t add up, they multiply.
55. V. Example Time
56. You are now entering The Subjective Zone.
57. The next-generation multi- homed cloud-based potato storage solution.
58. taterbases.com
59. taterbases.com (Thanks @tenderlove!)
60. (By the way, that website doesn’t exist.)
61. taterbases.com is (obviously) serious business.
62. Ok! Let’s get started.
63. Decision 1
64. Programming Language
65. The Boring Option
66. Assembly
67. Ruby! :-D
68. Java, C, Python, any of that stuff is obviously fine.
69. (Well, from a maturity perspective, anyway.)
70. When to use something else.
71. It needs to run in the browser.
72. JavaScript is ALL YOU GET.
73. Go, Rust, Elixir, etc, are probably not mature enough for production.
74. We can write code, but we need to store potata data.
75. Decision 2
76. Tatabase
77. Database
78. The Boring Option
79. “Just use Postgres.”
80. When to use something else.
81. You’re processing giant data sets…
82. …and your processing can’t keep up with input…
83. …and your algorithms fit well with MapReduce.
84. Hadoop might work.
85. Your read operations are too slow…
86. …and your data mostly fits in memory…
87. …and all you’re storing is simple data structures.
88. Redis is an option.
89. Bonus points if you’re already using Resque. (Or Sidekiq.)
90. Your write operations are too slow…
91. …and you have really big datasets…
92. …really, really big data sets…
93. …and you’re ready to employ a full-time DB hacker.
94. You might try Cassandra.
95. Back to our taterbases.
96. That’s enough to start writing code, but…
97. We still need to get taterbases.com on the internet.
98. We still need to get taterbases.com on the series of tubers.
99. Decision 3
100. Platform
101. There are a lot of good reasons to use something newer.
102. The Boring Option
103. Build your own server.
104. You are gonna need a sysadmin for that.
105. When to use something else
106. You don’t have a sysadmin on staff…
107. …you don’t have huge performance needs yet…
108. …and you like things that are awesome.
109. Heroku is a good bet.
110. There are also other options.
111. (AWS, various flavors of virtualization, Docker, etc)
112. But they’re all gonna take a sysadmin.
113. So just get your sysadmin to explain them to you.
114. Ok, taterbases.com is up and running!
115. It sprouts a bunch of features!
116. It’s growing faster than a tuber in tater season!
117. Things start to get really hairy!
118. Yuck!
119. Time for services!
120. Decision 4
121. Service Protocol
122. I have a pretty strong opinion on this one.
123. The Boring Option
124. Rails-style RESTful JSON over HTTP
125. It has so much tooling already out there.
126. HTTP has a lot of nice features built in.
127. All your third-party consumers know it.
128. It’s pretty much the only choice to communicate with your JS.
129. Side note.
130. When using Angular, use the Rails conventions for REST operations.
131. When using Ember, it’s probably easier to change Rails to match theirs.
132. When to use something else
133. You really, really need more performance.
134. Provide a Protocol Buffer version of your performance critical endpoints.
135. You need really really insane performance…
136. …and you have no sense of fear.
137. Maybe roll your own with ØMQ.
138. Other Alternatives
139. Thrift
140. As of today, I don’t think Thrift is mature enough.
141. SOAP
142. D-:
143. Maturity isn’t everything.
144. So, we know we’re using JSON + HTTP, but…
145. …where do you send the requests?
146. Decision 5
147. Service Discovery
148. The Boring Option
149. DNS
150. users.taterbases.com taters.taterbases.com recipes.taterbases.com kittens.taterbases.com
151. users.taterbases.com taters.taterbases.com recipes.taterbases.com kittens.taterbases.com
152. And that’s not all!
153. SRV Records
154. _users._tcp.taterbases.com. IN SRV 0 25 389 server.taterbases.com.
155. _users._tcp.taterbases.com. IN SRV 0 25 389 server.taterbases.com.
156. _users._tcp.taterbases.com. IN SRV 0 25 389 server.taterbases.com.
157. _users._tcp.taterbases.com. IN SRV 0 25 389 server.taterbases.com.
158. Side note.
159. Oh my gosh, DNS is so great.
160. When to use something else
161. You have a whole lotta services and servers…
162. …that may or may not be available…
163. …and you change things around frequently.
164. Zookeeper does that stuff.
165. So taterbases is basically working, but…
166. You’re probably going to want some libraries?
167. Decision 6 - ∞
168. Gems
169. Questions to ask…
170. How long has this gem been around?
171. How widely has it been used?
172. How long do issues stay open?
173. When was the last commit?
174. Does this gem actually need to change often?
175. Ultimately, it’s a judgement call.
176. Side note.
177. ruby-toolbox.com is awesome.
178. VI. Conclusion
179. Non-standard technology choices are enormously expensive.
180. Make sure it’s worth it.
181. Or better yet, embrace boring. Be awesome.
182. John Hyland “DJSpinMonkey” on all the things john@djspinmonkey.com @djspinmonkey github.com/djspinmonkey www.djspinmonkey.com