5月に Ruby Kaigi 2023に参加してきました。
とんでもなく時間があいてしまったので今さらという感じなのですが🙈 参加レポートです。
自宅から離れた場所でのオフラインのイベントに参加したのは私にとってはじめての体験でした（東京近郊では何度か参加していたのですが）。
現地参加できて本当によかったです。
松本での Ruby Kaigi はめちゃくちゃたのしかったです。
- 思ったこと
- セッションの内容
- 参加レポート
- 来年は
- 後日談 / 会社のテックブログ
思ったこと
Ruby コミュニティ
松本の至るところに Rubyist が集結していて、Ruby コミュニティを肌で感じました。
知ってる方が会場のあそこにもここにも！という感じで、この方たちがみんな Ruby をつくったり、Ruby をつかったりしていると思うと感無量でした。
そして、自分のその Ruby コミュニティの一人として関わっていきたい・・！という気持ちになりました。
自分は、こどもがいてなかなかコミュニティへの参加に時間などで壁を感じていたのですが、だんだんこどもも大きくなってきて、先日の Rails Girls へのコーチ参加などをはじめ、Ruby コミュニティに参加していきたいです。
地域.rb に参加していきたい・・・！！
秋の Kaigi on Rails に参加したいですし、大江戸 Ruby Kaigi も参加したいと思いつつ迷い中です（こどもを一人にできないので、自分か夫のどちらかが参加することになりそう）
Ruby Friends
4月に、Rails Girls Tokyo 15th にコーチとして参加したのですが、このときに参加して本当によかったです。
会場で、Rails Girls のときにコーチをされた人や Girls の方、他の地域で Rails Girls のオーガナイザーをされた方などとお話したり、すれちがったりすることができました。
また、同僚の方が、フィヨルドブートキャンプの方を紹介してくださったりして心強かったです。
セッションの合間に話しこんで、キャリアの話をして思わず話が深まったり、今の会社で少し前に退職された方にお会いできたり（残されたコミットログや Issue コメントで一方的に知ってる方に会えた！という感じでうれしかった）、オフラインならではの人との関わりがとてもたのしかったです。
セッション
セッションは、Parser や YJIT の話などが印象的でした。
複数のセッションで、parse.y のお話が出ていて、「大パーサー時代」なんて言葉も聞きました。
セッションを聞いただけではわからないことも多く、まだまだこれからいろいろ知っていきたいという気持ちが強くなりました。
これもセッションの合間に人とお話していて印象的だったのですが、Ruby Kaigiに初参加する人のセッションの理解度はとても低いので、生活発表会なので、普段から Ruby の動向を追っていないと理解していくのがむずかしい、というお話をお聞きしてなるほどなあと思いました。
普段から地域.rbなどに参加したり、GitHubのリポジトリをキャッチアップしていると、この話題については誰を追っていくと良いかということが段々わかってくるので、そうやって1年間追い続けていくと次の Ruby Kaigi ではだんだんついていけるようになる、とお聞きしました。
つまり、日常から追っていないと理解できないということだと思います。
キャッチアップして、来年の Ruby Kaigi ではいろんなセッションの理解度を上げていきたいと思っています。
日々仕事でいっぱいいっぱいになりがちですが、Ruby の動向を日常から追っていきたいです。
英語！
興味のあるセッションが時々英語だったりした場合、英語のセッションも聞いていたのですが、そもそも難しい内容に加えて、英語の理解力が低く、かなりむずかしかったです。
また、発表のスライドも、基本英語でした。
また、Ruby コミッタの方が、英語で話しかけてくださったのですが、英語で言いたいことや聞かれたことの答えを伝えることがむずかしく、せっかく話しかけてくださったのに思うようにコミュニケーションできなかったことが悲しかったです・・・。
英語も課題だとひしひしと感じました。
たのしいは正義
Ruby Kaigi に参加していろいろな方としゃべったり、スタンプラリーをまわったりしながら、会場の Rubyist がめいっぱいたのしんでいることをひしひしと感じました。
こんなたのしさを感じられる Ruby コミュニティに参加することができて、なんてしあわせなことだろうと思いました。
スポンサーブースのスタンプラリーがあったり、最近本を出版した Rubyist の方に声をかけてスタンプをもらう Rubyist Book Authors スタンプラリー があったり、たのしいことがいっぱいでした。
「はじめてつくるWebアプリケーション」で江森さん、やださんに、「RubyとRailsの学習ガイド2023」で igaigaさんにサインをいただきました！
お話するきっかけにもなってありがたい企画でした。サインもうれしかったです。。。
そしてたのしいやることがいっぱいあって、現地参加の2日間は息つくまもなく、たのしく、いそがしかったです。
冷蔵庫
会場には、奥の方に冷蔵庫が並ぶスペースがありました。
Cookpad さんの提供で、冷蔵庫と、その中にクラフトビール、りんごジュース（数種類）が提供されていて、自由に飲むことができました。
なんてありがたい・・・！！
クラフトビールのパッケージは、Ruby Kaigi 仕様になっていて、めちゃくちゃかわいかったです。
I ❤️ Matsumoto
とにかく松本という街が大好きになりました。
まず、松本城がすてきでした。黒くて落ち着いていて、山を背景にそびえています。
街には川が流れていて、川辺で山を臨む景色もよかったです。
街の中に、湧き水を汲める井戸のような場所がいくつかあって、おいしい水を飲むこともできました。
街の雰囲気が少しレトロでとても良かったです。
蕎麦、ビール、おやきなど、おいしいものもたくさんありました。
モーニングをやっている喫茶店が多く、また喫茶店もとても雰囲気のあるお店が多そうで、また来たいです。
モーニング巡りをしたいです。
イベント
私は1泊だけだったので、参加できたのは、2日目夜のMNTSQさんのイベントだけでしたが、 会期中、たくさんのイベントが開催されていました。
またこういった公式のイベントだけでなく、お昼ごはん誰か一緒に行きませんかというやりとりなど、そこら中で Rubyist どうしが繋がっていく様子が感じられました。
コロナ
イベント会期中や終了後、Ruby Kaigi に参加した方でコロナ陽性になったという声がちらほら聞こえてきており、どきどきしました。
幸いにも、自分はなにも起こらずに済みました。
これだけ大規模なオフラインイベントとなるとコロナは避けられないのだな・・・と感じました。
感謝のきもち
今のプロダクトに関わっている Web プログラマのけっこうな人数が Ruby Kaigiに参加していたので、残っていたメンバーの負担が大きかったと思います。
快く送り出してくださった同僚のみなさん、参加を支援してくれた会社に、ただただ感謝でした。ありがとうございました。
そしてこんな素敵な Ruby Kaigi をつくりあげてくださった運営の方、登壇された Rubyist たち、スポンサーの方々、多くの人に感謝のきもちでいっぱいでした。
Ruby Kaigi 最終日に、スライドに「Nice Team!!!」とあるのを見て、胸が熱くなりました。
恩返ししていかねば。
セッションの内容
聴いたセッションについていくつかピックアップして書きます。
その場で聞いて理解がむずかしかったものも、改めてスライドや動画を見返すと、そういうことをお話されていたのか！という気付きがありました。
聴いたセッションについて全部書きたいのですが、1日目に聴いたセッションについて書いたところで息切れしてしまったので、今後、書き足していきたいと思います 🙏
（セッション内容について、別記事に切り出すかもしれません）
30 Years of Ruby / Matz Keynote
Ruby の生みの親である 'Matz' こと まつもとゆきひろさんが、Ruby の30年の歴史をいくつかの時代に区切りながらふりかえり、その時々で得た教訓や未来へ向けた展望を語ってくださいました。
最後に「Rubyコミュニティ全体でRubyをよくしていくことに、みなさんに参加してもらいたい」と締めくくられていて、「今後のRubyは、このRubyKaigiに集まっているみんなで作っていくのだ」と気持ちが盛りあがりました。
会社のテックブログに、このKeynoteについて記事 を書いたので、よかったらお読みください。
The future vision of Ruby Parser
Ruby の Parser の将来についてのセッションでした。
Ruby の Parser には現状、Usability、Maintanability、Universal Parser がほしいという3つの課題があり、それにどう立ち向かっていくのかというお話でした。
自分は初見で理解が追いつかず、あらためて録画を見ておお！となり、Parser に興味がわいてきました。
1. Usability
- 不正な入力に対してもきちんと ASTを作ってほしいという要望に対して、不正なtoken を Insert / Deleteして Syntax Error から回復させるアプローチがある
- Ruby のパーサジェネレータの Bison は、環境によってバージョンが違うため、このInsert / Delete によるリカバリをBison に実装することは大変
- そのため、Ruby で Lrama というパーサージェネレータを作成
- yaccとBisonの系譜なので、4本足の動物ということで Lrama
- セッションの理解のために以下の記事が参考になりました
2. Maintainability
- parse.y はむずかしいと巷でよく言われている
- 特に、Parser（構文解析器） と Lexer（字句解析器） が密結合しているというやばい問題がある
- たとえば、Ruby の do は4種類のtokenがあり、Lexer はこの4つを条件を見て切り分けている
- Ruby の根深い問題であった do も、既存のテクニックを使って解決できた
- その解決法は、parse.y の記法だけを変えた、つまりDSLだけを拡張した
- LALR parserのアルゴリズムは変えていない
- LALR parserの本当の力は引きずり出せていなかった
3. Universal Parser
- Universal Parser がなぜほしいのか
- mRuby などのほかの Ruby 実装やツールなどで、Ruby の Parser を使ってASTがほしいという要望があるが、いちから実装するのも大変、毎年 Ruby がリリースされるたび Parser も変わっているので追従が大変だから
- Ruby の Parser は Ruby の機能を使っていていろんなものが入っている
- この解決には、以下の2つの方法を組み合わせてやる必要があった
- Parserの機能のうち、Rubyとして渡している機能は、関数ポインタとして外から渡す
- 既存のものをコピーしたり、ファイルを整理してparse.oに対してリンクしてshared object を作る
- GitHub - yui-knk/ruby at universal-parser
- できあがったものの、209個の関数を用意するインターフェースになったので、もう少し整理していかなければいけない
LR Parser
-
-ドラゴンブックの表紙の戦士が持っているものは
LALR Parser Generation - この問題に立ち向かうには、LR parser しかないという結論
- そのために、今回、Lramaという pure Ruby の LALR parser を用意したので、これに機能を実装していきましょう
今後の展望
- LR Parserを基盤に据えて
- 入力するファイルのDSLをつけ足していくことでLR Parserができることを増やす
- Lexer に載ってるロジックを文法定義に持ってきたい etc
Understanding the Ruby Global VM Lock by observing it
by Ivo Anjo
Global VM Lock (以下、GVL) についてのセッションでした。Datadog のシニアエンジニアの方だそうです。
GVL についてふんわりとした理解なので、聞きたくて参加しました。
実際に、GVL がどのようにロックを取るか、gvl-tracing という gem を開発して、可視化した様子を見せてもらいました。
こちらの記事が理解の助けになりそうでした。
以下、メモです。英語で聞くのはむずかしかったですが、スライドがとてもきれいにまとまっていて理解の助けになりました。
What is the Global VM Lock(GVL)?
- Ruby VM is a big program that is written in C
- That uses multiple OS threads
- GVL is mechanism/strategy to ensure correctness of ruby the multi-threaded c program
What’s a lock?
- 一つのブランコ、一人しか乗れない
- It's a mechanism that allows only one thread to work at-a-time
- Whane a thread inside the Ruby VM is
What is the GVL not ?
- GVL allows concurrency （同時実行性）
- Illusion of working on multiple things at the samge time by switching between them
- (ninja)
- but not parallelism （並列処理）
- actually working multiple things at the same time
- GVL only protects the Ruby VM data/state
- The GVL does not protect Ruby code running in multiple threads
Observing the Global VM Lock
- Ruby3.2 introduced the GVL Instrumentation（計装） API
- これを基に、gvl_tracing というgemを作った
- Draw GVL usage in a visual timeline
- Concurrency but not parallelism
- Threads take turns to execute
- Adding more threads to example makes each threads wait longer between executions(2 threads ⇒ 10 thread)
- Adding more threads to a Ruby app impacts latency when multiple threads want the GVL at the same time
- Runs for 100ms / Wait for 900ms
- Ruby threads are “noisy neighbor"
- Ractor is introduced in Ruby 3 as a new concurrency primitive
- Ractor is parallel 🎉
What do you do with this information?
- Avoid using too many threads if you are latency-sensitive
- Separate latency-sensitive code from other things
- Don't guess: experient and measure! （推測するな、計測せよ）
- Ractors, JRuby and TruffleRuby can unlock performance + latency benefits
- Always remember the GVL is not protect your code
- The future is blight, Ruby is always improving and evolving
- Ractor, YJIT, MaNy Project(M:N threading), 10ms thread switch?
"Ractor" reconsidered
Ractor は、Ruby で並列処理を行う機能です。 このセッションでは、Ractor が現状あまり広く使われておらず、足りていない機能とその難しさ、その困難の解決法、今後の展望について話されていました。
Ractor の前提理解には、このあたりが参考になりそうでした。
私は最近、達人プログラマーを読んだのですが、「並行性」を扱う章で、アクターとプロセスという方法が説明されており、アクターとプロセスによって、共有メモリーの同期という重荷を背負うことなく並行処理を実現する方法が提供されるとありました。
上に貼った記事によると、Ractor は Actor モデルを意識して設計されているようです。
（追記）
8月ころに公開されていたこちらの記事が、Ruby の並行並列処理の今までとこれからの展望がまとまって書かれていて、Ruby Kaigi 2023 での講演の位置付けもとてもわかりやすかったです！
techlife.cookpad.com
以下、セッションのメモです。
Ractor は
- マルチコアでのよりよいパフォーマンスのための、Ruby の並列プログラミング
- 堅牢な同時実行（concurrent）のプログラミング（オブジェクトの共有によるバグが発生しない）
- でもあまり使われていない 😢
Ractor の難しさと課題
- プログラミングモデル
- メモリモデル（オブジェクト共有モデル）
- オブジェクトの共有を行わないことで並列処理を実現している
- オブジェクト空間の分離を維持するために、Ractorは厳しい制約がある
- 定数は共有不可能なオブジェクトを参照できるが、グローバル変数は参照できない
- 既存のライブラリは、修正なしには動かないので、エコシステムが欠如してしまう
- メッセージパッシングAPI のような Actor
- send/receiveメソッドを備えた従来の Actor スタイル
- Ractor.select による複数イベントの待機
- オブジェクトの分離を維持するための Copy/Move セマンティクス
- 共有可能なオブジェクトのための参照による送信
- Copyによる送信
- Moveによる送る
- メモリモデル（オブジェクト共有モデル）
- コードの品質の低さ
- CIが数日ごとに失敗する
- パフォーマンスの低下
- 現状は、あまり使われていないのでフィードバックがなく、エコシステムが育たない状態
- 今後の予想される状況として、品質とパフォーマンスを改善して、使ってもらって、フィードバックを得てエコシステムを成長させていきたい
最近の改善
- Ractor の同期コードをすべて書き直した
- CI が失敗しなくなった！
- Ractor::Selector APIの導入
- Ractor.selectはO(n)を必要としている
- 事前登録API
- 待機コストはO(1)になる（現在の実装ではO(n)）
- native threads にスレッドに依存しているため、パフォーマンスが悪い問題
-独自のM:Nスケジューラの導入
- MaNyプロジェクトのラクター
- MaNyプロジェクト： RubyでMaNyスレッドを作る(RubyKaigi 2022)
- 昨年はRubyの Thread を使ったM:Nスケジューラについてだけ紹介したが、Ractorもサポートされた
今後の取り組み
- さらなるパフォーマンス向上として、Ractor local GC
Lightning Talks
5分刻みで LT が12本。
みなさん結構早口で、いきおいのある LT で、技術的な話ももちろん、去年の Ruby Kaigi きっかけで転職できたというお話もあったり、とても聞いていてたのしかったです。
制限時間になると、銅羅の音がドーン！となるのも、Ruby Kaigi ならではな感じでたのしかったです。
参加レポート
1日目はオンラインで視聴し、2-3日目は松本へ移動して現地参加しました。
こどものことがあるので、泊まるのは2日目の夜の1泊のみの予定にしました。
1日目 オンライン
リモートで働きつつ、タイムテーブルに合わせてセッションを聞いていました。
Twitter で #rubykaigi のハッシュタグを追いかけて現地の様子を感じつつ、次の日の現地参加への期待が高まりました。
Ruby Kaigi に快く送り出してくれた同僚のみなさんに感謝でした。
2日目 松本へ
朝、5時半頃に起きて、新宿から朝一番の特急あずさに乗り、松本へ向かいました。
向かう旅路でも #rubykaigi のハッシュタグを見て、朝に松本の街をめぐったりモーニングをたのしむ Rubyist の様子を観測しながら、松本でやりたいことのあれこれを考えていました。
こどもが生まれてから、泊まりで1人で出かけることがはじめてで、とてもわくわくしていました。
松本駅に着くと、Ruby Kaigi 歓迎などの垂れ幕やデジタルサイネージを見て、いやおうなしに気分がもりあがりました。
セッションは、3つの会場で行われていたので、スケジュールを見ながら、興味のあるセッション会場へ移動をしていました。
午前のセッションを聴き終えてお昼ごはんをどうしようと考えていると、Rails Girls でご一緒した方がちょうど通りかかるのを発見。声をお掛けして、一緒にお蕎麦を食べに行きました。お蕎麦屋さんにも、Rubyiest がたくさん来ていました。
松本城近くのお蕎麦屋さんだったので、お昼の後に松本城を散策してから会場へ戻りました。
夜は、MNTSQさん主催の MNTSQ Beer Hush!!! というイベント（ドリンクアップ！）に、同僚と一緒に参加しました。
フィヨルドブートキャンプの方やたくさんの方々と話して、いろんな仕事・キャリアを垣間見ることができました。
業務委託で同じプロダクトを一緒につくってくださっている方とも直接お会いしてごあいさつすることができてうれしかったです。
会場では、松本ブルワリーさんのクラフトビールを数種類選ぶことができ、ビールは美味しく、Rubyist との交流もたのしい時間でした。
イベントの様子、MNTSQさんのこちらの記事にありました。
夜、ホテルへの帰り途中にどうしてもラーメンが食べたくなり、松本ブラックを食べました。 （中華そばマルキ商店というお店のラーメンです）
3日目 松本で最終日
あっという間に最終日になりました。
3日目がはじまる前に同僚と待ち合わせして、会場近くのカフェ 栞日 で朝ごはんを食べました。お店はすぐ人でいっぱいになっていました。Rubyist がほとんどだったと思います。
待ち合わせの前に時間があったので、松本城まで足を伸ばしたりしました。
最終日の全セッションが終わったあとは、帰りの電車の時間が迫っていたので、会社のみなさんと記念撮影したあとに急いで駅へ向かいました。
帰りの電車で食べる駅弁を買おうと思ったのですが、駅の売店はほとんど売り切れていて（帰途の Rubyiest がみんな買ったから・・？？）、かろうじてホームの売店でおにぎりを買うことができました。
帰りの電車で、また #rubykaigi のハッシュタグを追いつつ、余韻にひたりながら帰りました。
（家に着いたら、こどもが1日早い母の日で花束をプレゼントしてくれてとても感慨深い日になりました）
来年は
来年は沖縄の那覇開催だそうです！めっちゃ行きたい・・・！！
仕事次第ですが、家族で行けたらそれもいいなと思ったりしています。
後日談 / 会社のテックブログ
Ruby Kaigi 2023に参加した会社の有志で、参加レポートをテックブログに書いたので、よかったらお読みください！ （自分は前述のとおり、Matz Keynoteについて書きました）
