スライド概要 ActiveRecordパターンに引きづられて設計が歪みがちになるのを学びほぐすことでクリーンアーキテクチャでの開発の良いスタートラインに立てるのではないでしょうか?
rescue_from で Exception をキャッチすると予期しない挙動をして驚いたことがあった。Rails ガイドを見てみると以下のようにそのような使い方は非推奨のようだった。 Action Controller Overview — Ruby on Rails Guides Using rescue_from with Exception or StandardError would cause serious side-effects as it prevents Rails from handling exceptions properly. As such, it is not recommended to do so unless there is a strong reason. Exception や StandardError を指定すると Rails による正しい
目次 はじめに 使用する関連付け preload、eager_load、includesの挙動 includesはどのような場合にpreloadとeager_loadの挙動となるのか preload、eager_loadの使い分け さいごに はじめに こんにちは、株式会社スタメンでエンジニアをしているワカゾノです! 4月からサーバーサイドエンジニアとして、弊社プロダクトTUNAGの開発を行っております。 先日、弊社CTOの松谷とペアプロを行いました。 パフォーマンス改善のタスクを行いましたが、タスクを通してN + 1問題に複数回直面しました。 Active Recordにおいて、N + 1問題を解消する方法として、関連テーブルのデータを事前に読み込んでおき、キャシュしておくという方法を取ると思いますが、Railsではその方法としてpreload、eager_load、includesメソッ
When teams use Code Climate to improve the quality of their Rails applications, they learn to break the habit of allowing models to get fat. “Fat models” cause maintenance issues in large apps. Only incrementally better than cluttering controllers with domain logic, they usually represent a failure to apply the Single Responsibility Principle (SRP). “Anything related to what a user does” is not a
こんにちは。SmartHRでRails顧問業をしています @willnetです。最近は主にリファクタリングをしています。 SmartHRのバックエンドは基本的にRubyで書かれています。しかし入社してくるバックエンドエンジニアは必ずしもRubyやRailsを長年使ってきた人だけではなく、前職では他言語を使っていてRuby(Rails)はほとんど使ったことがないという人もいます。 webアプリケーションを作る、という点ではどの言語でも抑えるべき点は同じですが、RubyやRailsに特化した考え方や書き方もありますよね。SmartHRではそれを効率よく習得してもらうために読書会を開催したり、社内のドキュメントツールに知見を書いて共有したりしています。 僕も社内のドキュメントツールにActive Recordの付き合い方ついて書いたところ、評判が良く「テックブログにしたら?」と言われたので今回一
はじめに 大量のレコードを扱うときに便利な find_each は order での順序指定ができません。その理由は http://qiita.com/yugo-yamamoto/items/5569c037e8917fdb59ae にある通り。 とはいえ、簡易なアプリを作成するにあたって find_each_with_order があったら良いなぁというので探してみたらこんな記事を見つけたので http://grosser.it/2009/09/09/activerecord-find_each_with_order-find_each-with-order/ rails4で使えるように書きなおしました。 見ての通り、limitとoffsetを使うのでパフォーマンスを求める場面では使えません。全件持ってくるのはメモリ的に無理だけど、多少効率悪いのは問題ない、くらいな状況では使っても良いか
バックエンドエンジニアの横塚です。 Railsで中規模以上のサービスを運用していると、大量のレコードやcsvをバッチで処理したい場面などが出てくると思います。 当たり前のように意識できている人も多いかと思いますが、今回はおさらいの意味も込めてバッチで大量データを扱うときに気をつけていることをまとめていこうと思います! 大量レコードに対して処理をするときはfind_eachやfind_in_batchesを使う DBからデータを取得してきて処理をしたい場合、eachで処理しようとすると対象データがすべてメモリに展開されてしまいますが、find_eachは1行ずつメモリに展開するため、レコード数を気にせず処理をすることができます。 User.each do |user| # なんか処理 end ↓ User.find_each do |user| # なんか処理 end また、find_in_
これは 渋谷.rb[:20150617] の発表資料です スライドバージョン 複数認証を例にしたポリモーフィックとSTIの設計紹介 #shibuyarb sue445 2015/06/17 Shibuya.rb 自己紹介 sue445 株式会社ドリコム 所属 社内ツールとか社内ライブラリとか TDDおじさん プリキュアおじさん 【今期の嫁】キュアトゥインクル 【本妻】キュアピース Agenda 前置き(やりたかったこと) ポリモーフィックとSTIでのそれぞれの設計 ポリモーフィックでよかったこと (≒ STIのデメリット) ポリモーフィックでつらかったこと (≒ STIデメリット) まとめ おまけ(reveal.jsのこと) やりたかったこと とある社内アプリの開発にて下記の要件があった 1ユーザで下記のいずれかの認証を利用 普通の従業員であればLDAP認証 LDAPに紐付かないユーザ(常
はじめに ActiveRecordでN+1問題やスロークエリを解消するためにeager loadingを行う場合、普段Railsを使って開発されている方であれば、パッと思いつくのはincludesではないでしょうか?もしくは、preloadやeager_loadを使用しますよね。 この記事では、Webサイト表示パフォーマンスを保つため、ActiveRecordのメソッドの違いや、どいういう場合に使ったら良いのか、どいういう場合には使わない方が良いのかについて書きました。 実際に Railsアプリケーションを作成して解説していきます。 用語の説明と分類「ORM の Eager loading と Lazy loading」 Webサイト表示パフォーマンスを保つため、ORM(RailsではActiveRecord)では、Eager loading と Lazy laodingというものをサポー
バックエンドエンジニアの宮澤です。 Railsアプリを開発していると関連テーブルを取得するactiverecordのincludes, eager_load, preloadメソッドはよく使いますよね。 アプリケーションのある箇所でスロークエリが出ているのを見つかって対応した際に、テーブル関連付けの種類によるこれらのメソッドの挙動について調べてみました。 テーブル設計 ER図 サンプルとしてシンプルに地域 => 国 => 都市と1:Nの関係でテーブルを作成します マイグレーション class CreateRegions < ActiveRecord::Migration[6.0] def change create_table :regions do |t| t.string :name t.timestamps end end end class CreateCountries < Ac
マネーフォワード福岡拠点の責任者をしております 黒田 です。 普段はRailsエンジニアとして マネーフォワードクラウド経費 の開発を担当しています。 普段Railsを使って開発されている方であれば、N+1問題に悩まされた経験は大抵の方がおありではないでしょうか。 N+1なクエリの発見には bullet を使うと良いですね。 bulletを使うとN+1なクエリを発見してくれ、さらに、具体的にここにincludesを追加しなさいと指摘までしてくれるので大変助かります。 しかし、先日bulletに言われるがままにincludesを付けてみたところ、N+1は解消したものの、スロークエリに見舞われることとなったので、includes,preload, eager_loadについて改めて調べてまとめてみることにしました。 (ソース調査したRailsのバージョンは 6.0.0.beta3 です。) i
はじめまして。2019年4月から妊娠・出産アプリ『Babyプラス』の開発チームにJOINした濱田です。 『Babyプラス』のバックエンドはRailsで実装されているのですが、とあるCSV生成処理がとても遅かったので100倍以上に高速化しました。この過程でRailsアプリの処理高速化に関する以下の知見が得られたので、具体例を交えて共有します。この知見は、ActiveRecordを使用してMySQLなどのRDBMSからデータ抽出をする様々な場面で活用できると思います。 いわゆる「N+1問題」を起こさないのは基本 「ActiveRecordインスタンスの生成コスト」はそれなりに高い pluckはjoinsと組み合わせることで他テーブルのカラム値も取得できる 前提: DBスキーマとデータ規模 今回の処理高速化に関わるモデルのDBスキーマとデータ規模は以下の通りです。なお、これらは本エントリ向けに少
1 Active Recordクエリインターフェイスとは? 生のSQLを使ってデータベースのレコードを検索することに慣れた人がRailsに出会うと、Railsでは同じ操作をずっと洗練された方法で実現できることに気付くでしょう。Active Recordを使うことで、SQLを直に実行する必要はほぼなくなります。 Active Recordは、ユーザーに代わってデータベースにクエリを発行します。発行されるクエリは多くのデータベースシステム(MySQL、MariaDB、PostgreSQL、SQLiteなど)と互換性があります。Active Recordを使えば、利用しているデータベースシステムの種類にかかわらず同じ記法を使えます。 本ガイドのコード例では以下のモデルを使います。 class Book < ApplicationRecord belongs_to :supplier belong
さくっとDBにアクセスするバッチやスクリプトを、rubyで書きたいなぁと思うことはないですか? Railsで使われている O/Rマッピングのライブラリ「ActiveRecord」ですが、Railsではなくただのrubyプログラムから単体で使うことが出来ます。 今回は、「ActiveRecord」を単体で使用して、MySQLにアクセスするスクリプトを書いてみます。 環境 ruby 1.9.3 activerecord 3.2.8 ActiveRecordを使ってみる ActiveRecordをインストール $ gem install activerecord MySQLに接続するためのアダプタインストール $ gem install mysql2 下のようなエラーが出る場合、 Building native extensions. This could take a while... ERR
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く