タイミーの新谷、神山です。
東京Ruby会議12 が1月18日に開催されました。タイミーは Gold Sponsor として協賛をさせていたただき、ブースを出展していました。ブースに来ていただいたみなさんありがとうございます！
タイミーからは @ryopeko が「functionalなアプローチで動的要素を排除する」というタイトルで登壇しました。
また、タイミーには世界中で開催されているすべての技術カンファレンスに無制限で参加できる「Kaigi Pass」という制度があります。
この制度を使って2名のエンジニアが参加しました。 参加して聞いたセッションのうち印象に残ったいくつかをピックアップしてご紹介します。
Keynote "Scaling Ruby @ GitHub"
GitHub 社の John Hawthorn さんによる GitHub というプロダクトがどのようにして規模を拡大し、高可用性とパフォーマンスを維持しながら、アプリケーションを効率的に運用しているかについて紹介するセッションでした。
セッションの中ではたくさんのノウハウの紹介がありました。
- 大量の Pull Request のデプロイを効率的に管理するためのマージキュー
- 問題が発生した際に素早く切り戻すための Feature Flag
flippergem - パフォーマンスチューニングを行う際の性能比較を行いやすくするためのツール
scientistgem - データベースレプリケーションを最適化するためのツール
frenogem - DB再接続の機構と過度に再接続を行わないようにするための Circuit Breaker の仕組み
発表の中で GitHub はモノリスな Rails で運用されていて、コード行数は380万行弱、テストコードは200万行弱という話がありました。単純な引き算をするとテストを抜いた実装に関するコードは180万行弱ということになります。これは現在のタイミーのモノリスの10倍以上ものコード行数です。
モノリスであること自体がスケールのボトルネックになるわけではなく、モノリスを取り巻く周辺環境の整備さえできればこれだけ組織がスケールするという点は大きな励みになりました。
また、発表の中での「GitHub 社に入社後、GitHub が普通の Rails アプリケーションだったことに驚いた」という話も印象的でした。飛び道具を使うわけではなく、実直に目の前の課題に対処することへの重要さを再認識しました。
発表の中でいくつかの GitHub 社のテックブログが引用されていたと思うので、こちらを参考にさせていただこうと思います。
心のどこかで遠い存在のように感じていた GitHub が我々の開発の延長線の先にいるように感じられた、そんな発表でした。
（@euglena1215）
新谷が書いているように、GitHub が弊社の開発の延長線上にいるように感じました。
特に scientist の gem は変更に対して堅牢さをもたらしてくれるなと感じているので、結構気になっています。
スライドが公開されたら見返したい。
(@dak2)
Writing PDFs in Ruby DSL
Cookpad Inc. の Hiromi Ogawa さんによる Ruby DSL で PDF 書こうぜというセッションでした。
私は前職で thinreports で PDF に出力する項目を修正していたことがありました。
そのため、個人的にセッションの内容が気になっていました。
PDF の構造は知らなかったので、自分にとっては知見だなあと思いつつ自分だったらどう書くんだろうかと思いながら楽しく拝見しました。
業務で使っているツールなどをハックして再実装するなどの試みは、そのツールとの機能差分が比較できてより理解が深まりますよね。
何か Ruby で再実装できないかなあと意識する良いきっかけになりました。
セッションのスライドの PDF 自体も Ruby DSL で自作されていたという最後の伏線回収まで綺麗でお見事だなと思いました（笑）。
(@dak2)
Simple組み合わせ村から大都会Railsにやってきた俺は
これまで軽量なライブラリの組み合わせによって Web サービスを開発してきた（≒ シンプル組み合わせ村に住んでいた）ところから、フルスタックな Rails を書くようになった（≒ 大都会Railsに移り住んできた） moznion さんによるシンプル組み合わせと大都会Railsの比較を行うセッションでした。
私は業務でちゃんと使ったことがあるのが Rails のみでSimple組み合わせ村に住んだことがないシティーボーイだったということもあり、興味深く拝見しました。
Simple組み合わせ村も大都会も「どちらも正解だよね」と結論だったのですが、Simple組み合わせ村に住んだことがない自分としては適材適所の具体例を一歩踏み込んで聞けると尚良かったなと感じました。
また、これは発表と直接関係ないのですが、Simple組み合わせ村が発達している言語においてはDI（Dependency Injection）も同様に発達しているような印象があり、それは組み合わせの差し替えを容易にするためだったりするんだろうか…と聞きながら考えていました。
（@euglena1215）
私も production 利用のコードベースで触ったことがあるのは Rails のみな都会っ子です。
セッション内容を聞きながら、20年経っても Rails が当初の価値観を崩さず、Rails でいつづけられるのは、Easy であるからこそなのではないかなと思っていました。
Simple 組み合わせ村は「俺の考えた最強のxxxx」が乱立するんだろうなと思いますし、すべてのプロジェクトでそれが通用するかと言われると微妙なところがあると思っています。
Rails は Rails Way という言葉があるようにレールに乗った開発を推奨しているので、同じコンテキストの情報が Web にたくさん落ちていますし、そういった面からもクイックにやりたいことを実現できる素養があって、ここまで使われているんじゃないかなあと考えていました。
(@dak2)
Regional.rb and the Tokyo Metropolis
広義の “Tokyo” の地域.rbのオーガナイザーが一堂に会し、色々なことに対してガヤガヤと話す RubyKaigi の Ruby Committers and the World 的な会でした。
東京近辺にこんなに地域.rbがあるのかという驚きが第一印象でした。他の言語のコミュニティにあまり参加したことがないのですが、ここまで地域コミュニティが発展している言語はあまり多くないのではと予想します。Asakusa.rb のようなOSS活動などでアウトプットすることを目的とした地域.rbもあれば、しんめ.rb のような初学者向けの地域.rbがあったりと裾野が広さを改めて感じることができました。
私は普段 omotesando.rb に参加することが多いのですが、地域.rbがあることで普段の業務や趣味で取り組んでいることを対外的に発表する機会が生まれ、登壇資料を作る中で自分の中でも理解の整理が進み、発表した内容を元に懇親会で興味ある人とざっくばらんに話すという一粒で三度美味しい経験をしているので、地域.rbのオーガナイザーには感謝してもしきれません。本当にありがとうございます。
（@euglena1215）
三浦半島.rb が立ち上がったのを聞いて Kaigi Effect を感じました！ 私は自宅近くの地域.rbにしか参加していなかったので、これを機に他の地域.rbにも顔を出してみようかなあと思いました。私なりの Kaigi Effect です（笑）
(@dak2)
Keynote “Ruby と Rust と私”
Cookpad Inc. の Suzuki Kohei さんによる Ruby と Rust の実装を比較しながら感想を述べていくセッションでした。個人的には最近趣味で Rust を触ってみているので、どういう違いがあるのだろうかと気になっていました。
並行処理の文脈で「Ruby だと工夫が必要なところが、Rust では普通に書くだけで達成できる」という言葉が印象に残っています。メンテなども考えると、この間の距離って強い気持ちがないと埋めづらいなと聞きながら思っていました。
Result 型の question operator によるエラーハンドリング便利ですよねとか、SQLx で DB の row をデータ型にマッピングできるのかとか共感や発見が得られて面白かったです。
余談ですが @euglena1215 が Suzuki さんと ISUCON の Ruby 実装に型を付けたいという話をされたようで、ISUCON の Ruby 実装にも型がつくかもしれません。
(@dak2)
今回のコンセプトは「Ruby と Class」ではなく「Rubyと暮らす」でした。
発表としても業務で Ruby を使っている、というよりももう一歩生活の中に Ruby が溶け込んでいるような印象を受ける発表が多かったような気がします。
RubyKaigi とも Kaigi on Rails とも異なる、アットホームな味のある楽しいカンファレンスでした。東京Ruby会議12のオーガナイザー、ヘルパーのみなさんありがとうございました！
