Day 2 のあとに ruby.wasm をいじってたら README のインストール手順に誤りを見つけたので Pull Request を作り、マージされた。
Update installation instruction in README.md by kyanny · Pull Request #41 · ruby/ruby.wasm · GitHub
Kaigi 期間中の熱いうちに一つこなせてよかった。
error_highlight: user-friendly error diagnostics - RubyKaigi 2022 ★★★☆☆
細やかな開発者体験向上の機能の裏側について。エラーメッセージのフォーマット（一行→複数行）にも後方互換性を気にしなきゃいけないなんてコア開発者は大変だ。
ターミナル出力時のセキュリティ対策でエスケープシーケンスがダブってエラーハイライトの位置がずれる問題を、「これもう不要でしょ」と主張して消すために地道に証拠集めをして・・というあたりが真っ当でよかった。
Syntax Tree - RubyKaigi 2022 ★★☆☆☆
どっち聞くか迷ったが、直前でこっちにした。が、おそらくこのトークを聞くための前提知識が色々足りてなかったっぽくて、途中から何の話ししてるのかついていけなくなった。これなら裏のほうを聞いたほうがよかった。まだ頭が起きてなくて眠くて、英語もところどころ聞き取れないのもわからないに輪をかけた。
Real World Applications with the Ruby Fiber Scheduler - RubyKaigi 2022 ★★★☆☆
これも当日朝にこっちを選んだが、正解だった気がする。10 年前、自分のネットワークで使うために Ruby で DNS サーバーを自作したが問題があり、かつて一世を風靡した EventMachine を使えば解決できたがすべてのコードを書き直したくなかった。Celluloid も使ったが内部実装が複雑で、長期に渡って信頼がおける基盤かというと疑問があった。そういう自分自身のニーズから来る不満を解消するために async gem を作り、falcon も作り、最終的に RubyDNS も async gem で満足のいく出来になった、と。最後に so I feel I've achieved my goal. 的なことを言ってたのが印象的で、とても良かった。
falcon がなぜ fiber ベースだと puma よりパフォーマンスが良いのか、あたりはよく理解できなかった。スレッドプール方式だと無駄が発生するので良くない、的なことを言ってた気がするが、その部分はメモを取りそびれていた。
英語もまあまあ聞き取れて、話していること自体は結構ついていけた。
やはり real world の話が面白いなと思う。
Why is building the Ruby environment hard? - RubyKaigi 2022 ★★★★☆
「環境構築に異常に詳しい」
「自分には簡単だけど他の人にはそうでないことは『特技』」これにはなるほどと思わされた。これを聞けただけでも割と元は取れた感がある。
紹介された事例についても細かくメモをとったはとったけど、まあ資料が公開されるだろうからそれを見ればいいだけで、あえて書くこともなし。
「何もしてないのに壊れた→何もしてないからこそ壊れる」「ソフトウェアを取り巻く環境の変化に適応する」これも、なるほどなーと感心した。
おれもかつては環境構築マニア、とは言わないが、環境構築でハマった経験は人並みかちょっと多めにありそうな気がするし、直すの案外嫌いじゃないので、関心ある分野だなあと思った。
The Better RuboCop World to enjoy Ruby - RubyKaigi 2022 ★★★★★
今回の RubyKaigi で一番期待値が高かったトーク。これは期待に違わず聞いてよかった！
初学者にとっては RuboCop に怒られないコード = Ruby のコード。そんな彼らに「Ruby は書きやすくてやりたいことがすぐにできるのが良いところ」という感覚を持ってもらうにはどうしたらいいのか、シニアエンジニアはもっと考えた方がいいのではないか。考えさせられる提言だった。
シニアにとっての問題点を、「"Style Guide" に引っかかりがある」「Ruby っぽい Style Guide って動的なものなんじゃないか、『正しい Style は静的に定まる』というのが RuboCop の思想で、しかし DSL とか『Ruby らしいコード』には必ずしも当てはまらないのではないか、スタイルはときとしてスタイルではなく心（ハート）で、心に対して RuboCop に何やかんや言われるから『痛い』のではないか」、という風にうまく言語化していて、フェアで優しい議論だと思った。
「ルールを『強制レベル』と『提案レベル』の二つに分ける」という提案も実践的かつ漸進的で、おれは話者の名前はもちろん以前から知っていたが実物を見るのは初めてだったが（といってもオンラインだが）、話者の人格が垣間見えるような気がした（もちろん良い意味で）。
RuboCop に限らず linter の類は好きではなくて、RuboCop は特に嫌いなのだけど*1、このトークを聞いて「頭ごなしに否定するのは良くないな」と身につまされた。
Ethereum for Ruby - RubyKaigi 2022 ★★★☆☆
ペパボ時代の後輩が喋るならせっかくだから見ておこうか、と選んだ。英語で喋るとは思ってなくて意外だった。これはちゃんと練習してきたことがうかがえて好印象だった。ブロックチェーン周りはほとんど触ったことがなく、暗号通貨とか Web3 とかは興味ないのだけどブロックチェーン技術そのものは少しくらいは触って理解しておくべきだよなあと数年思っていて、特にスマートコントラクトはなんか面白いアイデアに思えて理解を深めたいと思っていたので、Ruby でもその辺のエコシステムを触れることがわかって収穫だった。スマートコントラクト自体は Solidity という言語を使わないといけないにしても、プラットフォーム側？のツールチェインに不慣れな Python とか Go とか Node.js とか（でできるのかも知らないが）を使うくらいなら Ruby でできた方がハードルが低いので。
String Meets Encoding - RubyKaigi 2022 ★★★★☆
エンコーディングの話は面白そう、と思って期待して聞いたが、エンコーディングそのものはあんまり関係なくて当初の期待とはやや違った。「私は文字と文字コードに興味があって」昨日の Wireshark の人といい、ハードコアな部分が好きな人が活躍していることだなあ。
プロファイリングをとって見ていくあたりは聞いててちょっと退屈だったが、String#split の最適化方針の考え方は論理的・正しい着眼点で、とても真っ当だなあと思った。
特定の処理の 10% の改善というと JIT みたいな本体の大幅な高速化に比べてインパクトが低いように見えそうだが、こういう局所的な最適化も重要だと思う。特に、実際のアプリケーションで誰もが実際に頻繁に使う処理では、数パーセントでも幅広く恩恵があり、トータルインパクトは大きい。そして、本体の高速化とかは然るべき人たちがやり、局所的な最適化もモチベーションがある人がやる、というのは、今回の Kaigi で何度かキーポイントとして触れられた「コミュニティ」が健全に機能していることの証左だよなあと思った。
Ruby programming with types in action - RubyKaigi 2022 ★★★☆☆
裏のるりまの話も聞きたかったのだが、せっかくデモやるならリアルタイムで見ておくか、とこっちを選んだ。が、肝心のデモが不発で残念だった。
日本人の英語プレゼンにケチをつける嫌なやつ状態だが、この人の英語はどことなくインドのアクセントっぽく聞こえて不思議な感じがした。イギリスかオーストラリアのアクセントも少し混じってそうにも聞こえた。喋りは flow が良いというか、抑揚・メリハリがはっきりしていて、聞いていて引き込まれる感じがした。明らかにスピーキングスキルがとても高い。
最後のまとめのあたりで、実装 - テスト - 型 - デザイン（設計）の左側ほど具体的で右側ほど抽象的で、型（RBS）はテストとデザインの中間くらいだから変更しやすく、型を変えながら良い API を設計していく、実装・テスト・型を行ったり来たりしながらコーディングしていく（Steep のエディタ連携支援によってそれをやりやすくする）、というのが、確かにそれなら大規模プロジェクトとかでなくても型を書く・使う動機になりうるな、と思った。まあ Haskell とか型でプログラミングする世界の人たちにとってはずっと昔から当たり前の世界観だったのだろうが。
Stories from developing YJIT - RubyKaigi 2022 ★☆☆☆☆
何か事情があったのか開始が遅れて、スポンサーセッションが二つ挟まった。二つ目は突発？だったようにも見えたが、Creative Survey というアンケートシステムの会社の CTO? の人が英語で自社サービスの紹介を始めて、今回の RubyKaigi で聞いた日本人の英語の中でこの人が一番上手かった気がした。帰国子女とか海外在住経験長い系だろうか。
最後のトークはもう難し過ぎてさっぱりついていけなかった。ライブストリーミングサイトのチャットに貼られたツイートに「CPU の仕組みを知らないとこのトークは理解できないだろう」と書いてあって、あーじゃあおれにわかるわけないわ、と心が折れて、途中からは全然関係ない Twitter とか眺めていた。あれはコア開発者向けの講演だった。
Closing
松田さんのお気に入りセッションとして初日の wasm と trick の紹介があって、wasm で ruby 実行できるデモコードで trick の作品の一つをコピペしてブラウザ内で動く！という即興デモをやってて面白かった。
Ruby を、お金を稼ぐために（仕事として）、「Rails の言語」として使ってる人もいる、それはそれで構わない、けど Ruby はこんなふうに面白いおもちゃとしても使える、というデモンストレーションは、RubyKaigi に数多くのスポンサー企業がつくのが当たり前の光景になったからこそ、あえて強調していう意味があることなのかなあ、と思った。
ちょっとセンチメンタルな感じの話が続いて、現地に行きたかったなあ、でも人との交流は下手だからオンラインがちょうどいいのかもなあ、など考えてしまった。
最後にこれだけは聞いておかねばならない、次回について。来年の五月、連休の翌週。場所は 2020 年にコロナでキャンセルになった長野県松本市。金沢から割と近い？まさかの会期中毎日通い、なんてことになったりして。来年五月なんてずいぶん近い気がするけど、八ヶ月後と聞くとそうでもないのが不思議だ。
*1:細かいところは好きに書かせろ、というのと、感性で決めるべき良し悪しをツールごときが決めるな、というのと、でも一番嫌いなのは他人とルールの是非について議論すること・他人同士が議論してるのを見ることで、要は「おれの書くコードの審美的な良し悪しを他人であるお前に決められるのは我慢ならん」というプライドがヘイトの源泉にあるのだろうな、と内省した。ルールの議論が不毛で時間の無駄、というのは副次的な理由に過ぎない。
