freeeの開発情報ポータルサイト

トップ > 技術 > Kaigi on Rails 2023参加しました！

Kaigi on Rails 2023参加しました！

技術 ピックアップ Ruby on Rails

freee のエンジニアで Kaigi on Rails 2023 に参加しました！

こんにちは〜！freee のエンジニアメンバー、anna , fumi , hachi , k-massan , nakayan , otyamura , yongi です。 今回、Kaigi on Rails 2023 に参加してきました！

スクリーン前で撮った記念写真

Kaigi on Rails とは 2023/10/27-28 の2日間で開催された技術カンファレンスです。当初は2020年にオフラインでの開催を予定しておりましたが、コロナ禍によりしばらくオンラインでの開催が続いていました。今回の Kaigi on Rails は念願のオフラインとオンラインでのハイブリット開催！オフラインの会場は浅草橋でした。 これは行かねばならぬ！と、hachi さんは Organizer で、他のメンバーは一般で参加してきました。

こちらのブログでは、参加した感想についてまとめていきます！

目次

会場の様子

企業ブースがたくさん並んでいて、各ブースでは様々なイベントを行っていました。

mybest さんのブースでは同じ豆を3台のコーヒーメーカーで比較し、一番人気のコーヒーメーカーを当てるというクイズを行っていました。めちゃくちゃ難しかったです。freee のメンバーでは yongi さんが見事正解し、mybest のランキングで1位のコーヒー豆を頂きました。

コーヒー格付けブース

コーヒー豆

真ん中には各ブースのステッカーやグッズがたくさん置いてありました！

「Rubyだいすき」と書かれたうちわや各企業さんのステッカーなどが置いてある机

3Fでは猫廼舎さんが珈琲を配っていました。集中力が途切れた頃やお昼ご飯の後にとっても美味しい珈琲が飲めるのはとても嬉しかったです。

コーヒーを淹れている写真

会場内の様子はこんな感じ。2Fと3Fにホールがそれぞれあり、ゆったりセッションを聞くことができました。

スクリーンと椅子がたくさん並んでいる様子

浅草橋のご飯

今回はお昼休憩が1時間半と長かったので会場近辺の浅草橋にて、freee メンバーでお昼ご飯を食べに行きました！

参加者4人でタイ料理を食べてる様子

1日目のお昼はタイ料理のお店へ。ガパオライスやグリーンカレー、カオマンガイなど様々な種類のタイ料理がありとても美味しかったです！

2日目の「32個のPRでリリースした依存度の高いコアなモデルの安全な弄り方」というセッションの途中で #孤独のCTOグルメ というハッシュタグで X に投稿されているという情報を得たので、さっそく紹介されていたお店へ行ってみることに！

牛カツライス

「肉食堂・優」さんへ行ってきました！名物だという、牛カツライスを食べてみました。サクサクの衣で挙げられた牛と目玉焼きが乗っており、溢れ出す肉汁が何ともギルティな一品でとても美味しかったです！

その後コーヒーを飲みたいという話になり、時間もあったので浅草を徘徊。

オシャレな建物の前での記念写真

Google Mapでなんかオシャレそうだ..という理由で abno さんへ行きましたが、なんとホテルの2Fにあるお店。ホテルの入り口がめちゃくちゃオシャレで一人だったら絶対入れませんでした。エアロプレスのコーヒーや紅茶など各々好きな飲み物をテイクアウトしました。

チョコモンキーを飲んでる様子

興味本位で頼んだチョコモンキーという飲み物。チョコとバナナっぽい香りがするからチョコモンキーらしい。バナナの香りが強いから実質モンキーでした。

オフィシャルイベント

1日目は Startup Drinkup at Kaigi on Rails 2023 へ！

Startup Drinkup at Kaigi on Rails 2023の様子

他社さんやスピーカーの方々、X 上では繋がっているけど初めて会う方など....いろんな方と交流できてとても楽しい会でした！ドリンクがとても美味しかったです！

2日目は会場で行われた懇親会。

ケータリングが置いてある懇親会の様子

5つ並んだ日本酒

食事も飲み物もたくさんあって豪華でした！1日目のドリンクアップでは話せなかった方とも交流できて楽しかったです。

その後は RubyMusicMixin on Rails 2023 へ！

RubyMusicMixin on Rails 2023の様子

音楽とお酒と技術に酔いしれる楽しい時間でした！

セッションの話

ここからはセッションについての感想です！

TracePointを活用してモデル名変更の負債解消をした話

このセッションではモデル名を変更した際に、該当箇所を機械的に洗い出し、修正の手間を減らしたというお話をされていました！ モデル名を変更するとモデル名が参照されている箇所はもちろん、create_userなど動的に生えるメソッドなども変更しなければなりません。そこでTracePointという標準ライブラリを用いて、参照されている箇所を機械的に特定し、60,000行以上の修正を行ったそうです。

まず、TracePoint自体はイベントに合わせてフックすることができるようになるものであり、例えば:callはメソッドの呼び出しにフックすることができ、

trace_point = TracePoint.new(:call) do |tp|
  pp([tp.event, tp.method_id, tp.path, tp.defined_class])
end

def hello
  "hello"
end

def say_hello
  hello
end

trace_point.enable
say_hello

をすると↓のように返ってきます

[:call, :say_hello, "trace.rb", Object]
[:call, :hello, "trace.rb", Object]

これを活用して、Thread::Backtrace::Locationでファイルや行数情報をさらに取得し、RubyVM::AbstractSyntaxTreeでASTから詳細なコードの位置(node_id)を特定する、という流れで変更箇所を特定していました。 中でも、TracePointを愚直に使うと必要なメソッドコール以外でも発火してしまうということがあったため、必要なメソッド以外であった場合は早期リターンをする最適化も行われていました。（User.find(1).loadをするだけで約5000回も発火してしまうらしい！）

