• Home
• コーポレートブログ
• RubyKaigi 2024で印象に残ったセッションとRubyistと一緒に過ごした楽しい時間

今回のブログ担当は石川です。2024/5/15〜5/17に沖縄で開催されたプログラミング言語Rubyの国際会議RubyKaigi 2024に参加したので、その様子や感想を書いていきます。

RubyKaigi 2024

RubyKaigi 2024のセッションの中で印象に残ったことについて書きます。

Writing Weird Code

資料: https://drive.google.com/file/d/1Dkx15u_5UAGoFqJHCeAuj2FXS-z_U7EE/view

Weird Code（奇妙なコード）をテーマとしたセッションでした。

文字や記号で動く魚を描いたアニメーションに見えますが、このコードをRubyとして実行すると実行した時点の魚の位置から再び泳ぎ出すというコードになっているそうです。irbにコピペして実行してみたところ本当に動いて、「特別なライブラリもなく本当に動くんだ･･･」と驚きました。

先月、TRICK2022(超絶技巧Ruby意味不明コンテスト for RubyKaigi)で金賞をとってきたプログラム(Quine)です。
全てのフレームが、魚達がその場所から泳ぎを再開する実行可能なRubyのコードになっています。
魚・水草・泡でコードの一部が欠落していますが、誤り訂正により復元しています。 pic.twitter.com/vQsGG5o7Of

— ぺん！ (@tompng) October 18, 2022

(セッション内で紹介された、TRICK 2022で金賞を受賞されたプログラム)

他にもRubyKaigi2024に関連付いた作品と、その作品を構成する技術的手法も紹介されました。今回発表されたような奇妙なコードを書くためには、Rubyの言語仕様を深く理解している必要があるとのことです。

@🌺のように絵文字を使ったインスタンス変数は使えるが@2️⃣のように数字の絵文字のインスタンス変数は使えないという話がありましたが、

• 2️⃣のような絵文字が結合文字として扱われていること "2️⃣".chars == ["2", "\u{fe0f}", "\u{20e3}"]
• Rubyでは数字から始まる変数名はエラーになり使用できないこと
• 数字から始まる変数名はエラーになり使用できない部分の判定がどのようになっているか

などを理解していればこのようなインスタンス変数を書いたときどうなるかが自ずと理解できるのかな思います。私は絵文字のインスタンス変数を作ってみようなんて今まで考えたこともありませんでしたが、Rubyについてより深く知るためにももっと好奇心を持っていろんなことを試してみたいと思いました。

こういう「Rubyをつかって面白いことをしている」セッションが一番最初のキーノートだったことでRubyKaigi全体のわくわく感みたいなものが上がったのを感じましたし、Ractorやwasmなど他のセッションに繋がるような内容となっていて本当にすごいキーノートでした。紹介された作品ももちろん素晴らしかったのですが、それだけでなく構成含めて美しいというか。

私はAtCoder（競技プログラミングコンテストサイト）のコンテストにRubyで参加しているのですが、AtCoderの提出結果をコード長の昇順で並び替えてみると「なんでこれで動くの？」「読めない･･･」というコードを見かけることがあります。そういうコードの一端を垣間見た気もしました。

Unlocking Potential of Property Based Testing with Ractor

資料: https://speakerdeck.com/ohbarye/unlocking-potential-of-property-based-testing-with-ractor

Property based testingという手法のテストをRactorで並列化して素早く動く形で実現されたというセッションでした。まずProperty based testingという手法をはじめて知ったのですが、

• 何らかの基準で入力値を選んで、その入力値でコードを動かして期待した結果が返ることを確認するテスト（一般的な書き方）: Example based testing
• 特定の例に頼らず、多くの入力値ごとにケースを自動的に生成して行うテスト: Property based testing

というように普段行っているテストとは異なる手法のようです。

Property based testingを使うメリットとしては、手動テストでは見逃されるようなエッジケースを見つけやすいという網羅性が一番大きいようで、網羅性が高い分Example based testingよりも処理時間がかかるのですが今回紹介されたpbt gemではそこでRactorを使った並列処理を活用されていました。

ただ、その多くの入力値に対するテストを行って期待する値が返ってくるかの判断は相対的なコードとして書く必要がありそうなので、そのコードが正しくない場合もあるというところがちょっと怖いところかなと思いました。Example based testingで問題が起きそうなサンプルを抽出して期待値をべた書きしたテストを書き、それに加えてProperty based testingで多くの入力値を網羅するテストを書くと良さそうです。もちろんすべてに対してここまでテストを書くことは難しいですが、とくに重要な部分に対してはProperty based testingを取り入れていくというやり方であればありだと思います。

