DevLOVE2012

this slide is presented on DevLOVE2012's Hanger Flight session(public appeal)

Transcript

1. スーパーハカーに なりたかったITドカタと コミュニティ そしてマサカリ DevLove Conf 2012 12/15
2. 皆さん
3. こんにちは！
4. 勉強会は好きですか？
5. 私は好きです
6. 勉強会って楽しい
7. DevLOVEに出会ってから
8. 多くの人と知り合いました
9. 多くのコミュニティと 出会いました
10. すごい人をたくさん見て
11. 私もそうなりたいと思って
12. こうして私は
13. スーパー ハカーに 憧れるように なったのだ
15. 今日は
16. コードを書いて
17. アプリを作って
18. 公開して
19. フィードバックをもらった
20. 話をします
21. コード書く フィードバック もらう 公開する
22. コード書く フィードバック もらう 公開する
23. これ何かに似てない？
24. コード書く フィードバック もらう 公開する
25. 黄金の回転
26. ゴゴゴゴゴゴゴゴゴゴゴ
27. 黄金の回転を回すために
28. コードを書こう 公開しよう
29. という話をします
31. 話を戻して
32. スーパー ハカーに 憧れるように なったのだ
33. でも何をすればいい？
34. 昔偉い人は言った
35. 考えるな、コードを書け
36. ということで
37. コードを書いて
38. アプリを作ってみた
39. アプリの目的
40. 目的： 大量の技術書を管理したい 厚さ 25cm これが６つ
41. 概要： 技術書、電子書籍を 管理するアプリ
42. 要求： 大量の技術書 ・管理したい ・検索したい
43. だからアプリを作ってやる！
44. でもどうやって作れば いいんだ？
45. 技術って何があるんだ？
46. まずは
47. 何があるのかを 調べることから始めた
48. でも何も分からなかったので
49. ・コミュニティ ・勉強会 ・書籍 で勉強した
50. さっくり作りたい →Rails サーバはクラウドで →Heroku＋RDS 見た目もオサレに →jQuery Mobile
51. そして
52. ３ヶ月後
53. オサレなアプリが完成
54. 見た目もオサレに
55. スマフォから本棚を検索
56. 大事な事はすべて勉強会が 教えてくれた（ドヤッ）
58. 作ったものを人に 見てもらおう
59. 以下感想
60. 感想１ ・見た目がかっこいい ・データを画面から 登録したい ・Amazon API使えばいい
61. 感想２ ・コード汚い ・テスト書け
62. 感想３ コードが ・これはひどい ・Railsじゃない
63. 感想４ テストが ・これはひどい(２回目) ・RSpec本読め ・GOOS本読め
64. 上げて落とされた
65. 要約すると
66. 他人に見せたら
67. 他人に見せたら
68. フルボッコ
69. 正直心が折れた
71. とりあえず
72. 言われたことはやろう
73. RSpec本を読んだ
74. テスト書いた
75. あわせてリファクタリング
76. ControllerからModelへ ロジックの民族大移動
77. コードが腐海状態→浄化
78. 要望された機能も追加
79. 書籍データをAmazonAPIにより 画面から追加可能に
80. そうしたら
81. コードが成長
82. Before After
83. Before After
84. ということで
85. もう一度見せてみた
86. そしたら
87. 感想 ・テストが全然足りない ・命名センスが 致命的にない
88. さらにフルボッコ
89. ひどい目にあった
91. でも
92. いいこともあった
93. アプリを作って
94. ・コードを毎日書く習慣 ・ツールの知識 (git,jenkins,Rspec,etc) を手に入れた
95. 仕様、技術選定、実装 全部自分でやる→楽しい
96. コードを公開して ・レベルが上がった ・視野が広がった ・知識がついた
97. 成長
98. 具体的にどう成長したか
99. 電子書籍の登録機能 ・Java ・レガシーコード ・クソ設計 →正直見返したくない
100. ・一番最初に書いたコード ・黒歴史 ・例外握りつぶす ・Eclipse開くとSAN値が減る ・黒歴史
101. 想像して欲しい
102. SAN値が下がるほどの クソコード
103. リファクタリングしたくない
104. だから
105. Rubyで作りなおした
106. 電子書籍の登録機能（新） ・Ruby ・テストコード付き ・設計頑張った →バグも減った
107. Before After ４ヶ月 ２週間 成長の結果 →開発速度が９倍 →コードの質が向上
109. なぜわざわざ コードを書くのか
110. ・好奇心に突き動かされて ・コードが書きたかった ・作りたいものがあった ・ついカッとなって
111. ・本を読む ・勉強会で話を聞く →それだけでは 分からないこともある
112. 実践が伴わないと 深い話ができない
113. だから実践をしよう
114. 実践したら公開して フィードバックをもらおう
116. フィードバック＝ツッコミ
117. ツッコミを受けよう
118. ツッコミは 自分ができない事を 知るベストプラクティス
119. ツッコミする人は 解決策も知っている事が多い
121. 「でもツッコミって痛くね？」 「心が折れたりしない？」
122. うん、痛いよ うん、心折れるよ
123. でもそれ以上に成長したい
124. むかし偉い人が言っていた
125. エンジニアは マサカリを 受けると 戦闘力が上がる
126. 参考画像
127. だからもっと マサカリを受けるべき
129. コード公開のコツ
130. ・Githubにおくだけでは 見てもらえない ・自分で人に見せよう ・見る人を選べる ・ツッコミしてほしいところに ツッコミがもらえる
132. ツッコミしてくれる人を どこで見つければ いいんですか？
133. コミュニティ
134. ・インプットの場 ・ツッコミをくれる人が いる場所 コミュニティ
135. ツッコミをもらったら その点を直そう
136. もっと良いコードを書こう
137. 書いたら公開して またツッコミをもらおう
138. コード書く フィードバック もらう 公開する
139. でもさ
140. もらってばかりでも よくないよね
141. 恩送りをしよう
142. ・自分がアウトプット ・他人にツッコミ 恩送り
144. ご清聴ありがとうございました
145. 書いた人 瀬宮 新 @shin_semiya 職業：SIer ハイパーレガシーコードクリエイター 好きな言語：Ruby
147. 追記
148. 心が弱い人がマサカリを 受けるための教訓
149. ベジータに学ぶ マサカリの受け方
150. エンジニアは マサカリを 受けると 戦闘力が上がる
151. 参考画像
152. この時の原作の状況を 整理しよう
153. 背景：フリーザがやばい 目的：ベジータは パワーアップしたい 手段：ベジータはクリリンに 半殺しにしてもらい デンデに回復するよう 依頼した
154. 考えてみよう
155. ベジータはフリーザに半殺しに するよう依頼していない。 フリーザは手加減せずに 殺しちゃうから
156. 教訓１： 手加減のできない人から マサカリを受けるべきではない （少なくとも最初のうちは）
157. ベジータは信頼のできる、 親切なクリリンに依頼した しかも事前に回復役のデンデを 確保した状態で依頼した。
158. 教訓２： 手加減のできる、親切で詳しい 人にマサカリを依頼すべき 教訓３： ダメージは残るので、回復役は 用意しておくべき
159. マサカリを投げてくれるよう 依頼する人はコミュニティの 詳しい人（かつ親しい人）に するべき。
160. どうしようもないクソコード だと自覚している場合は githubに別アカを作って それをマサカリ依頼する 人にだけ教えるべき。
161. なんでもかんでも フルオープン にすればいいって わけではない
162. さぁみんなも
163. レッツマサカリ依頼
164. 追記 終わり