こんにちは。
メディアサービス開発部 Webアプリケーション開発課のフサギコ(髙﨑)です。
Ruby on Railsによるバックエンドの実装運用と、AWSによるサービスインフラの設計構築を中心とした、いわゆるテックリードとして働いています。
本記事では、2023年5月11日から13日にかけて、長野県松本市で開催されたRubyKaigi 2023へ参加したことについてお話します。
RubyKaigiとは
RubyKaigiは、プログラミング言語Rubyにまつわるあらゆるトピックを扱う国際カンファレンスです。 今回は3会場3日間にわたって、Rubyに関する様々な研究開発の成果や、事例発表などが行われました。
Rubyが日本発の言語ということもあり、世界の様々な地域で開催されているRubyについてのカンファレンスの中でもトップクラスに大規模で、日本国外からの参加者も(僕個人の体感ですが)2～3割ほどいます。
2016年以降は首都圏ではなく日本各地で開催されている点も特徴的です。
社員4名で参加
RubyKaigi 2022では僕単独の参加でしたが、今回は前回の教訓1を忘れずに社内で行きたい人を募ったところ、社内の理解もあり僕含め4名での参加となりました。
弊社ドワンゴともに4人ずつだったので、KADOKAWAグループとしては8人が参加したことになります。
1名がLT登壇
また、弊社の相生ゆらが初日のLTにて登壇しました。
このLTでは僕への言及もあったのですが、Official Partyなどで「あのLTで言及されていたのはもしかしてあなたですか？」と、相生ともどもたくさんの方々にお声がけいただきました。ありがとうございます。2
見に行った講演からいくつか
The future vision of Ruby Parser
Rubyのparserに関しての講演。
- Language Serverでの補完などを目的としたエラー回復性
- いまエラーになっている箇所にどのような字句を追加/削除すればエラーにならずに済むか、という視点で補完候補を提示する
- 決定性有限オートマトンの理論を応用できる！
- 字句解析器(lexer)と構文解析器(parser)が密結合していることによる改修の困難さ
- Rubyには実は4種類のdo～endが存在し、それらの区別がこれまでは困難だった
- 演算子の結合優先度を表現する仕組みを応用するとシンプルに決定できる！
- 我々がLR parserの潜在能力を引き出しきれていなかっただけだった！
- どこでも誰でも使える統一されたパーサー
- MRIのみならず、様々な場所でparserは必要とされている
- mruby, PicoRuby, JRuby, TruffleRuby, rurubyといった他実装
- sorbet, typeprof, language serverといった開発支援ツール
- MRIのparserはMRIのC関数に極度に依存している
- 一応動かせるものはできたが、209個もの関数を渡す必要がある
- なんと、parserが直接RubyObjectを作っている = parserの責務をはみ出している
- parserとしての責務に本質的に必要なものだけに整理し、parserの責務を超えるものは後段に移していく
- MRIのみならず、様々な場所でparserは必要とされている
といった内容だと理解しました。
parserについては僕の出身が電話電信を由来とした情報通信系の専攻なこともあって本当に概要的なことしか知らないのですが、 それだけに今もこうやって技術革新が続く古くて今なお新しい分野なのが面白いと思いました。
"Ractor" reconsidered
スライドはこちら。
Webサービスの開発を生業にしているという点から個人的にプログラムの並列実行性に強い興味があり3、Ruby3.0でRactorという名前になる前、かつてGuildと呼ばれていたころから話題としては追いかけているRactor。
安全な並列プログラミングを実現するためにオブジェクトのイミュータブル制約が非常に強かったり、 アクターモデルプログラミングは従来のRubyからの大きな発想の転換が必要、 イミュータブル制約が理由でRubyGemsにある大半のgemが動かないことが理由で. 現時点では残念ながらあまり使われていない4のですが、 現状の打破に向けて、まずは性能改善をしているという内容。
個人的にもRactor使ってみたいのですが、Ractorのような並列実行性が最も必要な個人的ユースケースはやはりWebサービスになってしまうので、そのあたりが難しいところ…5
Optimizing YJIT’s Performance, from Inception to Production
YJITのルーツと性能改善のために作ったyjit-bench、メモリ使用量の削減などのチューニングを地道に繰り返してShopifyでの本番運用へこぎつけたことについて。
YJITの発想のルーツが元をたどるとMATLABのJITにある、というのは興味深い話でした。
Day3のAfter Partyにおいて、ShopifyのUfuk Kayseriliogluさんと話すタイミングがあり、弊社yotaとtukiyoの
の記事を見せたところ、「ああ、この記事見たよ！」と言ってもらえました。
そのうえ、たまたま通りがかったこの講演の発表者のMaxime Chevalier-Boisvertさんを呼びとめてくれて、 YJIT開発の感謝を直接、拙いながらも英語で伝えられたので、非常に嬉しかったです。
Ruby JIT Hacking Guide
去年の講演の続き。
YJITがRuby 3.2でprod readyになった現在、MJITはどうするのだろうと気になっていました。 すると、gccへの依存を完全に外してPure Rubyでx86_64のみを対象とした、試行錯誤のしやすさを重視したRJITへと変貌していました。
しかもチュートリアル付き。
ちょっと興味があるので手を出してみようかなと思っています…が、6～7月は個人的に忙しい6ので、手を出せるのは8月…かなぁ…
松本はいい街だった
会場の松本市は周囲を山に囲われた、しかししっかりとした市街でいい街でした。特急あずさなら片道3時間7千円で新宿まで行けるというのもだいぶ近いなと思いました。
Official Partyや各日のスポンサー企業主催の懇親会では飲み食い交流に夢中だったのでまともな写真は撮っていませんでした！！ 文章だけになってしまいますが、主催してくださった皆様ありがとうございました！！
まとめ
本記事では、2023年5月11日から13日にかけて、長野県松本市で開催されたRubyKaigi 2023へ参加したことについてお話ししました。
3年ぶりの物理開催だった前回を経て、今回は初日終了後のOfficial Partyや各日のスポンサー企業主催の懇親会も開催され、Rubyist同士の交流を深めるRubyKaigiが久々に帰ってきたと実感しました。
僕個人としては今回、日本人だけでなく海外から来てくれたRubyistとも交流する(できれば英語で)というのが密かな目標だったのですが、それもAfter Partyなどいくつかの場所で拙いながらも話せたので、これは達成できたと言えるのではないかと思います。
さて、あとはお決まりのような感じになりますが、ブックウォーカーでは物理・電子・Web連載問わず漫画や本が好き、あるいはRubyに情熱を持っているWebアプリケーションエンジニアを募集しています。
興味がありましたらぜひ下記採用情報ページより、カジュアル面談からでもご連絡ください。
来年の沖縄でもぜひ、お会いしましょう！7