Ractorという並列化に使える新しい仕組みができたらしいぞということは知っていたのですが、並列処理したい場面も少なく、したいときもGitHub ActionsでjobごとわけるとかLambda関数を複数動かすとかそういう方向性だったので、今回のRubyKaigiでほぼはじめてRactorについて知ることができました。

導入も結構簡単そうなので、今後 https://github.com/ohbarye/pbt をどこかで使ってみたいです。

Long journey of Ruby standard library

資料: https://speakerdeck.com/andpad/long-journey-of-ruby-standard-library-rubykaigi-2024

Rubyの標準ライブラリについてのセッションでした。

なんとなく感じ取ってはいましたが、default gemsを減らしてbundled gemsを減らしていく方向性のようです。

default gemsを減らしてbundled gemsを減らす理由:

• サプライチェーンアタックのリスクを減らすため
• 可能な限りソフトウェアの粒度を小さくして、アップデートをしやすくするため
  • bundled gemsの仕組みを利用することで、gemに問題が見つかったときにRubyのバージョンを上げなくても問題修正後のgemを利用することが可能
  • Ruby全体ではなく、ライブラリ単位でコミッターを追加できる

Ruby3.3で導入された機能で、default gemsからbundled gemsに移行するライブラリを利用している際に警告を出すようになるそうです。今後のバージョンアップのことを考えると事前に警告を出して貰えるのはとてもありがたいです。

こんな感じに警告されるらしい:

>> require "csv'
warning: csv which will no longer be part of the default gems since Ruby 3.4.0. Add csv to your Gemfile or gemspec

Using "modern" Ruby to build a better, faster Homebrew

資料: https://speakerdeck.com/mikemcquaid/using-modern-ruby-to-build-a-better-faster-homebrew

Homebrewの開発者の方によるHomebrewの開発についてのセッションでした。HomebrewがRubyで動いていることは知っていましたが、macOSにRubyが標準で入らなくなったあたりから変わったのかと思っていました。今もRubyなんですね。

https://github.com/Homebrew/homebrew-core/blob/f1e6445bf32504e0e3a50169a2ee7f8e7ccba76a/Formula/w/wget.rb はWgetのインストールに必要な情報が記載されているファイルのようですが、DSLがとても洗練されていて読みやすいです。test do ... endブロック内に書かれているコマンドによって、パッケージのインストールが成功しているかどうかをテストしているようです。wgetの場合は system bin/"wget", "-O", "/dev/null", "https://google.com"。いつか継承元のFormulaのコードを読んでみたいです。

Namespace, What and Why

資料: https://speakerdeck.com/tagomoris/namespace-what-and-why

Namespaceという開発中の機能がテーマのセッションでした。Namespaceとは、中で行われた変更を空間の中に隠すことができ、その空間の中で定義されたものを外から呼び出せるという機能を持っている必要があり、それらを実現することで「名前の衝突」「定義の衝突」「バージョンの衝突」を解決することができるとのことです。

とくに、「Appが使っているライブラリXはライブラリYのバージョン1を使っていて、同じAppの中でライブラリYのバージョン2を使えない」というありがちな辛い状態が、Namespaceとbundlerがうまく連携できれば解決できるかも、ということがとても魅力的でした。今後の展開が楽しみです。

（感想）Rubyの未来を感じた

今回のRubyKaigiでは、Namespace, What and WhyでのNamespacesについての提案や、Ruby Committers and the WorldでのRBSを別ファイルに書くのは嫌なのでコメントにするのはどう？という提案など、今後のRubyへの期待が高まるお話をいくつか聞けました。まつもとさんのキーノートセッションでもRuby4.0について触れる場面があり、今後のRubyが楽しみになりました。

RubyKaigi全体を通してRubyコミッターやRubyを使って開発をしているプログラマーの皆さんの熱意を感じ取ることが出来たのもよかったです。

RubyKaigiの周囲

エモリハウス ＆ ヤダハウス

エモリハウスは

女性がRubyKaigiに参加しやすくなるといいなあ、 そんな家主の思いからはじまったエモリハウス。 女性のRubyKaigi参加者たちといっしょに泊まって、わいわいしよう！という企画です。

といったゲストハウスを貸し切って共同生活をするという企画で、私は今回はじめて参加させていただきました。 https://emori.house/

私は2017年のRubyKaigiにも参加したことがあるのですが（RubyKaigi 2017に参加しました）、このときは知り合いも、知らない人に話しかける度胸も無かったので、懇親会にも参加せず誰とも話さずセッションだけ見て帰るという参加の仕方をしていました。（もちろんそれも参加の仕方のひとつではありますが、当時の私はとても寂しい気持ちになった）

