RubyKaigi 2014 二日目 9/19 11:30 から Hall A にて <%= link_to "bundle", "update" %> - Make "bundle update" more fun to review という発表をさせていただきました。お聞きいただいた皆さん、ありがとうございました。
https://speakerdeck.com/kyanny/percent-equals-link-to-bundle-update-percent-make-bundle-update-more-fun-to-review
Compare Linker というツールの紹介と、なぜそれを作ったのか、そして開発を通じて得た学び、などについて発表しました。
Compare Linker については You can review "bundle update" efficiently with Compare Linker - @kyanny's blog で詳しく説明していますが、この記事も発表も英語のみで、日本語での説明が無いことに気づいたので、この場で改めて説明します。
- bundle update して依存 gem が更新されると Gemfile.lock の差分が発生します。GitHub の pull request を使った開発フローでは Gemfile.lock の差分を含むコードレビューをする機会があります。しかし Gemfile.lock の diff はレビューに適しているとは言えません。
- ある gem のバージョンが変化したことはわかりますが、具体的に何がどのように変化したかについての情報はありません。何が変わったのかを知りたければ、まず gem のソースコードリポジトリを検索し、バージョン間の diff を見る、などの作業を全て手作業で行うことになります。
- 実際にそういうことを何度も繰り返した結果、面倒なので自動化しようと思い立ち、 Compare Linker を作りました。
- Compare Linker を Rack アプリケーションとして Heroku などで起動し、 GitHub のリポジトリの設定で pull request webhook の送信先に URL を登録します。新しい pull request が作られると Compare Linker は webhook を受け取り、Gemfile.lock が変更されているか調べます。
- Gemfile.lock が変更されていれば、 pull request の base ブランチ（通常は master です）と head ブランチ（pull request のもとになっているブランチです）それぞれの Gemfile.lock を比較し、変更のあった gem について GitHub の compare view URL を作成し、リンクの一覧を pull request ページにコメントします。
発表ではさらに、 Compare Linker の開発を通じて学んだことについても話しました。それは「アイデアを思いついただけではだめで、行動をおこさなければ価値はうまれない。しかし行動してみただけでもまだ不十分で、改善し続けることが最も大切だ」ということです。
このことに気づいたのは、Junior Designers vs. Senior Designers — The Year of the Looking Glass — Medium という記事を読んだときでした。 Compare Linker を開発し、仕事のワークフローに組み込んで数ヶ月使ってみたものの、思ったほど便利ではなかったかな、と感じていました。その理由はなぜだったのか、この記事を読んでわかった気がしました。なので、どうしてもそのことを伝えたくなり、記事の著者に引用の許可をいただき、話の結論にあたる部分のスライドに記事中の図を使った、という経緯があります。
自分としては、「単なる自作ツールの紹介ならブログで十分。わざわざ話を聞いてもらうからには、自分が得た知見まで含めて伝えたい」との想いからこのようなストーリーを組み立てたのですが、ちょっと説明不足だったかもしれません。
発表の準備をするにあたって、いくつか影響をうけたことがありました。
@deeeet さんの コマンドラインツールについて語るときに僕の語ること のスライドの美しさを目にしたことが、それまで既存の自作テーマを使い回して作っていたスライドを見つめ直すきっかけになりました。この内容を伝えるために最も適した表現方法が他にあるのではないか？と考え直し、結果的に満足のいくものが作れました。
また、 @deeeet さんのブログ記事 や、 GitHub の Zach Holman 氏による The Talk on Talks と http://speaking.io/ からは、スピーカーとしての心構え、特に準備や練習を入念にすべし、ということを再認識させられました。振り返ると、準備、練習ともに不十分だったと感じており、反省すべき点が多々ありました。
Zach Holman 氏からは心構え以外にも、スライドの文字を大きくすることや、目にやさしく見やすい配色を選ぶこと、元気よく情熱的に喋ることなど、多くを学びました。それから、 Keynote の ⌘D というキーボードショートカットを知ったおかげで、スライド作りがだいぶ楽になりました。スライドの見栄えについては、事前のコネクタ接続チェック時にちらりと確認した限りでは、まずまずの出来だったのではないかと自負しています。喋りについては、声はちゃんと出ていたと思いますが、なにぶん経験の浅い英語スピーチだったのでしっかり前を向いて喋れなかったのが反省点です。
そして、最も強く影響を受けたのは、四月に開催された RESTful Meetup vol.3 における @koriym さんのプレゼンテーションでした。まるで TED トークのような情熱あふれる素晴らしいプレゼンテーションで、自分もいつか郡山さんのようなプレゼンテーションをしてみたい、と強くインスパイアされました。そのおかげで RubyKaigi 2014 の CFP に応募する一歩を踏み出せましたし、本番が近づくにつれプレッシャーで追いつめられた気持ちになったときも、あのときの感動を思い出して勇気づけられました。
英語が流暢に喋れるわけでもないのに英語でスピーチをすることについては葛藤がありました。 Semi International Conference とはいえ大多数の参加者は日本人ですし、日本語スピーチについてはプロの翻訳チームによる英語への同時通訳が提供されるのですから、下手な英語で喋るより日本語で喋ったほうが、誰にとってもメリットが大きいはずです。それをわかった上であえて英語を選ぶのは勇気がいることでした。オーガナイザーチームの皆さんがそれを認めてくれたことはとても嬉しく、同時に責任の重大さも強く感じました。
発表前日 @kakutani さんから「（言語は）どっちでもいいと思っている。日本人が英語で喋っても、外国人が日本語で喋っても、好きにやってもらえれば」とおっしゃっていただいたおかげで、ここまできたらあとはやれるだけのことをやるだけだ、と気持ちが吹っ切れました。
発表直後には、翌日の発表を控えた @remore さんから「自分も英語でスピーチする予定なので、（日本人である僕が英語で喋っているのを）みれてよかった」と言っていただき、やってよかった、と救われた気持ちになりました。
英語スピーチの準備をするのは日本語のときと比べるとずっと大変で、逃げ出したくなったときもありましたが、貴重な経験になりました。この経験を糧とし、今後はより大きな目標にチャレンジしていきたいです。
