Solve your problem, speed up your life, and paint it black with Ruby!

Slides for Rakuten Technology Conference 2013 talk "Solve your problem, speed up your life, and paint it black with Ruby!" http://tech.rakuten.co.jp/

Transcript

1. Solve your problem, speed up your life, and paint it black with Ruby! Akira Matsuda
2. Please allow me to introduce myself
3. I'm a man of Ruby and Rails
4. Rails Ruby
5. Pleased to meet you
6. Hope you guess my name
7. My name •GitHub: amatsuda •Twitter: @a_matsuda
9. We meetup on every Ruby Tuesday
10. Members and ...
11. From all over Asakusa
12. From all over Japan
13. From all over the World!
14. I'm a Rubyist.
15. begin
16. Ruby is different today. I hear every programmer say •Ruby is a "web language" •Ruby is a "slow language"
17. Ruby.is_a? web language
18. Ruby.is_a? web language •Obviously it is!
19. I use Ruby because...
20. I use Ruby because... •I'm a web programmer.
21. I use Ruby because... •I'm a web programmer. •Every web programmer uses Rails.
22. I use Ruby because... •I'm a web programmer. •Every web programmer uses Rails. •Ruby is the language "under Rails".
23. Why Ruby? •Rails is my business... and business is good! •I'm not playing on Ruby, I'm just working on Rails.
24. I hear every programmer say •Ruby is a "web language" •Ruby is a "slow language"
25. Ruby.is_a? slow language
26. I heard people say Ruby is slow, so what shall I do?
27. New trolls! •Submit a CFP titled "7 reasons why Ruby is slow" for a Ruby conference. Immediately. •Be quick, or be dead you'll miss a chance to get up on stage.
28. 7 reasons? •They say GC is slow. •They say Ruby is slow because of the "GIL" thing.
29. "GIL" (or GVL) • What exactly is it? • Don't ask me. I don't know. Ask @_ko1 or @kosaki55tea • No, actually you need not to know about it. • I hear every programmer say JRuby or Rubinius are better and faster than MRI because they are GIL free. So let's just throw MRI away.
30. GIL free! •Thank Matz Almighty, we are free at last! •Roll over @yotii23's husband, tell Patch Monster the news.
31. How is it free? •Let's take a look.
32. Concurrency is such a lonely word. Every Thread is so untrue. array = [] 5.times.map do Thread.new do 1000.times do array << nil end end end.each(&:join) puts array.size http://www.jstorimer.com/blogs/workingwithcode/8085491-nobody-understands-the-gil
33. Concurrency is hardly ever heard. And mostly what we need from Ruby. •% ruby -v thread_tes.rb ruby 2.1.0dev (2013-10-14 trunk 43282) [x86_64-darwin12.5.0] 5000 •% ruby -v thread_tes.rb rubinius 2.1.1 (2.1.0 be67ed17 2013-10-18 JI) [x86_64-darwin12.5.0] 3504
34. OMG
35. But ... but I still feel like Ruby is kind of slow for me, so what can I do?
36. No trolls! •Submit a CFP titled "7 reasons why Ruby is slow" for a Ruby conference. Immediately.
37. :trollface:
38. Don't troll. Code. • Unless you're a VM programmer, shut your mouth. • That's @_Ko1's business. • That's why Heroku pays @_ko1's salary. • Instead, nd a problem that YOU can deal with. • And don't let it be. Don't whisper words of wisdom. Solve it.
39. I know a person who actually have been doing this •He thought Rails is slow because assets are slow. •=> The asset pipeline •He thought Rails is slow because we are reloading assets for every request. •=> Turbolinks
40. He's the speed king
41. Your Rails app is slow because... •Kernel#require is slow •RubyGems & Bundler is slow •ActiveRecord is slow •RSpec is slow •Rack is slow
42. Kernel#require •@_ko1 told me that require_relative would be way faster than require •So we tried
43. https://github.com/amatsuda/ rails/tree/require_relative •Rewriting 544 `require` calls to `require_relative`
45. 'Cause I try and I try and I try and I try • Before: % time rails r 1 4.07s user 1.32s system 95% cpu 5.650 total % time rails r 1 3.91s user 1.15s system 99% cpu 5.087 total % time rails r 1 3.91s user 1.17s system 99% cpu 5.107 total • After: % time rails r 1 4.20s user 1.24s system 99% cpu 5.467 total % time rails r 1 3.98s user 1.17s system 99% cpu 5.167 total % time rails r 1 3.99s user 1.15s system 99% cpu 5.169 total
46. I can't get no! I can't get no! •NO performance improvement!
47. Hail, hail to Bundler •It turned out that RubyGems rewrites Kernel#require and makes it slow, but Bundler re- rewrites it and makes it fast nally.
48. The problems I recently found
49. database_cleaner is slow
50. 10% of `time rake spec` was spent for DB cleaning •time rake spec: 14m01s •time spent on cleaning DB: 77m35s
51. So I rewrote database_cleaner •Come cleaning faster! •Just call `delete` if I hear `insert` •FIX ME!
52. amatsuda/ database_rewinder
53. Speedy's coming •time rake spec: 13m15s •time spent on cleaning DB: 0m8s
54. Loading a huge HTML is slow
55. lazy-load partials •Separate a huge webpage into several partials. Then load the partials via separate requests. •Rails views already have "partials". •What if partials are lazy-load- able?
56. amatsuda/ ljax_rails
57. ljax_rails <%= render 'users' %> => •<%= render 'users', remote: true %>
58. bundler is slow •$LOAD_PATH
59. In our mid-sized app's case % rails r 'puts $:' | grep gems | wc -l 200
60. Can't they be squashed into one lib/ directory? •Because each gem are basically namespaced. •The only thing that looks good on me, at runtime, is lib/ directory in most cases.
61. Current directory structure ᵓᴷᴷ gem1 ᴹ ᵋᴷᴷ lib >> LOAD_PATH ᴹ ᵓᴷᴷ gem1 ᴹ ᴹ ᵓᴷᴷ bar.rb ᴹ ᴹ ᵋᴷᴷ foo.rb ᴹ ᵋᴷᴷ gem1.rb ᵋᴷᴷ gem2 ᵋᴷᴷ lib >> $LOAD_PATH ᵋᴷᴷ gem2 ᵓᴷᴷ fuga.rb ᵋᴷᴷ hoge.rb
62. Squash all gems into one directory ᵋᴷᴷ all_bundled_gems_in_one ᵋᴷᴷ lib >> LOAD_PATH ᵓᴷᴷ gem1 ᴹ ᵓᴷᴷ bar.rb ᴹ ᵋᴷᴷ foo.rb ᵓᴷᴷ gem1.rb ᵋᴷᴷ gem2 ᵓᴷᴷ fuga.rb ᵋᴷᴷ hoge.rb
63. (bundle_squash) •(It should be possible) •(But not yet on the Web...)
64. Problems I'm willing to challenge •Make Haml faster •Or create a faster fork of Haml •Make ActiveRecord faster •Or create a faster subset of AR
65. Haml
66. Ruby.is_a? web language •(reprise)
67. Ruby.is_a? web language and !Ruby.is_a? web_only language •Ruby off Rails!
68. One thing I hate on my computer
69. One thing I hate on my computer
70. Who here are happy with the Finder.app?
71. Finder.app •Mr. Finder.app, what went down in your head •Your UI to me seems so tragic, with the thrill of it all
72. At Railsษڧձ@౦ژ last month •We talked about how Finder.app sucks •We agreed that we need a better " ler" •And I started creating it last month.
73. Why Finder.app sucks
74. Why Finder.app sucks •Productivity •Design
75. Productivity • It's so hard to do simple things such as `mkdir`, `rm`, or `cd` to a hidden directory. • How can I `touch`? How can I `ln -s`? How can I `chmod`? • Telling me more and more about some useless features. Supposed to : re: my productivity.
76. Design •It's white!
77. Paint it black! •I see a white window and I want it painted black.
78. Paint it black!
79. Paint it black! •No colors anymore I want them to turn black.
80. Paint it black!
81. So, I made my own nder •And saw that it was good.
82. How can Finder.app be better? •Needs to be more productive. •Needs to be painted black.
83. Clone FD
84. FD •It's only a DOS application but I like it.
85. About FD •http://news.mynavi.jp/articles/ 2012/11/20/FD/ •A legendary " ler" for MS-DOS •Firstly released in 1989
86. Do ya think I'm sexy? •This tool is not very glamorous but still very sexy.
87. Get back to where you once belonged
88. What a drag it is getting old •Am I sticking to an old tool that I'm used to because I'm too old to learn new tools? •No. I'm creating this not just for nostalgy but for productivity.
89. Technologies •Xnix •Terminal •Ruby •Curses
90. amatsuda/rfd % gem i rfd
91. Concept, design •FD + Vim •Simple MVC •M: les & directories •V: Curses •C: logic •Customizable, plugin-able architecture
92. Implementation •Basically commands are one- char •Each command is de ned as a method in commands.rb •Pressing a key simply runs that method (send)
93. rfd commands •Moving the cursor •Manipulating les •Viewing, Editing •Manipulating archives
94. TODO •tree view •command customization •color customization •undo •watchr
95. Summary (1) •I use Ruby to solve "my" problem •OSS != volunteering. No need to "contribute" to someone else. Start with "your" problem. It's a very good place to start.
96. Summary (2) •Ruby is slow, and I'm trying to make it faster. •You can do it even if you're not a VM hacker or a GC hacker. •There're many unoptimized parts left in the whole Rails app stack.
97. Summary (3) •I'm painting it black with Ruby. •It works ne, and I'm happy with that.
98. Conclusion •Play with Ruby for fun rather than just work with Ruby for money! •Let's spend the night with Ruby!