こんにちは。サーバーサイドエンジニアの三村（@t_mimura39）です。 N番目の「ClinPeerアプリ開発の裏側連載記事」でございます（連載記事を同時執筆しているため本記事が何番目になるのかもはや不明）。 tech.medpeer.co.jp 今回はClinPeerで実践した「Railsプロジェクトのオブザーバビリティ強化施策」の紹介記事になります。少しマイナーなネタですね。 目次 オブザーバビリティとは ログ アクセスログの構造化 その他ログの構造化 実行コンテキスト リクエストログのトレースID ログ出力例 query_log_tagsの有効化 ActiveStorage+S3 ファイルアップロードのきっかけとなったレコード情報 ファイルアップロード時の実行コンテキスト情報 モンキーパッチやめたい Amazon S3 メタデータ APM エラー管理 おわり オブザーバビリティとは
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: How to add index to a big table of your Rails app | Arkency Blog 原文公開日: 2024/06/13 原著者: Szymon Fiedler 日本語タイトルは内容に即したものにしました。 成功したアプリケーションでは、一部のテーブル（usersテーブルなど）がかなり肥大化することがあります。ご興味がおありでしたら、データベースのパフォーマンスを定期的にチェックしてみましょう。メトリクスで遅いクエリが見つかったら、インデックスを付け忘れている可能性が高いでしょう。 🔗 DBエンジンの現状をチェックしよう 現代のデータベースなら、ほとんどの場合非同期かつ非ブロッキング方式でインデックスを作成可能ですが、そのデータベースのルールにどんな例外があるかをもれなく理解しておく
The In-depth Guide to ActiveRecord load_async in Rails 7 Updated Mar 1, 2022 17 minute read Rails 7 introduces ActiveRecord load_async method that runs SQL queries asynchronously in the background thread. This seemingly simple change of just adding a single new method that takes no arguments has profound implications for database layer interactions. In this tutorial, we’ll deep dive into the intri
STORES 予約 でエンジニアリングマネージャーをしている Natsume です。 STORES 予約 は10年モノの45万行、380テーブルある大きなモノリスの Rails アプリケーションです。 業種にとらわれない汎用的な予約システムであり、それらに対応するように複雑なコードベースになっています。また、ここ 1~2 年はプロダクト間連携を進めており、各基盤やアプリケーションともつなげていく開発を進めています。今後も新規プロダクトとの連携や機能開発を進めるには、少しでも認知負荷を上げずに開発しやすい状態を保ち続けるか、が重要だと感じました。 その課題感の中で、今回はモジュラモノリスを選択し導入をしましたので、そちらのお話をしたいと思います！ 現状の課題感 私が入社した3年前から STORES 予約 の開発メンバーは3倍になり比較的新しいメンバーが多く、また古くからいるエンジニアも少数な
About This Title Pages: 454 Published: June 2024 ISBN: 9798888650387 In Print High Performance PostgreSQL for Rails Reliable, Scalable, Maintainable Database Applications by Andrew Atkinson Build faster, more reliable Rails apps by taking the best advanced PostgreSQL and Active Record capabilities, and using them to solve your application scale and growth challenges. Gain the skills needed to comf
The “getting-back-into-full-stack” trend in web development communities is gaining more traction. Frontend frameworks are trying to embrace server components, htmx is the new black, and LiveView and LiveWire are conquering Elixir and Laravel applications, respectively. And, of course, Ruby on Rails has its newer offspring, Hotwire. Let’s explore how far you can go with the full-stack approach in R
SmartHRでは開発にRuby on Railsを広く採用しています。 今日は負債解消のために、開発しているサービスでRailsのモデル名をすべて変更した話を紹介します。 既存のモデル構造のつらみ 私達が開発しているサービスでは、モデルの親子構造が分かりやすいということで、モデルをネストした構造にしていました。 例えば、 User に紐づくプロフィール画像 User::ProfileImage は、 app/models/user/profile_image.rb に配置する具合です。 パッと見の構造が分かりやすいのですが、時が経つにつれて次のようなつらさが顕在化してきました。 Railsの規約(推奨ルールのようなもの)に則っていないので、関連定義が冗長になる テーブル名が長くなる。 外部キーや関連名が長くなる。 関連名と外部キー名が一致せず、カラムを呼び出したいときにDB定義を見ないと
こんにちは クラウド経費開発チーム ・ クラウド債務支払開発チーム の 江口 です。普段 Ruby on Rails （以降Railsといいます）を使って開発しています。今回は before_action のデバッグを助ける action-tracer という gem を紹介します。 はじめに Rails のコントローラではよく before_action を使ってコードを再利用します。 しかし before_action が大量になり、コントローラの継承関係も深くなってくると、実行順序を追跡するのが難しくなります。 コード理解が浅いプログラマーはもちろん、ベテランのプログラマーでも手を焼かされた経験は多いのではないでしょうか。action-tracer はこのデバッグの苦しみを和らげてくれます。 before_action, after_action がどの順序で実行されたか befor
こんにちは。サーバーサイドエンジニアの三村（@t_mimura）です。 主に保険薬局と患者さまを繋ぐ「かかりつけ薬局」化支援アプリ kakariのサーバーサイド開発（Ruby on Rails）を担当しています。 突然ですが！ この度kakariプロジェクトは「型導入」をしました！ kakariのRailsリポジトリに型導入PRがマージされた様子 皆さんのプロジェクトは「型導入」していますか？ 「型導入」しているRailsプロジェクトはまだ少ないのではないでしょうか なぜ型導入しないのか 型を導入すると何かしらが便利になることは分かっているのに何故やらないのでしょうか（煽り気味） 「型の恩恵」と「型を自分たちで書くコスト」の２点を比較していませんか？ RubyKaigi 2023開催前の私がまさしくそう考えていました。 本当にその２点を比較するべきなのかをここで再考してみましょう。 「型導
SmartHRではRuby on Railsを多くのサービスで採用しています。 そのため、不足している機能や不具合があればrails/railsへコントリビュートすることがあります。 今日は、日々のぽつぽつとしたコントリビュートの中から、Rails 7.1に追加したUNIQUE制約について紹介します。 unique_constraint(UNIQUE制約) UNIQUE制約(unique_constraint)はRails7.1(執筆時は未リリース)から利用可能になるActiveRecordの新機能です。 rails/rails#46192 PostgreSQLでしか利用できませんが、下記のようにunique_constraintで遅延可能なUNIQUE制約を定義できるようになりました。 # create_table内で使う場合 create_table :items do |t| t.i
The Case Against Monkey Patching, From a Rails Core Team MemberMonkey patching is considered one of the more powerful features of the Ruby programming language. However, by the end of this post I’m hoping to convince you that they should be used sparingly, if at all, because they are brittle, dangerous, and often unnecessary. I’ll also share tips on how to use them as safely as possible in the rar
Rubyist Hotlinksにインスパイアされて始まったRubyistめぐり。第1回は高橋征義さんをゲストに迎えて、お話を聞きました。こちらは後編です。前編はこちら。 Rubyが他の言語に与えた影響 藤村：第2部、高橋さんについて聞いてみようと思います。今更ながらRubyについて聞きたいんですけど、好きな機能とかありますか？ 高橋：好きな機能ですか？あんまり機能としてこれというのなくて、全体的に使い勝手がいいですね。まあでも、そういう意味でいえばオープンクラスの方がいいんじゃないの？みたいな感じがしますね。オープンクラスじゃないRubyはつらそうだって。 藤村：確かに。 高橋：つらそうというかつまらなさそうですね。オープンクラスが原因でつらいことになるのはわかるんですけど、でもあれがないんだったら他の言語でもいいよね、って。 藤村：Rubyがああじゃなかったら他の言語は今のようになって
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Gemfile of dreams: the libraries we use to build Rails apps—Martian Chronicles, Evil Martians’ team blog 原文更新日: 2024/05/28 原著者: Vladimir Dementyev（首席バックエンドエンジニア）、Travis Turner（技術記事編集者） サイト: Evil Martians -- ニューヨークやロシアを中心に拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 日本語ブログ: 合同会社イービルマーシャンズ - Qiita 日本語タイトルは内容に即したものにしました。また、gemごとにGitHubリポジトリへのリンクカードも追加してあ
「iCARE Dev ブログ」は、2025年2月27日をもちまして終了いたしました。 長らくご覧いただきまして、誠にありがとうございました。 今後は iCARE Official Note をご覧いただければ幸いです。
A common critique of Rails is that it encourages a poor separation of concerns. That when things get serious, you need an alternative that brings the missing pieces. We disagree. I have often heard this: vanilla Rails can only get you so far. At some point, apps become unmaintainable, and you need a different approach that brings the missing pieces, because Rails encourages a poor separation of co
Ruby on Railsを推進する「The Rails Foundation」発足、理事長にDHH氏が就任。Cookpad、GitHub、37signals、Shopifyなどが創立 創立メンバーとなる企業はCookpad、Doximity、Fleetio、GitHub、Intercom、Procore、Shopify、37signals。理事長にはRuby on Railsの作者であるDHH（David Heinemeier Hansson）氏が就任します。 The Rails Foundation kicks off with one million dollars from @cookpad, @doximity, @fleetio, @github, @intercom, @procoretech, @Shopify, and @37signals to improve the
GitHub’s ViewComponent library has been around for some time, helping developers stay sane while building the view layer of their Ruby on Rails applications. It’s steadily grown in popularity—but not as quickly as probably deserved. In this series, we’ll lay out why you need to give it a shot, too. We’ll discuss some best practices and examine various tips and tricks that we’ve accumulated in our
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く