大阪Ruby会議04 の参加レポート

Posted by Ryo Hayakawa on August 28, 2024 · 2 mins read

NaClの早川です。
2024年8月24日(土)に開催された大阪Ruby会議04に参加しました。
本記事では参加レポートとして、私の感想を交えつつ発表内容の紹介をいたします。

大阪Ruby会議04

大阪Ruby会議04は、大阪の中之島フェスティバルタワーで開催されました。

01_signboard.jpg

スポンサーブースもありました。
02_booth.jpg

Keynote: 最高の構文木の設計 2024年版

Yuichiro Kanekoさんによるキーノートです。
Kanekoさんと言えばパーサーというイメージですが、今回は構文木のお話でした。
構文木の使われ方の変遷から始まり、ユースケース毎の抽象構文木の扱い方の違い、さらに抽象構文木の先にある具象構文木の説明、実装についての解説がされました。
具象構文木という概念をRubyの世界に連れてくるためにはRuby固有の問題(例えばヒアドキュメントの複雑さなど)があり、一筋縄ではいかないようです。
構文木の詳しい解説や最新の事情というのは中々聞く機会のない話なのでとても興味深かったです。

dRuby 入門者による あなたの身近にある dRuby 入門

makicamelさんによるdrubyを用いた身近なプロダクトの紹介です。
『dRubyを用いてプロセス間でメッセージのやりとりができる!すごい!面白い!』という想いのこもったデモに、こちらも『何それすごい!面白い!』とワクワクさせられました。
分散オブジェクトシステム、と聞くと何やら複雑で縁遠いものに感じてしまいますが、ActiveSupportや、るりまといった、まさに日頃お世話になっているものにもdRubyが使われていて、色々な技術の上に成り立っている日々なのだなぁと実感しました。

RubyKaigi公式スケジュールアプリ開発で得た、Hotwireの使い方

kinoppydさんによるHotWireに関する知見のお話。
Hotwireはフロントをサーバーから制御するので通信速度の影響が如実に表れるという問題があり、どのように回避するかという実践的な内容でした。
Hotwireというと比較的新しい技術なので、実際に開発で得られた知見が共有されるのはありがたいという方も多いのではないでしょうか。
特にスケルトンスクリーンを使ってレスポンスを早める手法はチュートリアルレベルでも始められそうな内容なので、私も手元で試してみたいと思いました。
来年のスケジュールアプリ開発を既に見据えているということだったので、松山ではそちらにも注目したいですね。

Re-line 〜 IRB・Reline 複数行編集の裏側

ぺん!さんによるRe-lineのレンダリング改善にいたるまでのお話。
冒頭で紹介されたTypeScriptで書かれた線香花火が衝撃的でしたが、本題はRe-line。
3Dの描画例を交えてRelineで差分レンダリングを実現する手法を丁寧に解説されていて、とてもわかりやすかったです。
まとめにあった「当たり前のことを当たり前にやるとソフトウェアは確実に良くなる」という言葉も実直で素敵だなと思いました。

freeeの川原翔吾さんによるN+1問題の対策に関するお話。
攻め編ではN+1問題を作らせない設計についての解説があり、守り編ではできてしまったN+1を発見する手法を紹介されていました。
攻め編の最後に『「これが正しい」というものはなく要件や周辺環境次第で選択する必要がある』というお話があり、N+1という有名なアンチパターンですら銀の弾丸は存在しないのだなぁと設計の難しさを感じました。

永和システムマネジメントのjunk0612さんによるパーサー3分クッキング!
jsonのBNFさえあればなんと3分でLRパーサーが作れるということで、怒涛の情報量でパーサーの作り方を説明されていました。
次回(?)は構文木の生成についても解説が入るそうで、3分で構文木入門したい人は見逃せない内容になりそうです。

Rustで作るTreeSitterパーサーのRubyバインディング

joker1007さんによる、TreeSitterのRust製Rubyバインディング作成およびRustでRubyGemを開発するお話。
RustでRubyGemを作る場合、Rustの持つ所有権とライフタイムの概念などがRubyの世界にどう影響するかを考慮する必要があるそうです。
特にGC周りは複雑なようで、GCによって何が解放されるかを理解する必要があるというお話をされていました。
メモリ管理はプログラマのたしなみ、なんて言葉も聞いたことがありますが、やはりメモリ周りの話は難しい!
私も一度腰を据えて勉強しなければと思いました。

競技プログラミングでみる Ruby の豊かさ

haruguchi-yumaさんによる、競技プログラミングを通じてRubyのコーディングの柔軟さを見てみましょうというお話。
このお話のためにatcoderで200問解いてきたそうです!
可読性、拡張性、保守性の価値観を捨て、あえて読みにくく複雑で短くしたコードが紹介されるのですが、終始笑いの起こる楽しい発表でした。
一文字単位でコードを短くするといえばコードゴルフの価値観ですが、多彩な書き方のできるRubyにぴったりの遊びかもしれませんね。