このセッションを聴講して、Railsならではの動的にメソッドが生えてしまうことによるrenameの負債解消を、TracePointやASTなどを用いた解決方法について知ることができました。特に、TracePointを使うだけではなく、そこからさらに他の技術を複数用いて技術的負債に立ち向かう姿は、1エンジニアとして見習いたいととても感じました。自分自身も巨大な技術的負債の解消に立ち向かった時はこのように標準ライブラリでも組み合わせると強力になるということを思い出し、頑張りたいと思います！

by otyamura

Hotwire的な設計を追求して「Web紙芝居」に行き着いた話

どんなお話？

RailsのHotwireを用いてUIを組み立てるときに、コンポーネント指向的なアプローチでコードを書くと、クライアントサイドのjavascriptで頑張ることが増えて辛くなりがちです。これに対して、話者が「Web紙芝居」と呼ぶアプローチでコードを書くと、SPA的な体験を保ちつつ「なんでもサーバサイドでできる！！」状態が実現し、Railsの良さを最大限に享受できる、というのが今回のお話でした。

何が良かった？

何よりも印象に残ったのは、話者のRailsとHotwireに対する圧倒的な熱量です。特に「なんでもサーバサイドでできる！！」のときの勢いは思わず笑ってしまうほどでした。

また、普段の開発では専らReactを用いるため、コンポーネント指向で考えることがほとんどでした。しかし、今回の発表を聞いて、コンポーネント指向的なアプローチをより相対化して捉えられるようになり、クライアントサイドで頑張る立場とサーバサイドで頑張る立場の双方のメリット・デメリットを考え直すいいきっかけとなりました。

by fumi

Update Billion Records

この講演は、数十億レコードの更新をどのように行ったかという内容でした。レコード更新作業を自分は行ったことがなかったので、それほどの数をどうやって更新していくのか興味を持ちこの講演を聞きました。 rails runner + parallel + activerecord-import による bulkupdate を並列実行する方法では、70分/1000万件 ペースでしか更新作業が行えず、また以下のような課題があったそうです。

  • rails runner の実行環境に依存してしまいリリースのたびに作業を中断
  • モニタリングのしづらさ

そこで行った解決案が Sidekiq Worker で非同期ジョブにするとのことでした。確かにSidekiq を使えば、rails runner の実行環境には依存しませんし、さらに sidekiq の管理画面や APM を見ることで実行状況の詳細なモニタリングが容易ですね。さらに、DB 負荷を高めないように Job の数を一定数にコントロールする工夫まで行ったそうです。簡単に説明すると、Redis に更新する対象を登録 => rails からある一定数の Job を登録 => Job は対象をRedis から pop して更新作業を行う => 自らが新たな Job を登録し、消滅する。Job が Job を作り出すことで、数を自動的にコントロールしているところが個人的にとても興味深かったところでした。さらに、Redis から対象データを消すことで、何か問題があった場合に一括終了できるようにもなっており、知見の詰まったお話でした。結果的に 40分 / 1000万件 ペースでおよそ 3ヶ月で更新作業が完了したそうです。大規模なレコード更新作業を力技ではなく、工夫で乗り切ったという貴重な講演を聞くことができ、とても身になりました。

by nakayan

Exceptional Rails

この発表は、Rails　アプリにおける例外の扱い方についての発表でした。タイトルの “Exceptional Rails” は書籍 “Exceptional Ruby” から着想を得たそうです。Exceptional という形容詞には「卓越した」と「例外的な」という2つの意味があり、“Exceptional Rails” というタイトルには例外処理を適切に行うことで卓越した Rails アプリを開発しようというメッセージが込められているとのことです。

一般に、例外とは通例の原則に当てはまっていないことを指しますが、Ruby の文脈では例外インスタンスを raise することを指します。発表では、例外の扱いについて4つの観点が挙げられています。

  • 例外を発生させる条件
  • 例外を rescue する方法
  • 例外の発生を開発者に知らせる方法
  • 例外の発生をユーザーに知らせる方法

自分にとって特に新鮮だった点は、例外には処理の遅さやフローの分かりにくさといった問題があるため、例外の発生は最小限にすべきという考え方です。単なる分岐や不正な入力など正常系・準正常系ではなく、あり得ない分岐やユーザー入力に依存しないエラー、DB接続の失敗など、異常系においてのみ例外を発生させるべきだということです。ただし、コントローラ層で ActiveRecord::RecordNotFound を rescue し 404 レスポンスを返すことでコードが簡潔になるなど、メリットがデメリットを上回る場合も考えられます。

他にも、スコープを必要最小限に絞り早い段階で例外を補足することや、エラートラッキングサービスを利用すること、ユーザーに見せるべきエラーを精査することで、例外処理を改善することができます。

このように、例外のメリット・デメリットを理解し、適切に発生させ処理することで、開発者とユーザーの双方にとってより質の高い Exceptional な Rails アプリを作ることができると思います。発表では、先に述べた4つの観点について、具体例をふんだんに用いて網羅的かつ詳細に解説されています。非常に学びのある資料になっていますので、スライドと合わせてご覧になってください。

by yongi

最後に

いろんな方と交流ができ、これからの開発へのモチベーションも高める事ができてとても刺激的な2日間でした！Kaigi on Rails は業務に寄ったセッションも多いのでとても親しみやすく、参考にしたい内容が多かったです。

運営のみなさま、本当にお疲れ様でした！