ながらRuby 会議01に行ってきました！ – Timee Product Team Blog

こんにちは！
タイミーでBackendEngineerをしている志賀(@akitoshiga)です！

2025年9月6（土）に開催された「ながらRuby会議01」に行ってきましたので、その様子を振り返りたいと思います！
ながらRuby会議には、「Kaigi Pass」という社内制度を利用して参加しました。

「Kaigi Pass」とは、世界中で開催されているすべての技術カンファレンスに無制限で参加できる制度です。

productpr.timee.co.jp

当日は長良川沿いにある「長良うかいミュージアム」というとても素敵な場所で開催されました。

会場内にはスポンサーノベルティや展示などもありました。




refinementsのメソッド定義を4000倍速くした話

alpaca-tcさん

Ruby3.2以降、refinementsにおけるメソッド定義は約1万倍低速化していました。
社内サービスの開発でこの事態に直面した際に、原因の究明からRubyへのコントリビュートまでを行った過程をお話しされていました。
refinementsとはRuby2.0から導入された安全にRubyを拡張する仕組みのことで、モンキーパッチを当てたクラスのスコープを限定させることが可能です。
きっかけは、社内サービスのRubyのアップデートの際にRuby on Railsのアプリケーションの起動に数十秒かかるようになってしまったことでした。　　
VernierとMiddlewareを利用して計測を行ったところ、ボトルネックとなっている処理が判明しました。
そこにrefinementsのメソッドModule#refineが存在していました。
Ruby3.3では、Module#refineを呼び出した際にrefineのcallcacheがクリアされる処理が追加されます。
このcallcacheが削除されたことが低速化の原因でした。
これをRuby Issue Tracking Systemで報告したところアドバイスをもらいました。
しかし、alpaca-tcさんはRubyの実装であるC言語には馴染みがありませんでした。
この問題に対してはChat-GPTやko1/rubyhackchallengeを活用したりコミュニティでアドバイスを得ることで解決していきました。
最終的にプルリクエストを作成してRuby本体へのマージが実現したそうです。
技術的なギャップを埋めるためにAIを活用したのは素晴らしい解決方法ですし、粘り強く取り組みRubyへのコントリビュートを実現する姿は素晴らしいと思いました！
 

知っているようで知らないrails newの世界

luccafortさん

speakerdeck.com
 
Ruby on Railsではプロジェクトの初期化の際にrails newというコマンドを実行します。
しかし、このコマンドの裏側でどのような処理が行われているかは多くは知られていません。
そこで、コマンドはどのような実行フローを行っているか、また使われている技術がどのような設計の組み合わせによって実現しているかについて深掘りしてお話しされていました。
luccafortさんの今回の発表の動機の一つには、オーガナイザーを務められた「関西Ruby会議08」での体験から、個人開発以外の成長の選択肢を模索したかったという想いがあったそうです。

rails newで実行される処理は以下の流れになっています。

1. コマンド解析
2. ジェネレータ初期化
3. オプション処理
4. ディレクトリ作成
5. ファイル生成
6. bundle install

これだけでも長大な処理なので、本発表ではコマンドの解析からジェネレータの初期化まで中心に説明していました。

rails newを実行するとRails::Commandによってargの解析やエラーチェックが行われます。
その後、Rails::Command.invokeによって入力したコマンドの内容からRails::Commandの適切なサブクラスが呼び出されます。
今回の場合はRails::Command::ApplicationCommandが読み込まれます。
Rails::Command::ApplicationCommand#performによって無効なコマンドチェックなどが行われた後、Rails::Generators::AppGenerator.startで定義された各種ファイルの生成タスクが実行されます。
その後、Rails::Generators::AppGenerator#bundle_commandによってbundle installが実行され最終的にコールバックが呼び出されます。
rails newに関する説明は以上です。
この取り組みを通してluccafortさんは仕組みを理解する重要性について気づきがあったそうです。
仕組みを理解していなくてもRuby on Railsは使えるものの、深く理解することで新しい発想や新たな気づきのきっかけになるとお話しされていました。

Ruby × iOSアプリ開発：共に歩んだエコシステムの物語

Tomoki Kobayashiさん

speakerdeck.com

Kobayashiさんは普段は主にモバイルエンジニアとして活動されています。
RubyはiOS開発の歴史において過去大きな役割を担っており、またiOS開発コミュニティもRubyに大きく貢献しています。
iOS開発とRubyが今までどう関わってきたかの歴史をお話しされていました。
2010年ごろのiOSアプリ開発はObjective-Cが使用されていましたが、サードパーティのライブラリのインストールが大変だったそうです。
ライブラリによってインストールの仕方が異なっており、Xcodeのビルド設定を行う際にもAppleの非公開の独自仕様のために保守性が非常に低いものでした。
この問題を解決するためにCocoaPodsというパッケージマネージャーが登場しました。
これによりライブラリの依存性解決・ダウンロード・Xcodeへのプロジェクト統合まで自動できるようになりました。
CocoaPodsはRubyでライブラリ管理に使用されるRubyGemsとBundlerを参考に作成されており、本体の実装もRubyで書かれています。
その他もnomad-cliやfastlaneといったRubyを参考にしたツールが登場してきました。
この背景はツールの作成者が元々RubyやRuby on Railsのエンジニアが多かったことにあるそうです。
そして、CocoaPodsの依存関係リゾルバーであるMolinillo（モリニージョ）はBundler1.9, RubyGems2.9に搭載されるようになりました。
しかしながら、iOS開発とRubyの関わりは薄れつつあるそうです。
2014年のSwiftの登場を機にSwiftが公式のパッケージマネージャーを発表したりBundler2.4でMolinilloが引退しています。