Minify Ruby Code

Koichi ITOさんによる、RubyのコードをMinifyするお話。
haruguchiさんに続き、永和システムマネジメント社員によるコードを短くするお話が続きます。
Minifyの可能性を探るところから始まり、実際のGemに落とし込むまでの話かと思いきや、図らずも自身の開発するRuboCopとのマッチポンプが完成したという面白いお話でした。
Minifyはデータ量を削減できるので、いずれ役に立ちそうな期待のできる技術ですね。

急遽スピーカーが変わったということで、okeyseaさんによるナレッジラボの紹介が行われました。

SmartHRのykyuki21さんによる、複雑な属性名を日本語コーディングで解決したお話。
Active_Recordのalias_attributeを使って、属性名を日本語化することができるということで、複雑なドメイン知識を求められる領域ではとても役に立ちそうな手法だと思いました。
コーディングに日本語を持ち込むのはちょっと…という感覚があったのですが、実際のコードの様子はとてもスマートに感じました。

strscanなしで文字列をスキャンする

弊社社長の前田さんによるstrscanを使わずに文字列をスキャンするお話です。
本題の前にSemVerは本当に必要なのか?常に最新のバージョンを使おうよというお話があり、実は今回主張したいことはこちらだったという言葉もありました。
strscanを使わなくてもString#scanString#indexなどで文字列をスキャンできるのですが、最後までまとめてスキャンしてしまう、マルチバイト文字でパフォーマンスの問題が出るといった問題があり、解決策としてString#byteindexが登場します。
しかし、Socketから読んだ文字列はASCII-8BITなので、byteindexでも計算量は同じ、速度も変わらないという悲しい展開に!
最終的にはstrscanを使えばいいというまさかの結論にいたってしまいましたが、何事もやってみなければわからない、ということですね。前田さんお疲れ様でした!

どうしてこうなった?から理解するActive Recordの関連の裏側

willnetさんによる、Active Recordの不思議な挙動を発見しそれを解明していくお話です。
関連先を自動で保存する仕組みとinverse_ofが重なることにより、意図しないタイミングで保存処理が実行されてしまうということでしたが、知らなければ割と起こしてしまいそうな問題に感じました。
双方向関連付けにもメリットがあり、当然使いたいタイミングもあるため、そんな方のためにデバッグ用ツールを公開されたそうです。
関連の保存に関する処理が標準出力に出力されるということで、Rails初学者が仕組みを学ぶのにも便利そうです。

Ruby開発のznzさんによる、deviseで2FA認証するためのGem、devise-two-factorのバージョンアップのお話。
devise-two-factorを4から5へアップデートするにはRailsも6から7に移行する必要があり、実運用だとRailsのダウングレードで起こる問題まで考慮しなければならないということでした。
バージョンアップで動かなくなることがあるのは何故?と思っていたのですが、メソッド名が衝突するというのはなるほど現実に起こり得るんだなぁと感じました。

インゲージの久保 慶輔さんによるPHPとRubyの比較と感想のお話。
久保さんはPHP歴9年でRubyは使い始めて3か月だそうです。
等価比較やfalsyな値、emptyの扱いなど、比較してみると様々な違いがあることがわかりますね。
中でもPHPは”0”(文字列の0)をfalsyにするという話があり、言語による考え方の違いが出ていて面白いなぁと思いました。

Keynote: 令和の隙間産業——PicoRubyはどこから来て、どこへ行くのか

Hitoshi HASUMIさんによるキーノートです。
主題はPicoRubyの歴史とこれからのお話なのですが、その中にも『隙間産業、ちょっとしたプロダクトを持つと面白いよ』というメッセージと、役に立たないコード、役に立たない発表を肯定してくれる価値観があり、なんだか自分でも楽しいことができそうな気になる素敵なお話でした。
『同じ題目でも人によって発表が違い、その人の人生が出る』といった主旨の発言があったのですが、『その話は誰かがどこかで既にしているんじゃないかな』といった尻込みの仕方をする私には、自分らしく発表すればそれでいいのかもしれない、という前向きな気持ちにさせられました。
PicoRubyの今後の展望は、エラーをわかりやすくするといったソフトウェア面での改良から対応マイコンを増やすといったハードウェアの拡充まで、ますます発展が期待される内容となっていました。

まとめ

知らないこと、わからないことの情報量に圧倒されつつ、知りたいこと、やってみたいことをたくさん与えてくれる、素晴らしいカンファレンスでした。
After Partyではたくさんの方とお話させていただき、LTの機会もいただきと大変楽しい時間を過ごしました。

03_team.jpg 運営のみなさん、登壇者のみなさん、そして参加者の皆さん、お疲れさまでした。