December 06, 2017
まぁタイトルのとおりなんですが、行ってよかったです(KONAMI
【Rails Developers Meetup 特別編】『プロを目指す人のための Ruby 入門』出版記念イベント&リファクタリングコンテスト｜ IT 勉強会なら TECH PLAY［テックプレイ］
今日のイベントはざっくり、
の 3 本立て。当日のやりとりは twitter のハッシュタグ #railsdm を追いかけるのがよいかと。
パラパラとまえがきと目次を読み、本文をつまみ食いしながら読んでみて、「1 年前に出会いたかった！！！！！！111」というのが率直な感想。自分はサーバサイド言語を PHP ではじめて、Ruby をさわるようになったのは今の会社に移ってから。これまでどうやって Ruby を習得してきたんだっけと振り返ってみると、
「『パーフェクト Ruby』や『Effective Ruby』よりももう少し敷居が低くて、ふだんの Rails 開発に活かせるな本があればなあ」と頭を抱えていた自分にまさにベストマッチで、ありがたや…という言葉しかない。
プロを目指す人のための Ruby 入門 言語仕様からテスト駆動開発・デバッグ技法まで：書籍案内｜技術評論社
もともとは「ぼくのかんがえたさいきょうのRubyにゅうもんしょ」～初心者のスキルアップのために技術書は何ができるか～というテーマだったが、「わかりやすい技術記事を書くための心構えとテクニック」 に変更。
「わかりやすい技術記事を書くための心構えとテクニック」、これアドベントカレンダーを書く前に知りたかったやつや… #railsdm
— cheezenaan🍺 (@cheezenaan) 2017年12月6日
わかりやすい記事のコツ 1.読者の視点に立つ 2.自分の言葉で書く 3. メリットを提示する 4. 具体例を出す #railsdm
— 🦇 (@mikiso) 2017年12月6日
技術の「おいしさ」(=おもしろさ、楽しさ、すごさ、便利さ)を読み手に伝える、利用シーンをイメージしてもらう。圧倒的""それな""感しかない #railsdm
— cheezenaan🍺 (@cheezenaan) 2017年12月6日
あとは今の時代における技術書のあり方論、みたいな話もちらほら。
【体系だった知識】ネットの情報=つまみ食いの繰り返し / 技術書=一流レストランのフルコース 著者の膨大な経験と知識(5年くらいの）を3000 円はやすい。ググっても出て来ない情報が多いほど本の価値は高い #railsdm
— 🦇 (@mikiso) 2017年12月6日
JunichiIto/ruby-problem-201712: A small Ruby problem for Rails developers meetup December 2017.
前にも同様の試みをやっていたのは twitter のタイムラインで追って知っていたけど、実際に参加するのは今回がはじめて。
とりあえずお題のプロダクションコードとテストコードを初見で読んだ際のメモがこれ。
## テストコード
- minitest さわるの、Railsチュートリアル以来だなあ(小声
- にしてもテストケース読みづらい
- 「ドキュメントとしてのテスト」として書く視点を持つといいかもしれない
- ex. メソッドを使う側の人間が `\n` とか意識するか？
- たとえば
- 1 2 3
4 5 6
7 8 9
- を Ruby で書けないか？と考える
- たしか <~~ でいけたような
## プロダクションコード
- Ruby 本来が持っている仕様を調べるクセをもつといい
- 誰かがやりたいと思っていることは、きっと他の誰かも考えている
- それが例えば gem で実現されていることもあれば、 Ruby 標準のライブラリで実現していることもあるメモをもとに自分が出したプルリクエストはこれ。
ふだん業務で交わしてるやりとりを思い出しつつやってみたものの、どこまで前提条件に踏み込んでいいのかとかコメントのレベル感どうするか？とか、実際のコードリファクタリング以外で考えるポイントが多かった…1。
本日の戦果です #railsdm pic.twitter.com/nW6tdETZgs
— cheezenaan🍺 (@cheezenaan) 2017年12月6日