こんにちは、タイミーでバックエンドエンジニアをしている 福井 (bary822) です。 タイミーのバックエンドは巨大な Rails のモノリスアプリケーションです。以前から「アクセスが集中する特定のテーブル（以下、人気テーブル）への DB マイグレーションが日中に通らない」という問題を抱えており、看過できないレベルになってきたため、本格的に対処に乗り出しました。 この記事では、原因となっていたロングトランザクションに対し、Datadog と Devin を組み合わせた自動修正フローで対処した話と、その設計の裏側を紹介します。 DBマイグレーション失敗のメカニズム 日常的に発生していたのは、人気テーブルへの ALTER TABLE が日中はほぼ通らない、という状況でした。原因は メタデータロック (MDL) です。 Aurora MySQL(8.0) では、SELECT / INSERT
先日のこの記事が思いのほかバズってしまった やっぱりRailsはまだまだ使える！って話をすると、 「そうだそうだ！Ruby大好き！」勢と「Rubyなんかとっくにオワコン、TS・Goでいいやん」勢 がバトルを始めるらしい 私は今はRailsが大好きだけど、バージョン5〜6の時（だいたい4年ぐらい前？）の時はフロントエンド周りの対応が酷すぎたので本当にRailsが嫌いで、TSに夢中になっていた。 ので、どちらの気持ちもわかる。 どちらもいい点があるし、この手の話題は前提条件が違えばいくらでも評価が変わりうる話ではある。だからは結論はないし喧嘩はやめよう（そもそも煽ったのは俺） 面白そうなコメントをXとはてなブックマークでいただいたので返信していく。 あくまで私は、「フリーランス×ソロプレナーとして新しくプロダクトをリリースすることに特化してRails最高」って目線なので、その点はよろしくお願い
こんにちは、フリーランスとして働いてるハルクです 最近自分の会社を立ち上げたことで、「AI時代にフィットしたwebフレームワークとは何か」を考えるようになりました。 私はRubyでコンピューターサイエンスの世界に入ってから、最近流行りのTypescript(Next.js, Nuxt.js)、Go、Rustなどを使ってサイドプロジェクトを立ち上げてきましたが、 結局のところ、RubyやRuby on Railsが最も自分のユースケースにフィットすることがわかりました。 そして、その評価は、AIコーディングが発達してきた2026年においても変わりません。 今回は、私がなぜAI時代にRubyを使い続けると判断したのかを説明したいと思います。 なお、私は自分の会社で始める今後全てのビジネスにRailsを使う予定です。そういったある意味「Rails信者の目線」の一つとして捉えてもらえればと思います
Rails のリポジトリをクローンします。 git clone https://github.com/rails/rails.git cd railsIssue を確認します。gh コマンドには GitHub GraphQL API のように関連するPR を追跡できないようです。 gh issue list --author "@me" gh issue view <number>プルリクエストをローカルにチェックアウトします。 gh pr checkout <number>5.4 ローカルブランチでアプリケーションを実行する ダミーのRailsアプリケーションで変更をテストする必要がある場合は、rails newに--devフラグを追加すると、ローカルブランチを使うアプリケーションが生成されます。 Ruby on Rails に貢献する方法 - Railsガイド--dev オプションを付
HTML 出力は見やすくて自由度が高い Claude Code に成果物を出力させる際、プレーンテキストや Markdown ではなく HTML で出力させると、そのままブラウザ (Chrome など) で開くことができ、Markdown の本部プレビューと比べて人間にとって非常に見やすくなります。 HTML は見出しや箇条書きにとどまらず、各 HTML 要素や CSS, JavaScript, SVG などを組み合わせて多彩な表現ができます。Markdown と比べてはるかに自由度が高いです。 Claude Code チームも 2026/05 に、Markdown ではなく HTML を出力形式として推奨する記事を公開しています。 HTML での問題: 見た目やフォーマットがばらつく 一方で、HTML を出力するつど見た目やフォーマットにばらつきが生じて困るという問題があります。 出力の
お疲れ様です！ シリーズで並行性・パフォーマンスの話を書いてきましたが、今回は レースコンディション（競合状態） をまとめてみました 「ローカルでは再現しないのに、本番でたまに二重登録される…」の正体です。 興味ある方は読んでいただけると嬉しいです レースコンディションとは？ ひとことで言うと 「複数の処理が"同時"に動いたとき、タイミング次第で結果が壊れる」 バグです。 身近な例で言うと、在庫が1個の商品を、2人が同時に買う場面です :shopping_cart: 時刻 → Aさん： 在庫を確認(1個ある！) ──────→ 購入(在庫を1減らす) Bさん： 在庫を確認(1個ある！) ──→ 購入(在庫を1減らす) 結果：在庫 -1（2人とも買えてしまった）💥
My Subversionのリポジトリ管理機能はRailsで構築 公式サポートがすでに終了しているRails UJSをHotwire Turboにアップデート Geminiを使用してTurboについて効率的に調べることができた きっかけ 弊社サービスMy Subversionで提供しているリポジトリ管理機能RepoMatはRuby on Railsを使用しています。アップデートは定期的に実施しているのですが、今回はRails UJSをHotwire Turboに置き換えようと思いました。 Rails UJSはRails6以前に標準で組み込まれており次の機能を提供していますが、Rails7以降は非推奨となりました。 非同期通信（Ajax）の実行 GET以外のHTTPメソッドのサポート 確認ダイアログの表示 フォームの二重送信防止 CSRF保護 Rails UJSは最新のRails8でも動作し
こんにちは、技術書ライブラリーのディレクター、山岡（@hiro_y）です。 6月18日（木）、「推し本トーク#1」を技術書ライブラリーで開催しました。参加いただいた皆さま、誠にありがとうございました。 わいわい#技術書ライブラリー pic.twitter.com/usMykawAt0 — ちひろ@GoConnect (@chiroruxxxx) June 18, 2026 最終的に私を含めて15人の方に参加いただき、そのうち10人が「トーク」で本を紹介するという、発表する人の方が多い会となりました。様々なジャンルの書籍が紹介されましたし、その後の懇親会でもいろいろな会話をすることができ、大変楽しかったです。 当日紹介された書籍は次の通りです（複数冊の紹介も含みます）。技術書ライブラリーに収蔵されている本も結構ありました。 『アジャイルコーチング』 『世界一流エンジニアの思考法』 『部下とし
has_one関連を勘違いしていたRails初心者が書いた記事です。 has_many関連は1対多の関係である以上毎回すべて取得するのは大変そうなので、関連先参照時に適宜取得クエリを実行するのは理解できるのですが、has_one関連って「1つ」しかないのだから、自動的に読み込まれる（キャッシュされる）のだと思い込んでいました。 目次 要約 経緯 原因判明 解決 要約 AとBが1対1の関係であり、A has Bの関連の場合、 has_oneを書いてるからって本体(A)を取得した際にhas_one関連先(B)を自動で読み込むことはない。関連先(B)を読み込む際に追加でクエリを実行する。 eager loadingを明示することで関連データを取得することができる。 経緯 Rails学習のために自作の勤怠管理アプリを制作していた時の話です。 アプリ内で月次の勤怠一覧を表示する際に問題が発生しました
書籍紹介『シンプリシティ―持続可能かつ人間的で効果的なソフトウェア開発』 書いた人：しまだ 書籍情報 『シンプリシティ―持続可能かつ人間的で効果的なソフトウェア開発』 著者・訳者 Dave Thomas (著)、島田 浩二 (訳) 発行日 2026 年 6 月 2 日 第 1 版 第 1 刷 ISBN 978-4-8144-0171-0 出版社 オライリー・ジャパン 価格 2,640 円 + 税 (紙書籍) 原書 “Simplicity: Sustainable, Humane, and Effective Software Development” (Pragmatic Bookshelf), 2025 年 7 月発行 本記事の最後に、Rubyist Magazine 読者に向けた本書のプレゼントのお知らせがあります。お見逃しなく! 書籍の紹介 2025 年 7 月に原書が刊行された “
One engine, many tools A few years ago, the new Ruby parser Prism was released. One of its primary goals was to unify the community since we had multiple implementations of Ruby parsers, each with their own bugs, differences in implementation and portability. By having a single parser, community investments in performance and correctness benefit every single tool built on top of it (including Ruby
こんにちは、st-1985 です。 今回はCommon Table Expression (CTE)を使用したクエリの処理に時間がかかっていたので改善した話を書いていきたいと思います。 状況 以下のようなメッセージの配信情報とその統計情報の単位(Unit)となるモデル構成があります。 Unit: 統計集計の単位となるエンティティ Delivery: unit_id と delivered_at を持つ配信レコード。Unit ごとに複数存在する 管理画面には Unit の一覧ページ(1ページ最大10件)があり、そこでは各 Unit において最後に行った配信の時間を表示しています。 定期的に行っている Datadog を使ったパフォーマンス確認の場で、この一覧ページの表示時間が遅いことがわかりました。 改善前のコード # Unit has_one :last_delivery, lambda
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
