Saving Sprockets

Saving Sprockets

Db953d125f5cc49756edb6149f1b813e?s=128

Richard Schneeman

May 06, 2016
Tweet

Transcript

  1. Type to enter text Saving Sprockets

  2. 2016 @schneems Saving Sprockets

  3. None
  4. None
  5. Why does sprockets need saving?

  6. May 2011

  7. Major Feature of Rails 3.1

  8. Sprockets is the asset pipeline

  9. Sprockets came first

  10. BTW

  11. They Call me @Schneems

  12. Sounds like “schnapps”

  13. Ruby “Hero”

  14. Ruby “Hero”

  15. None
  16. All likeness to Disney owned properties totally coincidental

  17. And/or parody

  18. (Please don’t sue me)

  19. Lawyers

  20. Call me by my real name

  21. DHH

  22. No need to look like Indy to maintain OSS

  23. He’s my Sprockets Spirit Animal

  24. From 2011 to 2016

  25. 51 million downloads

  26. Rails has 65 million

  27. One developer responsible for 2,027 commits

  28. 68% Sprockets

  29. ♥♥♥

  30. 68% Sprockets 0.9% Rails

  31. 51 million downloads 1 developer

  32. One day, Josh left

  33. What should we do?

  34. Abandon Sprockets?

  35. What are the problems?

  36. You can’t fix what you can’t define

  37. A re-write assumes we know better

  38. we don’t

  39. Assets are easy, edge cases are hard

  40. Established API

  41. How many of you maintain code?

  42. How many of you want to maintain it forever?

  43. None
  44. Losing maintainers is inevitable

  45. It’s not always expected

  46. None
  47. None
  48. 2014

  49. When we lose a maintainer it hurts

  50. How do we cope with losing a maintainer?

  51. Denial

  52. “They’ll come back”

  53. Anger

  54. “Leaving is so selfish”

  55. “That was a pretty jerk thing to do”

  56. Bargaining

  57. “Maybe if we hire them to work on it full

    time…”
  58. Acceptance

  59. “They’re not coming back”

  60. “Who will take this over?”

  61. Rule 1)

  62. A maintainer does not OWE you anything

  63. “I deserve an explanation

  64. Not even an explanation

  65. Leaving a project is a personal decision

  66. Josh didn’t want to talk about it

  67. We should respect what they’ve done

  68. Rule 2)

  69. You OWE a maintainer respect

  70. “But I HATE software <x>

  71. Critique software without demonizing the creators

  72. I’m going to critique the crap out of Sprockets

  73. Critique don’t Criticize

  74. None
  75. You are not your software

  76. You are not your khakis

  77. Josh gave years of his life

  78. HUNDREDS of closed issues

  79. To @josh Thanks for making Sprockets

  80. Rule 3)

  81. Words without actions are empty

  82. Be actionable

  83. Not Helping

  84. None
  85. “ES6 support is great…

  86. “looks like they don’t have async/await support yet

  87. “I need those because of <reason>

  88. Ask

  89. Is this comment adding anything?

  90. Hyperbole breeds burnout

  91. Be honest

  92. Be productive

  93. None
  94. None
  95. Complaining accomplishes nothing

  96. How do we keep a maintainer longer?

  97. How to stay as a maintainer longer?

  98. Back up

  99. Do we want mantainers to stay?

  100. Mic Drop

  101. Graceful handoff

  102. Almost every day I say “this is insane”

  103. 6 hours of my life later, I say “this is

    genius”
  104. Maintainers are historians

  105. Maintainers bring context

  106. Good commit messages

  107. Good PR messages

  108. Well written CHANGELOG entries

  109. Don’t compare to having someone who was there

  110. A story is worth 1000 commit messages

  111. You can’t ask a commit message a question

  112. Did you also consider…

  113. LOL I’m a commit message

  114. Keep maintainers longer by giving them what they want

  115. Respect

  116. Help

  117. “I don’t have time to help

  118. “Gahhhhhh fix all the things for me!!!!!!!!!

  119. 5 minutes to check snap- faceta- foursquare- tagram?

  120. 5 minutes to help

  121. Contribute to docs

  122. Read the guides

  123. Fix typos

  124. Did you find surprising behavior?

  125. Was your behavior documented?

  126. Add it to the guide

  127. 5 minutes to help

  128. Submit bug reports

  129. SRSLY We don’t know if it’s broken

  130. 5 minutes to help

  131. None
  132. Ask common questions

  133. “Was this working previously?

  134. Would you rather a maintainer spent time fixing bugs?

  135. or

  136. Asking for minutiae in issue comments?

  137. Give a minute, save a minute

  138. If you don’t who will?

  139. Exposes you to different parts of the project

  140. Helps you grow as a developer

  141. 10 minutes to help

  142. Include a example app that reproduces the problem

  143. OMG example apps are amazing

  144. “First run $ rails new”

  145. None
  146. Could not reproduce

  147. “Oh, yeah try…”

  148. None
  149. Could not reproduce

  150. None
  151. “Can you try…”

  152. None
  153. Instead

  154. “Here’s an app that reproduces the problem”

  155. github.com/ <username>/ ExampleApp

  156. Give a minute, save a minute

  157. Challenge make 1 example app this year

  158. 30 minutes to help?

  159. Try fixing a/ your bug

  160. Timebox it

  161. Guaranteed to learn something

  162. Read other people’s code

  163. Navigating and debugging are skills

  164. Navigating and debugging are marketable skills

  165. None
  166. Go the extra mile

  167. How do we make transition easier?

  168. What is a maintainer?

  169. Someone who knows the stories

  170. Someone who takes 5 minutes

  171. Someone who takes 10 minutes

  172. Someone who takes 30 minutes

  173. To help

  174. Helping preserves history

  175. Helping is the answer to keeping maintainers

  176. Helping is the answer to creating maintainers

  177. How do we foster a a culture for helping?

  178. Previously

  179. What do maintainers want?

  180. Now

  181. What do helpers want?

  182. DOCS

  183. Sane Code

  184. They want what regular users want

  185. A good developer UX

  186. Non-magical code

  187. Backwards compatibility

  188. Good deprecations

  189. Reliable Tests

  190. DOCS

  191. $ yard doc lib/ [warn]: In file `README.md':248: Cannot resolve

    link to ExecJS from text: [warn]: {ExecJS}... [warn]: In file `README.md':439: Cannot resolve link to Tilt from text: [warn]: {Tilt}... [warn]: In file `README.md':248: Cannot resolve link to ExecJS from text: [warn]: {ExecJS}... [warn]: In file `README.md':439: Cannot resolve link to Tilt from text: [warn]: {Tilt}... [warn]: In file `lib/sprockets/unloaded_asset.rb':62: Cannot resolve link to type: from text: [warn]: ...{type: ”application/javascript“}... Files: 70 Modules: 30 ( 10 undocumented) Classes: 48 ( 25 undocumented) Constants: 50 ( 32 undocumented) Methods: 405 ( 72 undocumented) 73.92% documented
  192. Sprockets methods are documented

  193. Method docs are like unit tests

  194. Don’t tell the whole story

  195. Easy to get out of sync with reality

  196. None
  197. A README tells a story

  198. Like an integration test

  199. $ wc -w README.md 2619 README.md

  200. Sprockets tells a LONG story

  201. Helpers love docs

  202. Sprockets has docs

  203. Y U NO HELPERS SPROCKETS?

  204. Design Research

  205. User Stories

  206. Consider the people using your “product”

  207. Introducing

  208. Pedro

  209. Likes long walks on the beach

  210. Favorite food is bagel bites

  211. Building the next UBER for goldfish

  212. Rails user

  213. Cares only about the user level interface

  214. //= require “foo.js”

  215. Pat

  216. Addicted to ES6

  217. Loves to fly fish

  218. Plugin developer

  219. Did you know sprockets has plugins?

  220. Called Processors

  221. Cares about the processor interface

  222. def self.call(input) data = input[:data] # … end

  223. Diana

  224. Has a dog named Exception

  225. Hates mustard

  226. Rails Developer

  227. I.e. people building an asset pipeline

  228. Cares about Low level interface

  229. env = Sprockets::Environment.new(".") env.gzip = false

  230. Different people need different docs

  231. Don’t make me hunt down docs

  232. sprockets/ guides

  233. Building an Asset Processing Framework

  234. End User Asset Generation

  235. Extending Sprockets

  236. Makes it easier for devs to find what they need

  237. Lives in the source, not a wiki

  238. Docs are only valid for a point in time

  239. Helpers love contributing to docs

  240. so

  241. Make more docs

  242. Make better docs

  243. Docs are the gateway to code contributions

  244. Sane Code

  245. realtalk

  246. Sprockets designed to solve problems

  247. Sometimes it feels like

  248. None
  249. They don’t know why it fails

  250. Sprockets isn’t talking to devs

  251. How does code talk?

  252. Errors

  253. Not

  254. “something broke”

  255. No route matches {:action=>"show", :controller=>"users"}

  256. “This broke”

  257. No route matches {:action=>"show", :controller=>"users"}, :id key is missing

  258. Look here

  259. No route matches {:action=>"show", :controller=>"users"}, :id key is missing

  260. Good errors are instructive

  261. Sprockets will have better errors

  262. I care about this

  263. None
  264. Deprecations

  265. Deprecating in comments is not enough

  266. None
  267. A) No one casually reads your method docs

  268. B) Who has the time?

  269. You cannot break your API without warning*

  270. *when you’ve got 51 million downloads

  271. Your code knows

  272. YELL AT THEM FOR IT

  273. Sprockets 3.X will have deprecations before 4.x

  274. None
  275. Deprecations nudge

  276. Deprecations Help people upgrade

  277. Deprecations help with API design

  278. If you can’t write a good deprecation

  279. The interface wasn’t very good

  280. What if you change a hash key?

  281. Sprockets did this

  282. filename = input[:source_path] || input[:filename]

  283. (more) Sane Code

  284. Sprockets suffers from the god object problem

  285. 1 main class, lot’s of concerns.

  286. 1 object, 105 methods

  287. Where did that method come from?

  288. Sprockets::Base

  289. Sprockets:: Environment

  290. Sprockets:: Dependencies

  291. Sprockets:: DigestUtils

  292. Sprockets:: HTTPUtils

  293. Sprockets:: Mime

  294. Sprockets:: Server

  295. Sprockets:: Resolve

  296. Sprockets:: Loader

  297. Sprockets:: Bower

  298. Sprockets:: PathUtils

  299. Sprockets:: PathDependencyUtils

  300. Sprockets:: PathDigestUtils

  301. Sprockets:: DigestUtils

  302. Sprockets:: SourceMapUtils

  303. Sprockets:: UriUtils

  304. My favorite

  305. Sprockets:: Utils

  306. mixed into

  307. Sprockets:: Compressing

  308. mixed into

  309. Sprockets:: Configuration

  310. Included in

  311. Sprockets:: Base

  312. Inherited by

  313. Sprockets:: Environment

  314. Wrapped and cached by

  315. Sprockets:: CachedEnvironment

  316. None
  317. Impossible to know at a glance how they interact

  318. For more info go to Rafael Franca’s talk

  319. Which was yesterday

  320. Solution to god objects?

  321. Move logic over to helper classes

  322. None
  323. Minimize God object API

  324. Small easy to understand files

  325. Readable code

  326. Attracts helpers who read code

  327. Ruby is Object Oriented

  328. Get comfortable with objects

  329. Sandi Metz POODR

  330. Katrina Owen Refactoring & Exercism.io

  331. Helping takes commitment

  332. respect that

  333. How?

  334. Be nice

  335. “thanks for submitting this PR

  336. They cared enough to try to help

  337. Help them help you

  338. What else do people want?

  339. Maybe they want recognition?

  340. None
  341. Maybe helpers want pizza?

  342. Windows Tests

  343. )

  344. Thanks @daniel-rikowski

  345. These are our ideals

  346. So you inherited a project with 51 million downloads

  347. The original maintainer mic-dropped

  348. What do you do?

  349. Find something that needs fixing

  350. Bug driven development

  351. Get an example app

  352. OMG example apps are amazing

  353. Reproduce the problem

  354. Repeat

  355. Every bug you fix, you’ll learn more about the project

  356. Eventually you’ll begin to see non- bug problems

  357. So you’ve got a bug report what do you do

    now?
  358. Source Maps in Sprockets 4

  359. Half finished

  360. I had no idea what source maps were

  361. Fixing bugs made tests break

  362. Are those test reliable?

  363. ¯\_(ツ)_/¯

  364. Where do we start?

  365. Become an archeologist

  366. Research

  367. Mozilla RFC

  368. Notes

  369. Create guides

  370. What is a source map?

  371. Read my guide!

  372. Good OSS maintainers steal borrow

  373. Used other projects to verify Sprockets

  374. Encoding $ npm install uglify-js

  375. Encoding $ uglifyjs foo.js --source-map foo.js.map var foo="foo";var bar="bar"; //#

    sourceMappingURL=foo.js.map
  376. Decoding $ npm install source-map

  377. Is it finished?

  378. No, need more actionable bug reports

  379. Where do we go now?

  380. Maintainers Won’t be around forever

  381. I Won’t be around forever

  382. I need help

  383. Help maintain the history of Sprockets

  384. Preserve the stories

  385. Get involved

  386. If you won’t, who will?

  387. We all need to step up

  388. Take 5 minutes

  389. Read guides

  390. Write docs

  391. Open issues

  392. Create example apps

  393. Just

  394. 5

  395. minutes

  396. Join me

  397. Become

  398. A helper

  399. A maintainer

  400. Together

  401. Save Sprockets

  402. Questions?