RegionalRubyKaigi レポート (89) 大阪 Ruby 会議 04
初稿：2025-01-22
RegionalRubyKaigi レポート (89) 大阪 Ruby 会議 04
- 日時：2024 年 8 月 24 日 (土) 10:00〜20:50
- 場所：中之島フェスティバルタワーウエスト 4F 中之島会館ホール
- 主催：Kyobashi.rb (キョウバシアールビー)
- 後援：Ruby 関西 (ルビーカンサイ)、日本 Ruby の会
- Togetter まとめ： https://togetter.com/li/2425167
- 公式タグ・ Twitter：#osrk04
- オフィシャルグッズ：https://suzuri.jp/kyobashirb
大阪 Ruby 会議とは
2018 年 7 月 21 日 (土) に大阪 Ruby 会議 01 がはじめて開催されました。以前までは関西 Ruby 会議という名前で開催していましたが、より地域に密接した Ruby 会議にしようというということになり、ローカルな大阪 Ruby 会議として開催されました。
第 4 回となる今回は大阪市中央区にある中之島フェスティバルタワーウエスト 4F 中之島会館ホール で開催しました。総勢 150 名 (運営スタッフ含む) の方にご参加いただきました。
セッション
Opening Talk
- 発表者
- ydah (@ydah)
大阪 Ruby 会議 04 の開催の挨拶をいたしました。
Keynote: 最高の構文木の設計 2024 年版
Parser や Parser Generator の未来を探求している金子さんが、現在考えている構文木の設計についてのお話でした。 他の言語の Parser を見ても、それらが生成する構文木に明確な原理原則や設計方針があるとは思えなかったそうで、今回はユースケースを分析し、その骨子をまとめられたとのことです。
LSP (Language Server Protocol) や RuboCop のユースケースを照らし合わせる中で、Ruby が提供する構文木の設計を検討すると、本当に多様なユースケースが存在することが明らかになったそうです。 それらを解決するために、具象構文木 (Concrete Syntax Tree : CST) という抽象構文木では失われる括弧や空白文字といった情報を保持する構文木や、Red Green Tree という Roslyn で発明されたアプローチで、解析した構文を2つの木構造として表現する手法で、多様なユースケースに対応できる構文木の設計を提案されていました。 Ruby の構文木の理想的な姿を考察するだけでなく、これまで人類が見落としてきた設計を Ruby のユースケースに結びつけた金子さんの分析と設計力には、さすがだと感じました。
dRuby 入門者による あなたの身近にある dRuby 入門
- 発表者
- makicamel 氏 (@makicamel)
- 資料
- スライド dRuby という分散オブジェクトシステムを実現するライブラリについて、入門者の視点から解説していただきました。 分散オブジェクトシステムとは、複数のプロセスやマシン間でオブジェクトを共有できるシステムのことを指します。
身近な例として、RSpec、ActiveSupport、Rabbit、るりま でも dRuby が利用されているとのことでした。 トーク全体を通して、dRuby に対するワクワク感が一貫して伝わり、その魅力をより一層感じられる素敵な内容でした。
RubyKaigi 公式スケジュールアプリ開発で得た、Hotwire の使い方
RubyKaigi の公式スケジュールアプリを開発する中で、Hotwire を活用した開発の知見を共有していただきました。 前回の 大阪 Ruby 会議 03 でも Hotwire に関するセッションがあり、非常に注目を集めている技術であることが伺えます。
注意が必要な点はあるものの、制御をすべて Rails 側で一元化できる点や、HTML のセマンティクスを尊重できる点は非常に魅力的ですね。 直面した課題についても、実際にどのように解決したかを具体的に説明していただいたので、これから Hotwire を導入しようと考えている方にとって非常に参考になる内容だったと思います。 以下のスライドにも、この取り組みについて詳しく紹介されているとのことです。あわせてご覧いただけると、より理解が深まるかと思います。
https://www.docswell.com/s/kinoppyd/KQ86MW-schedule-select-meets-hotwire
ランチタイム
ランチタイムは、会場近くのお店で各自ランチを楽しんでいただきました。
著者がよく訪れるキッチンルミエール さんでは、大阪 Ruby 会議 04 当日の 24 日 (土) 限定で、ランチメニューのご飯を 「蘭王の目玉焼きご飯」 に無料で変更できるサービスを提供してくださいました。多くの参加者に喜んでいただけたようで、本当にありがたいご厚意でした。ありがとうございました。
Re-line 〜 IRB・Reline 複数行編集の裏側
IRB や Reline のメンテナーであるぺんさんによる、Reline のリアーキテクチャについてのお話でした。 補完候補を表示する際に出力されるダイアログの実装の複雑さを、3D レンダリングの手法を参考にして解消されたとのことです。
一見異なる分野のように見えても、実は繋がりがあるという視点は非常に重要だと感じていて、単にリアーキテクチャの話だけでなく、ぺんさんが開発する際に考えていることや大事にしていることが詰まったお話でした。 「当たり前のことを当たり前にやるとソフトウェアは確実に良くなる」という言葉は、これからもずっと心に留めておきたい言葉です。
Rust で作る TreeSitter パーサーの Ruby バインディング
- 発表者
- joker1007 氏 (@joker1007)
- 資料
TreeSitter という Rust 製の Parser Generator を Ruby から利用するためのバインディングを作成され、その中で得た知見を共有していただきました。 「パーフェクト Ruby」をもし改訂するならば、Rust で書く RubyGem の章を追加したい、そしてその開発方法を身につけておきたいという思いから、今回の発表テーマを選ばれたそうです。
Rust の言語上の制約が Ruby の世界とのやり取りにどのような影響を及ぼすのか、またどのような落とし穴が存在するのかについて丁寧にまとめられており、大変参考になりました。 これから Rust を使って Ruby のバインディングを作成しようと思う方々にとって、非常に有益な資料として長く活用されるのではないかと感じました。
補足については以下のブログ記事にて解説されているので、あわせてご覧いただけるとより理解が深まるかと思います。
https://joker1007.hatenablog.com/entry/2024/08/26/112124
競技プログラミングでみる Ruby の豊かさ
- 発表者
- haruguchi 氏 (@haruguchiyuma)
- 資料
Ruby で競技プログラミングをされている haruguchi さんによる、競技プログラミングを通じて Ruby の豊かさを感じたというお話でした。 競技プログラミングでは、普段の開発で重視される「可読性」「拡張性」「保守性」といった要素がさほど重要視されないため、普段とは異なるコードを書く楽しみがあるとのことでした。
短いコードで問題に特化した解法を目指す、コードゴルフのような要素も取り入れられており、試行錯誤しながらさまざまな書き方を考える楽しさが伝わってきました。 また、「攻略本に載っていない書き方」を探求する過程は非常に魅力的で、Ruby の多様な表現力を知ることで、より一層その豊かさを実感できる内容でした。
Minify Ruby Code
JavaScript の UglifyJS や Terser のように、ソースコードのサイズを小さくする Minify 技術を Ruby に適用する取り組みについて紹介していただきました。 発表順は偶然ではありましたが、「同じ振る舞いなら短い方が良い」という観点から、haruguchi さんのセッションともリンクしているように感じ、興味深かったです。
設計方針や選択の理由が明確に説明されており、koic さんがどのように考えながらこの gem を構築したのかを知ることができる内容でした。 さらに、「Minify で壊して RuboCop で直す」という、RuboCop のエッジケース発見ツールとしての活用という展開も含めて、koic さんにしか出来ない話だなと感じました。
strscan なしで文字列をスキャンする
- 発表者
- 前田 修吾 氏 (@shugomaeda)
- 資料
StringScanner クラスを使わずに文字列をスキャンする方法について解説されています。
StringScanner の基本的な利用方法や正規表現に関する解説を踏まえ、String#index や String#byteindex の利便性と課題についても掘り下げられていました。
課題に対する解決策として、提案された MatchData#bytebegin/byteend の紹介とnet-imapの修正の例の解説がありました。 なお、この提案は大阪Ruby会議04をきっかけに提案されたそうで、Ruby 3.4 で導入されています。以下に提案の PR へのリンクを記載します。
https://github.com/ruby/ruby/pull/10973
どうしてこうなった？から理解するActive Recordの関連の裏側
Active Record の関連先の自動保存と双方向の関連付けについて、どのような動作になっているのかを解明していくお話でした。
前半では、関連を定義した際にどのようなコールバックが定義され、そのタイミングがいつなのか、また関連先の保存がどのように行われるのかについて、具体的なコード例を交えながら解説されていました。 後半では、双方向の関連付けについて、inverse_of の動作が順序立ててわかりやすく説明され、仕組みの理解が深まる内容でした。
また、紹介されていた save_chain_inspector という gem は、関連保存の処理をトレースできるツールとしてとても便利で、双方向の関連を有効にした際のデバッグに非常に有用だと思いました。 さらに、この発表は以下のブログ記事を元にしているとのことですので、あわせてご覧いただけるとより理解が深まるかと思います。
https://blog.willnet.in/entry/2023/08/07/231704
Keynote: 令和の隙間産業——PicoRubyはどこから来て、どこへ行くのか
- 発表者
- Hitoshi HASUMI 氏 (@hasumikin)
- 資料
まつもとさんのスライドスタイルで、角谷さんのようないい話を目指されたとのことでした。 その宣言通り、はすみさんのこれまで歩んできた人生の縮図のようなものが詰まった、素敵なクロージングキーノートでした。
これまでの取り組みやプロダクト（はすみさんが仰るところの隙間産業）を持つに至った経緯、そしてこれまで見てきたことや考えていたことを追体験できる内容だったと思います。 私は個人的には、「ぼくらにはそれぞれ旅に出る理由がある」というスライドの言葉に、深く心を動かされました。
はすみさんが冒頭で「役に立たない話をする」という宣言をされていましたが、このトークは多くの人の心に響く話であったと思います。
公式アフターパーティ
大阪 Ruby 会議 04 の公式アフターパーティは、京橋まで移動し Restaurant & Cafe GARB DRESSING さんで開催しました。 当日になって急遽募集したLT大会も行われ、参加者同士の交流が深まる場となりました。
ご協賛頂いた企業様
株式会社アジャイルウェア 株式会社永和システムマネジメント フリー株式会社 株式会社インゲージ 株式会社ナレッジラボ ポノス株式会社 株式会社 Ruby 開発 株式会社 SmartHR 株式会社アンドパッド BouqueTec 株式会社
著者について
高田 雄大 (@ydah)
大阪市在住、新米 Ruby コミッタ。parse.y に最近住み始めました。
Special Thanx
本記事の執筆にあたり、フォトグラファーとして大阪 Ruby 会議 04 の運営に参加いただいた @hachiblog さんと @shutooike さんに写真を提供いただきました。ありがとうございました。