倒れるときは前のめり。

カレーが好きです。

『プロを目指す人のためのRuby入門』出版記念イベント&リファクタリングコンテストに行ってきた

まぁタイトルのとおりなんですが、行ってよかったです(KONAMI

techplay.jp

今日のイベントはざっくり、

  • 書籍『プロを目指す人のためのRuby入門』(通称「チェリー本」)の紹介
  • jnchito 氏による講演: 「わかりやすい技術記事を書くための心構えとテクニック」
  • 公開リファクタリングコンテスト

の3本立て。当日のやりとりは twitterハッシュタグ #railsdm を追いかけるのがよいかと。

『プロを目指す人のためのRuby入門』

パラパラとまえがきと目次を読み、本文をつまみ食いしながら読んでみて、「1年前に出会いたかった!!!!!!111」というのが率直な感想。自分はサーバサイド言語を PHP ではじめて、Ruby をさわるようになったのは今の会社に移ってから。これまでどうやって Ruby を習得してきたんだっけと振り返ってみると、

  • ドットインストールをなめて雰囲気を掴んで、
  • Railsチュートリアルを2周くらいやりきって、
  • 業務で Ruby を触るようになってからは、Qiita の記事や技術ブログから雑多で断片的な知識を吸収しつつ、
  • 『パーフェクトRuby』を読んで体系的に知識を整理しようとするも、メタプログラミングの章で挫折する
  • あとは日々のコードレビューで指摘をもらいながら1つずつ少しずつ自分のものにしていった
    • 振り返るとこれが大きいかなあ

「『パーフェクトRuby』や『Effective Ruby』よりももう少し敷居が低くて、ふだんの Rails 開発に活かせるな本があればなあ」と頭を抱えていた自分にまさにベストマッチで、ありがたや…という言葉しかない。

gihyo.jp

「わかりやすい技術記事を書くための心構えとテクニック」

もともとは「ぼくのかんがえたさいきょうのRubyにゅうもんしょ」~初心者のスキルアップのために技術書は何ができるか~というテーマだったが、「わかりやすい技術記事を書くための心構えとテクニック」 に変更。

あとは今の時代における技術書のあり方論、みたいな話もちらほら。

リファクタリングコンテスト

github.com

前にも同様の試みをやっていたのは twitter のタイムラインで追って知っていたけど、実際に参加するのは今回がはじめて。

とりあえずお題のプロダクションコードとテストコードを初見で読んだ際のメモがこれ。

## テストコード

- minitest さわるの、Railsチュートリアル以来だなあ(小声
- にしてもテストケース読みづらい
- 「ドキュメントとしてのテスト」として書く視点を持つといいかもしれない
  - ex. メソッドを使う側の人間が `\n` とか意識するか?
- たとえば
  - 1 2 3
    4 5 6
    7 8 9
  - を Ruby で書けないか?と考える
    - たしか <~~ でいけたような

## プロダクションコード

- Ruby 本来が持っている仕様を調べるクセをもつといい
  - 誰かがやりたいと思っていることは、きっと他の誰かも考えている
  - それが例えば gem で実現されていることもあれば、 Ruby 標準のライブラリで実現していることもある

メモをもとに自分が出したプルリクエストはこれ。 github.com

ふだん業務で交わしてるやりとりを思い出しつつやってみたものの、どこまで前提条件に踏み込んでいいのかとかコメントのレベル感どうするか?とか、実際のコードリファクタリング以外で考えるポイントが多かった…1

所感

  • 生 jnchito さんは見た目通りに気さくな方だった
  • リファクタリングコンテストは社内でもやってみたい。モブプロとかとあわせてワイワイやるのがいいかも
  • 会場を提供いただいた Speee さん、ラウンジがおしゃれすぎて息を吸うのも心苦しかった

戦果


  1. たとえば「そもそもなんで転置行列なんだ?」とか、「このメソッドはプロジェクト内でどんな役割を果たすのか?」…とか、そのへんの話