ShopifyはなぜFalcon移行に苦戦したのか？FiberとC拡張ブロッキング #rubykaigi2026｜kiha
ShopifyはなぜFalcon移行に苦戦したのか？FiberとC拡張ブロッキング #rubykaigi2026 RubyKaigi 2026の「Surviving Black Friday: 329 billion requests with Falcon!」がFalcon gemの生みの親とそのチームが語るShopifyのunicornからFalconへの全面移行の戦いの記録で面白かったので深掘りしたい。本記事では、その発表で語られた事実を整理した上で、Falcon移行の本質である「Fiber Schedulerのフック対象外となるC拡張ブロッキング」を最小再現コードを交えて確認する。 ShopifyはFalcon（Webアプリケーションサーバのgem）を本番導入し、CPUコアあたりおよそ7%の効率改善を狙った。Shopifyのブラックフライデーは、ピーク時に毎秒142万リクエストに達
遠かった Rails が "自分事" になった瞬間 〜 transaction 内で job を安全に呼べるようになるまで - giftee Tech Blog
こんにちは、ギフティでエンジニアをしている mugi です。 先日、Ruby on Rails に初めて PR を出し、マージされました。 github.com この記事では、PR を出すきっかけからマージされるまでの流れ、そしてこの経験を通じて感じた「OSS が "自分事" になる感覚」についてお話しします。 きっかけ：Kaigi on Rails 2025 のトーク きっかけは、Kaigi on Rails 2025 で聞いた「非同期 job を transaction 内で呼ぶなよ！絶対に呼ぶなよ！」でした。 kaigionrails.org このトークでは、Active Record の transaction 内で perform_later を呼び出すと、transaction がコミットされる前に job が実行されてしまう問題が紹介されていました。 ActiveRecord
SmartHR最大のRailsアプリケーションにおけるPumaスレッド数を見直しました - SmartHR Tech Blog
こんにちは、SmartHR プロダクトエンジニアのB6です。 「基本機能」と呼ばれるSmartHR最大のRailsアプリケーションでは、アプリケーションサーバにPumaを使用しています。 RailsでPumaデフォルトスレッド数が変更されたのをきっかけに、私たちもスレッド数の設定を見直してみたいと思うようになりました。 本記事では、調整の際に行ったこととその結果について共有いたします。 背景 2024年、RailsでPumaのデフォルトスレッド数を減らすための議論が展開されました（Issue #50450）。議論の結果、I/O比率を25~50%とする一般的なRailsアプリケーションでは、スレッド数3が適切ではないかという結論に至りました。 要点をざっくりまとめると以下のようになります。 CRubyでは、GVLが存在するため、同時に1つのスレッドしかRubyコードを実行できない Pumaの
Rails8.0にアップグレードしたらinsert_allの振る舞いが変わった - メドピア開発者ブログ
こんにちは。メドピアのお手伝いをしている@willnetです。最近寒くなってきましたね。毎年この時期に風邪をひくので最近は手洗いうがいを怠らないようにしています。このたび久しぶりにテックブログに寄稿します。 insert_allの仕様変更に関するPR メドピア内のとあるRailsアプリケーションのバージョンを7.2から8.0にアップグレードしたときにinsert_allの仕様変更に気づいた話をします。 insert_allの仕様変更に該当するのは次のPRです。 Fix active record insert values of type cast and serialize by OuYangJinTing · Pull Request #48139 · rails/rails 上記PRではsaveメソッドとinsert_all(及びinsert、insert_all!)メソッドで値の変
Kaigi on Rails 2025 Webアプリケーションにおける非同期ジョブの設計原則を振り返りつつ実践してみた - Techouse Developers Blog
Kaigi on Rails 2025 に参加しました こんにちは、Techouseでエンジニアインターンをしているez0momongaと申します。 9/25、26の2日に渡って開催された、Ruby on Rails についてのカンファレンスKaigi on Rails 2025に参加して参りました。 Techouseでも各プロダクトにおいてRuby on Railsを用いたWebアプリケーションを開発しています。普段からRailsに触れる機会が多いため、今回のカンファレンスは非常に楽しみにしておりました。 普段の課題で感じる身近な課題についてのセッションや、最新の技術動向を知ることができるセッションなど、非常に多くの学びを得ることができ、大変有意義な時間を過ごせました。 本記事では、私が参加したセッションの中から、特に印象に残った@morihirokさんによるセッション「Sidekiq
Rails 8.1でのRuboCop関連のアップデート - koicの日記
Rails 8.1.0がリリースされました。ハイライトはリリース記事を読むと良いです。 rubyonrails.org ここで取り上げるのは、Rails 8.1.0 で更新された GitHub Actions 向けに生成される RuboCop 実行ワークフローのテンプレートについての小ネタです。 github.com 以下の設定は、この PR で更新された bin/rails new におけるテンプレートを元にした差分のサンプルです。ファイルとしては .github/workflows/ci.yml に相当します。 lint: runs-on: ubuntu-latest + env: + RUBY_VERSION: <%= ENV["RBENV_VERSION"] || ENV["rvm_ruby_string"] || "#{RUBY_ENGINE}-#{RUBY_ENGINE_VER
Rails 8.1リリース！ジョブ継続機能や構造化イベントなど、注目の新機能を紹介
10月23日、「Rails 8.1がリリースされた)」。 この記事では、Rails 8.1における主要な新機能であるジョブ継続機能（Job Continuations）、構造化イベント（Structured Events）、ローカルCI（Local CI）など、開発体験を大幅に向上させるアップデートについて詳しく紹介する。 概要 Rails 8.1は、前回のメジャーリリース以降、500人以上のコントリビューターによる2,500件超のコミットを経て公開された安定版リリースである。ShopifyやHEYといった大規模アプリケーションでは、すでに本番環境で数か月間稼働しているという。 Active Job Continuations：長時間ジョブの継続実行 これまで再起動などによって中断されたジョブは、最初から再実行する必要があった。Rails 8.1では、ジョブを「ステップ」に分割し、中断時に
RailsTokyo #1 に参加した - koicの日記
RailsTokyo #1 に参加した。 railstokyo.connpass.com この日は勤務先の京橋オフィスに出社して、電車の乗り継ぎも面倒なので日本橋の会場まで歩いて参加。東京でこういった Rails のイベントは本当に久しぶりな気がしている。開始前には dak2 さんと OSS まわりの話をしたり、yuki3738 や ginkouno なんかと RailsTokyo に関するだらっとした話をしたりしていた。 招待講演の yahonda さんのトークは、これまで聞いてきた yahonda さんのトークの中では珍しく、ご自身のキャリアにも触れたものだった。話の最後の方で、自分なりに持ち寄れるものでコミュニティに足を運ぶことで「知り合いが増える... ともだちが増える」と話されていた点が印象的でした。特に「知り合い」からの「ともだち」へちょっと間を置きつつはにかみながら転換してい
The Rails Doctrine
Ruby on Railsの驚異的な台頭は、斬新な技術とタイミングによるところが少なからずあります。しかし、技術的な優位性は時間の経過とともに失われていきますし、タイミングの良さだけでは長期にわたってムーブメントを維持できません。そのため、Railsがどのようにして現役であり続けることができたのかだけでなく、どのようにしてそのインパクトとコミュニティを成長させてきたのかについて、より広範な説明が求められています。私が提唱するのは、永続的な実現要因は、今も昔も物議を醸しているドクトリン（信条）にあるということです。 このドクトリンは過去10年の間に進化してきましたが、その最も強力な柱のほとんどは開発当初からのものでもあります。私はこれらの考え方の根本的なオリジナリティを主張していません。Railsの主な成果は、プログラミングとプログラマーの本質についての異端的な考えを手広く集めたものを中心に
「生成AIでサクッと！」というわけには行かなかったCoffeeScript → TypeScriptへの置き換え - エムスリーテックブログ
本記事は、コンシューマーチームブログリレー 3日目です。 はじめまして。エンジニアグループ、コンシューマーチームの松本と申します。 本記事では、社内で開発・利用している内部ツールのフロントエンドを CoffeeScript + Backbone.js の構成から TypeScript + React の構成に置き換えた時の知見を共有できればと思います。 早速ですがまずは宣伝から 弊チームでは AskDoctors というサービスを開発しております。 「病気・症状のお悩みを実際の医師に聞ける」というサービスで、１つの質問に複数の医師から意見を伺うことができるサービスとなっております。実在の医師から意見をもらうことができるので、悩み事があればぜひ相談してください。 早速ですがまずは宣伝から 背景 当時は最先端だったAltJS 役目を終えたCoffeeScript 作業の手順 CoffeeScr
Fintech, Rails, 運用, 高信頼性みたいな話をKaigi on Rails 2025でしました - valid,invalid
トークの正式タイトルは「5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム」。副題つきのタイトルは長くてブログタイトルとしては不利ですね。 Kaigi on Rails 2025は2021年から5年連続でスピーカーとしての参加になりました。 今回の発表について 発表に用いたスライドは以下。 主張は概ね以下の2枚にまとまっています。 すべてを要約した図 Fintechシステムとして求められる品質特性を実現するため運用でいろいろやってきた いずれもFintechに限らずやることで高信頼性に繋がる 一般化 求められる品質特性や、運用を通じて実現したいことは異なる 自分の事業・プロダクト・サービスにあてはめて考えてみるとよい 今回もまたこれまでやったことないアプローチに挑戦してみました*1。やり遂げた1つの課題を深掘りするのではなく、派手さはないが見逃され
Kaigi on Rails 2025で「dynamic!」という基調講演をしました - moroのブログ
去る9/26-27に開催された Kaigi on Rails 2025 にて、オープニングキーノートを努めさせていただきました。 参加者の皆様、他の登壇者の皆様、オーガナイザーの皆様、スポンサーの皆様などなど、関わった皆様に感謝いたします。ありがとうございました。 無事に終えることができてホッとしていますし、感想Tweetやブログ記事を見ては、とてもとても喜んでいます。 speakerdeck.com 今回の話は、文脈や行間や語りたい意図を、できるだけ明示しようと構成したつもりです。 自問自答しながら「実はこういうモチベーションで話したんですよ〜」っていうのを思いついたら、それをスライドや説明に戻すみたいなことを繰り返しました。その過程で、 @snoozer05 (敬称略、以下同)にもたくさん相談に乗ってもらいました。ありがとうございます。 おかげで、話したかったことはホントにすべて出し切
Kaigi on Rails 2025 参加レポート 〜 丁寧に作るということ | Wantedly Engineer Blog
こんにちは。バックエンドエンジニアの西野です。9月26日、27日に開催された Kaigi on Rails 2025 に、ウォンテッドリーのメンバー5名で現地参加してきました。 どのセッションも素晴らしいものでしたが、本記事では特に印象に残ったものをご紹介します。 Keynote: dynamic!今年のオープニングキーノートの「dynamic!」は、継続して変化し続ける「動的な」開発をテーマにした内容でした。変化に合わせた開発というのは、修復し続ける開発ということであり、その心構えの参考として Kent Beck 氏の著作『Tidy First?』が紹介されました。この本では「修復」を「整頓（Tidy）」として表現しており、日々の開発の中でコードを整えていく重要性と手法について書かれています。 発表では動的な開発とは、小さく丁寧に作ることだとも語られており、「丁寧に作る」というのはどうい
Kaigi on Rails 2025 参加レポート
読み方ガイド Kaigi on Rails に参加したかったけど行けなかった人向け。 私自身が Rails 初心者のため、初学者にもわかりやすい構成で、専門用語は最小限。必要箇所だけコード／コマンドを添えています。 はじめに 株式会社 Inner Resource でエンジニアをしている翠川です。 9月26日〜27日に Kaigi on Rails 2025 に参加したので、参加レポートを書きました。学会ではないテック系カンファレンスは初参加で、とてもワクワクしました。 先に弊社エンジニアの記事も公開されています。ぜひ併せてどうぞ 👉 Rails歴半年のエンジニアが行くKaigi on Rails 2025 全体を通して サイトの英語化や海外登壇など、日本→世界を強く意識した運営が印象的でした。 また、身近で実務に効くセッションが多く、「Rails で開発するみんなが、似たような辛み・悩
【Kaigi on Rails 2025】「入門 FormObject」で登壇しました - 部屋の隅っこで書く技術ブログ
09/26金-27土に開催されたKaigi on Rails 2025にて「入門 FormObject」のタイトルで登壇しました。 先に発表についての補足記事は出したので、この記事ではカンファレンス全体の感想を書いていきます。 改めまして、スタッフのみなさん、聞いてくださったみなさん、ありがとうございました！ 登壇した テーマ設定 設計を扱うトーク準備の難しさ ストーリー作り 分かりやすさと正確さと尺 発表 他のスピーカーからの言及 スライドの背景に使った秘境駅 発表を聞いた Keynote: dynamic! Railsアプリケーション開発者のためのブックガイド Railsによる人工的「設計」入門 今改めてServiceクラスについて考える 〜あるRails開発者の10年〜 2重リクエスト完全攻略HANDBOOK Railsアプリから何を切り出す？機能分離の判断基準 Rails on S
Kaigi on Rails 2025で登壇してきました - joker1007’s diary
今回のKaigi on Rails 2025で登壇の機会を頂いたので、話をしてきました。 トーク内容は今改めてServiceクラスについて考える 〜あるRails開発者の10年〜です。 speakerdeck.com ちなみに真面目にインデックス作るの面倒臭いのでURL直じゃないと参照できないんですが、Github PagesにHTML版があります。 資料中のリンクが直接クリックできたりするので、その辺り触りたい人はこちらもどうぞ。 http://joker1007.github.io/slides/kaigi_on_rails_2025/slides.html 使い古されたネタなんですが、ある程度バックグラウンドがある自分がベテランポジションとして話すことには意味があるかなあと思って改めて話をさせてもらいました。 実際言いたかったこととしては、Serviceクラスをフックにしつつ、チーム
続・wkhtmltopdfの次どうするか問題 - おもしろwebサービス開発日記
wkhtmltopdfの次どうするか問題 - おもしろwebサービス開発日記の続き。 上の記事でも書いていますが、令和の今RailsアプリケーションでPDFを生成する基本的な方針としては次の2択だと思っています。 chromeを使ってHTMLからPDFに変換する Thinreports などで直接PDFを生成する 「chromeを使ってHTMLからPDFを生成する」のgemとしてはgroverが有名ですね。だけどこれはruby -> puppeteer -> chromeという構成で、間にnode製のツールであるpuppeteerが挟まっています。 ferrum はrubyから直接chromeを扱うgemなので、これを利用するとnodeが不要になるしメモリ消費量も多少下がるはずだしいいじゃん、と前記事を書いているときは思っていました。しかしferrumはあくまでchromeを操作するのが目
🛤 Rails 8はSQLiteで大幅に強化された「個人が扱えるフレームワーク」（翻訳）｜YassLab 株式会社
原著者の許諾を得て翻訳・公開いたします。 英語記事: Supercharge the One Person Framework with SQLite | Fractaled Mind 原文公開日: 2024/10/16 原著者: Stephen Margheim 日本語タイトルは内容に即したものにしました。 また、見出しを適宜加えています。 本記事は、Rails World 2024における私の発表を編集して記事化したものです。以下のYouTube動画でもご覧いただけます。 はじめに Railsは誕生したときから、アイデアを超音速で宇宙空間に打ち上げるロケットエンジンのような存在として名を馳せてきました。しかし少なくとも私にとって、自作のフル機能アプリケーションをデプロイして動かすにはロケット科学者になる必要がある気もしていました。 ロケットエンジンは時とともに大型化し、複雑化してきまし
東京Ruby会議12で「混沌とした例外処理とエラー監視に秩序をもたらす」というタイトルで登壇しました - STORES Product Blog
STORES でソフトウェアエンジニアをやっております @morihirok です。タイトルの通り先日行われた東京Ruby会議12で登壇しました。 regional.rubykaigi.org 発表資料はこちらとなります。 speakerdeck.com STORES は Sliver Sponsors として協賛させていただきました。 会自体すごく大盛況で、前夜祭から懇親会まで含めてめちゃくちゃ楽しかったです！オーガナイザー、スタッフのみなさま、素晴らしい会を本当にありがとうございました！ 今回「Regional.rb and the Tokyo Metropolis」というタイトルで東京圏の地域.rbオーガナイザーが集結するイベントがあり、印象に残っている方も多いんじゃないかなと思うのですが、それを見ながら自分の中で生まれていたストーリーがあるのでついでにその話だけさせてください。 東
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Railsアプリケーション開発者のためのブックガイド