今回はエモリハウスとヤダハウスの方と事前にオンラインで顔合わせができていたこともあって割とすぐに仲良くなれて、エモリハウス内の部屋飲みでいろんな話をしたり、モーニングやランチを一緒に食べにいったり、観光に行ったりととても楽しい時間を過ごすことができました。エモリハウスと言えばお酒のイメージが強いようですが、ほとんどお酒を飲まない私でも楽しめる場所でした。また、懇親会やセッションの合間でも知り合いがいるということがとても心強く、沖縄にいた間が本当に充実した時間になりました。

あと、エモリハウスの近くの公園に野良猫がたくさんいて、日々の癒やしでした。

TokyoDev x RailsGirls x WNB.rb: Women and Non-binary Dinner&DrinkUp!

https://tokyodev.doorkeeper.jp/events/172303

Day0（RubyKaigiの前日）は女性とノンバイナリーのRubyistのための食事会に参加しました。RubyKaigiという大きなイベントに参加する前に知り合いができるのはとても心強かったです。

RubyKaigi 2024 Official Party

https://ti.to/rubykaigi/2024-party

Day1はOfficial Partyに参加しました。海の見える広い会場でのバーベキューで、RubyKaigiの規模の大きさを改めて感じました。

RubyKaigiの参加者は日本国内だけでなく海外からもたくさんいらっしゃっていて、英語話者の方に対しては（肉や野菜を焼きながら）「What would you like to eat?」と聞くくらいしか出来なかったので、もっと英語を話せるようになりたいと思いました。とくに考えたことを英語で口に出すことが難しいので、英語で話す練習をしていきたいです。

フィヨルドブートキャンプで勉強中という方とも何人かいらっしゃっていて、皆さんのモチベーションの高さに刺激を受けて私も頑張ろうと思えました。

コード懇親会/Code Party RubyKaigi 2024 Day 2

https://andpad.connpass.com/event/315564/

Day2は参加者が一緒にコードを書きながら懇親会をするコード懇親会に参加しました。rspec-openapiというgemの出力を一部改善したいという課題に取り組むチームになり、その場にいた8人でモブプロをしました。

まずテストのexpectedを書き換えてからコードを書き換えるTDDのような形で開発を進めていたのですが、rspec-openapiのテストコードの特殊な構造に苦戦します。特殊な構造（恐らくテストコードの内部で別のプロセスを起動していた）によってbinding.irbやputsメソッドで中身をのぞくことができず、どこを書き換えれば良いかがわからない状態になっていました。苦しい場面もありましたが、最終的にはその場にいた8人のプログラマーの集合知でテストの構造を把握してどこを書き換えれば良いかを見つけることができました。

全員がはじめてお会いした人たちで最初は会話もぎこちない雰囲気だったのですが、コードを書き始めるとスムーズにやり取りが進み、「これがコード懇親会の力か！」となりました。モブプロによって他の熟練のプログラマーがどのようにコードを書いているか、どういう思考回路で怪しい箇所を見つけ出しているのかをみ見て学ぶことができ、とても有意義な時間を過ごすことができました。わたしもデバッグのやり方について提案をしたり、怪しい箇所を見つけたり、dateとdataのtypoを見つけたりとモブプロに積極的に参加できたので良かったです。

RubyKaigi 2024 After Party sponsored by mov

https://connpass.com/event/313947/

Day3は国際のれん街の貸し切りという大きな規模で行われたAfter Partyに参加しました。沖縄のお酒や料理を楽しむことができ、RubyKaigiの開催期間中に知り合った人たちと最後にしっかり話せて良かったです。

そのほかに感じたこと

• RubyKaigiは名刺交換よりもXのフォローをしあうことが多く、RubyWorld Conferenceとも結構雰囲気が違うなと感じました。
• 「名札にアイコン画像を入れておくとか缶バッチとか何かしらアイコンがわかるものをぶら下げておくと顔とアカウントが一致しやすくて良いよ」というアドバイスを元に缶バッチを作っていったところ、「あ！石川さんだ！」と声を掛けていただいたりしました。缶バッチを作っていって良かったです！

• 沖縄のご飯美味しかった。もずくの天ぷらと海ぶどうがとくに美味しかったです。暑かったのもあってブルーシールのアイスは4回くらい食べてました。

このように、RubyKaigi 2024ではとても楽しい時間を過ごすことができました。楽しかっただけで終わらすのでは無く、今回受けた刺激を今後の仕事や学習のモチベーションにして頑張っていきたいです。Rubyコミュニティのみなさん、ありがとうございました！

【スタッフ募集中】
弊社ではAWSを活用したソリューションの企画・設計・構築・運用や、Ruby on Rails・JavaScriptフレームワークなどを使用したアプリケーション開発を行うスタッフを募集しています。採用情報の詳細
弊社での勤務に関心をお持ちの方は、知り合いの弊社社員・関係者を通じてご連絡ください。

---