Ruby Mini Language作成記 〜ハンズオンで学ぶインタプリタの世界〜

haruguchiさん
Rubyを用いてインタプリタを作成した経験をもとに、字句解析、構文解析、評価とった処理の実装方法や設計上の注意点についてお話しされていました。
インタプリタを作ろうと思ったのはharuguchiさんがRubyKaigi2025に参加したことがきっかけだそうで、RubyKaigiでよく発表される言語処理の話の理解を深めたいと思った時にインタプリタの実装を思いついたそうです。
haruguchiさんが参加されている勉強会でこの話を持ち込み、他のメンバーと実装していくことになりました。
インタプリタはFizzBuzzが動くものをゴールとして、単純な2項演算の実装からはじめることにしました。
最初は単純なパーサーのみで実装することとし、インタプリタの機能を追加していくにつれてレキサーを実装したり構文解析方法を工夫したりと実装を進めていきました。
自身で実装することを面白くするポイントとしてif文の条件式の区切りを< >にしたりとオリジナルの要素を追加していったそうです。
5ヶ月ほどでFizz Buzzの実装まで完了して、途中デモで実践していました。

会場のみんなでモブプロしてるの良すぎる#nagara01 pic.twitter.com/PX9v0mA3k2

— しが あきとし (@akitoshiga) 2025年9月6日

当初のゴールとしては達成したのですが、ここから配列やハッシュといったデータ構造も行ってみたいとのことでした。
言語処理の話題はRubyではよく出てくるのですが、その理解のためにインタプリタを自前で実践するところに尊敬しました。また、自分も挑戦してみたいと思いました。

💡Ruby（ひかるびー） 川辺で灯すPicoRubyからの光

bashさん

speakerdeck.com

PicoRubyという組み込み向けの軽量なRubyを使ってLEDを点灯させるところから、音声や加速度といったセンサーを追加して様々なことに挑戦することでRubyで組み込み開発をする楽しさについてお話しされていました。
最初の機材は「ATOM Matrix」という開発ボードで、内蔵のLEDを点灯させるところから始まりました。
また、基本的なアーキテクチャは「Super Loop Architecture」というものを用いていました。
Super Loop Architectureとは、初期化の後に発生させた無限ループの中でLEDに対しての操作を行うものです。
LEDの点灯に成功させたあとは、ランダムに点灯させたり自分の動きに合わせて点灯させたりといった試みを行っていきました。
最終的には棒状のLEDやMIDIシンセサイザーといった他の機材と連携させる試みを行っていました。

ライトセイバーを振り回すbashさん #nagara01 pic.twitter.com/SSv6g6SMAE

— すぎうり (@uproad3) 2025年9月6日

365日のOSS開発を続ける舞台裏

Koichi ITO(Koic)さん

speakerdeck.com
 
RuboCopのコミッターであり、365日OSSにコントリビュートを行っているITOさんの普段の開発環境やOSSに対する心構えについてお話しされていました。
開発環境は業務のコードとOSSのコードを透過的に扱えるようにすることをテーマとしていました。
そのためのツールとしてghqやgem-srcの使用を推奨されていました。
OSS活動をするとローカルリポジトリが大量に増えるのですが、その点についてはpecoやfzfを用いた対策を紹介されていました。
印象的だったのは、gitコマンドの扱い方でコミット権のないリポジトリとリポジトリでの振る舞いを合わせるためにFork先のリポジトリをoriginとして、upstreamをForkした方のリポジトリとすることを推奨されていた点です。
これによってどの環境にプッシュする際もgit push upstream headと同一のコマンドにできる利点について強調されていました。
心構えについては、コードの内容だけではなく発言やレビューについても恥ずかしくない振る舞いをしようという「ソーシャルコーディング」という考え方や、OSSを地球全体での非同期開発と捉えて自己完結したコードのみのPRを出さずにコンテキストを文章化して伝えることの重要性にも触れられていました。 　

懇親会の後にはアフターイベントとして鵜飼漁の観覧がありました！

鵜呑みです。#nagara01 pic.twitter.com/EPTU5bsiJ3

— どみにをん525 (@Dominion525) 2025年9月6日

残念ながら自分は参加できなかったのですが、大変盛り上がったみたいです。

スポンサーLTも含めてどのセッションも大変面白かったです。
発表者の「これがやりたいからやる！」といった気持ちに基づいた発表が多かったのですが、その姿勢をとても尊敬しました。
また小規模の開催だったこともあり、アットホームで参加者間でのコミュニケーションもとりやすくたくさんの方と交流できました。
また、自身は今回初めて岐阜に行ったのですが、自然と人々の生活が調和したとても素晴らしい場所でした。
大変心に残る素晴らしい会だったので、次回開催される際はまたぜひ伺いたいなと思いました！