3 日間に渡る国内最大の Ruby カンファレンス、RubyKaigi 2017 に行ってきた。初参加!
RubyKaigi 自体も初参加なのだけど、複数日に渡る技術系イベントにフル参加したこと自体がたしか初めて。遠方だったのもあってかなり疲れた…。
いつものように極めて雑な感想を書きますが、ぶっちゃけ聞いたけどわからなかったのとかもあったりするので(英語だったり難易度だったり…)、いくつかピックアップして書きます。 あと勝手な解釈でまとめを書いてたりするので間違ってたらゴメン。
1日目
Keynote - ゆるふわRuby生活 - nobu
発表自体が非常にゆるふわで、ふわふわしながら聞いていたのだけど、たぶん Ruby の開発に参加しませんかっていうお話のはず。
会期中にも幾度か話題に挙がった、右代入はあると便利そう。しかしこれ仮に入ったとして、同じ意味を持つコードの書き方が増える=スタイルが増えるので、しばらくはスタイルの統一に苦心するかも。新しい文法はすべからくその可能性があるので最初は仕方ないんだけど。
API Development in 2017 - @onk
Schema First で開発しようという話。
API 記述ツール回りは私も個人的に少し追っていたので、概ね想像通りの内容だった。GraphQL はまだ実際に試すところまで行けてないのでちょっと触ってみたい。
Official Partyの場で質問する機会があったので、以下のような感じなことを聞いてみた。
- Q: 既存の API 記述形式はいずれも Request/Response の記述のみだが、昨今は WebSocket などもあり、特にゲーム等では双方向通信のための API 記述が必要になることが多い。双方向通信の API を記述するにはどうするのがよいのか
- A: うちも困ってて悩み中 (雑要約)
ですよねーー!という感じだった。とりあえず悩んでるのが私だけでないとわかってよかった(?)。
別のセッションで出てくる Language Server Protocol はまさしくこの双方向通信を使っているものなんだけど、現状は Markdown 形式の仕様書 があるのみ。プログラムから再利用可能な形式の API 定義がほしい。
Handling mails on a text editor - @shugomaeda
発表資料: https://github.com/shugo/RubyKaigi2017
Ruby で書かれたテキストエディタ、Textbringer の実装の話。
バックグラウンド実行の話は興味深い。 Vim の場合は歴史的経緯もあってプログラム全体がシングルスレッド。外部インターフェースを使えばスレッドが作れるが、そこから Vim のバッファなどの情報を書き換えると当然クラッシュする恐れがある。怖い。
Gemification for Ruby 2.5/3.0 - @hsbt
発表資料: https://www.slideshare.net/hsbt/gemification-for-ruby-2530
標準ライブラリを外部 gem にしていく計画の話。
標準ライブラリを gem として外に出していくことで、Ruby 本体の更新を待たずに gem を更新して最新のパッケージを使えるようになるので、ユーザーとしては助かる。作る方は互換性の確保などの必要があって大変らしい。
Ruby 2.5 から bundler が標準ライブラリになって gem install bundler
が不要になるらしい。便利。
How to optimize Ruby internal. - Watson
発表資料: https://speakerdeck.com/watson/how-to-optimize-ruby-internal
地道にパフォーマンス改善していく話。
ものすごく淡々と、基本に忠実にパフォーマンス改善していた。カッコイイ。 計測で使っていた iprofiler が便利そうだったけど、Mac 用のアプリらしい。この辺りのツール類は計測したくなったときに色々調べてみよう。
I quit my job to write my own language: Goby - Stan
発表資料: https://www.slideshare.net/LoStan/goby-and-its-compiler
飼い猫がかわいいという話 自作言語 Goby の話。
どうやらまだまだコンパイラの作り方の勉強中らしい。割と基本的なバイトコード最適化の部分を「難しい」って言ってた。がんばれー。
私も時間取って言語作ったりしてみたいなー。
2日目
Keynote - The Many Faces of Module - matz
Ruby のモジュールが持つ役割の分類について。
今まで当たり前のようにモジュールを使ってきたけど、言われてみればモジュールは様々な種類の役割を持っていることに気付かされる。今回の講演では既存の役割として6種類の使い方が紹介されて、また今後増える可能性も示唆された。Structural signature は Ruby 3 に向けて議論されている型システムにも通じるものがあるので非常に興味深い。
そしてやはり最後、Ruby はもはや Matz さんだけの言語ではなく、我々の言語であると言っていたのが印象深かった。
An introduction and future of Ruby coverage library - mame
現状はラインカバレッジしか取れないので、もっと細かく取れるようにしていくとのこと。ブランチカバレッジも取れるようにしたいって話だったので、こんな風に行内の式のどの部分が実行されてないかわかるようになるといいなぁ。
ところで、カバレッジ結果の出し方について悩んでいるという話があった。ここでの話はライブラリの API の戻り値の話だったけど、それを更にファイルに出力する際のファイルのフォーマットって各言語の各ツールがみんなそれぞれ好き勝手にやってて全然統一されてないっぽい。Codecov の API リファレンスにある、受け付けるファイルフォーマットの種類はリストアップされているだけで21種類あり、実際にはもっとあると書かれている。まさにカオス。
カバレッジの結果って行やカラムなどのファイルの位置情報に終始していて言語の文法に依存することって基本なさそうなので、統一できそうなんだけどなぁ(ちゃんと作らないと行単位しか表せなかったりだと困るのでどの程度の表現力が必要かという話はあるだろうけど)…デファクトがないのがつらい。
Automated Type Contracts Generation for Ruby - Valentin Fondaratov
発表資料: https://speakerdeck.com/valich/automated-type-contracts-generation-1
Ruby のコードの型情報を生成する手法について。
Ruby は動的な言語なので、静的解析には限界がある。他のセッションでも、完全な型情報を型を書かずに静的に決定するのは不可能という話があったりした。 動的な言語なんだから実際に実行しないとわからない。なら走らせてしまえ、というアプローチがおもしろい。やっぱり動かすしかないよね…。
任意の gem 内で定義されているメソッドが、テストコードによってどの型で呼び出されたかという情報を蓄積して、これにより型を得る。集めたデータはクラウドに蓄積し、public な gem に関してはユーザー間で共有する。これはすごい。
セッションの紹介ページをよく見るとわかるのだけど、これは RubyMine で使われている手法。Vim でもできるようになるといいなぁ。
Type Checking Ruby Programs with Annotations - @soutaro
アノテーションを書くことによって型情報を与え、その情報を元に型チェックを行う手法について。
型情報を書かずに、完璧な型チェックを行うことは不可能と結論していて、わかる…という感じ。どこかを妥協しないといけない。 steep という gem でできるようにしていて、Ruby 本体に手を加えずにできるので、試金石としてかなり良さそう。
Ruby Language Server - @mtsmfm
発表資料: https://speakerdeck.com/mtsmfm/ruby-language-server
Language Server Protocol の紹介と、Ruby 版の実装の解説。
Language Server Protocol についてはその前身の 1 つである OmniSharp の Vim 版クライアント omnisharp-vim のメンテナをしている(メンテナンスしているとは言っていない)のもあってかなり関心が高い。 Language Server が提供するものの 1 つに補完があるけど、この辺りの話題は今回の RubyKaigi で本当に多い。そしてそれが難しいと言う話も何度も出ていて、やはり現状では本当に簡単な補完しかまだできない模様。 この辺りは今後もっと周辺の環境が整っていきそうな気配があるので、要注目。
3日目
Exploring Memory in Ruby - Building a Compacting GC - @tenderlove
日本語でやってくれたのも大きいけど、感動的なくらいに話が非常にわかりやすい。GC 回りの基礎知識を私が持っていたのもあるかもしれない。
資料ではコンパクションは明示的に呼び出している模様。モチベーションの起源を考えると、それで十分なのかな。将来的に Ruby 本体に入れることを考えているかどうかはわからないけど、もし入れるのであればある程度自動で走ってほしいところ。しかしそうするとインクリメンタル GC との相性などもあるので、かなりハードルが上がりそうだ。
最後に話していた、不可能であるという思い込みを捨てろというのは割と刺さった。よいなぁ。
Ruby Parser In IRB 20th Anniversary…Now Let Time Resume - @aycabta
RDoc のレガシーと戦った話。
全てはこの PR のために。
私は某所で個人的に彼が大変な思いをしながらレガシーと戦っていたのを知っていたので、完全に感極まった。おめでとう!!!
Writing Lint for Ruby - Pocke
発表資料: https://speakerdeck.com/pocke/writing-lint-for-ruby
RuboCop の仕組みおよび新しいチェッカの追加方法などの解説。
質疑応答の中で紹介されていた --parallel
オプションは知らなかったので収穫だった。
AST Visitor パターンの Lint の仕組みについては知識があったが、RuboCop 自体についてはそこまで詳しくなかったので、こういうのがポロッと知れるのはよい。
あとはセッションと別の機会で Pocke さん達と、RuboCop 遅いよね、という話題が上がったけどまあ雑談程度でいい案が浮ぶわけもなく。実際 Cop が増えれば増えるほど原理上遅くなるので、何か解消できる方法があるといいのだけど、何かないかなぁ。
Towards Ruby 3x3 performance - @vnmakarov
発表資料: https://vmakarov.fedorapeople.org/VMakarov-RubyKaigi2017.pdf
英語だったのと内容が高度すぎたのもあって理解がかなり怪しい…。スライドの英語と Twitter のデキる皆さんのツイートを頼りに解読した程度の理解度。
とにかく絶対難しいやつなのにサラッと作ったみたいなこと言ってるのがやばい。そして実際速くなってるとのこと。このセッション以外のアプローチもあるようだし、3x3 は割と見えてきている感じなのかな。すごい。
雑感
- 英語のセッションが全然わからなくてつらい…。リスニングだけでももうちょっとなんとかしないといけないんかなぁ。
- 初日に電源が提供されていることに全く気付かず、ないもんだと思って2日目コードを持って行かなかったら実はあったというアレ。3日目は存分に享受させてもらった。
- 去年はあったとの噂の弁当ランチが今年はないとか、広島平和記念資料館にタダで入れるとか、当日にならないとわからない情報が割とあった。事前に公式サイトで確認できると嬉しかった(実は書いてあったとかだったらゴメンナサイ)
- 前夜祭から始まり、毎日パーティがあって完全に食べすぎた…
- 翌日に響いてウトウトしちゃったセッションもあったり
- LT の感想はいくつか書きたかったけど力尽きた
とにかくめちゃくちゃ刺激を受けた。来年も是非行きたい!