Rails で fat model を避けるための、あまり知られていない方法について - おもしろwebサービス開発日記
このエントリで書いた内容は、ほぼ Growing Rails Applications in Practice の内容が元になっています。英語ですが、ここで挙げた内容以外にもコードを綺麗に保つテクニックが書かれており、かつページ数も少なく読みやすいです。コードを綺麗に保つのが好きな方は一読してみることをおすすめします。 はじめに Rails で fat model を避けるための方法は、7 Patterns to Refactor Fat ActiveRecord Models を始めとして、多くのやり方が存在します*1。 validation や callback は ActiveRecord(以下AR) を継承せずとも利用することができます。7 Patterns to Refactor Fat ActiveRecord Models の 「3. Extract Form Objects
DBのViewを作ったらRailsプログラムが綺麗になった話 | 自転車で通勤しましょ♪ブログ
最近データベースというかSQLについて勉強しているんですが、奥が深いですね。この前の第9回中国地方DB勉強会のときに聞いたrank関数を使って、ランキング機能をリファクタリングしよう！と思って最近頑張ってます。というのも、複雑なクエリ（遅い）を業種数分（10回くらい）呼んでいたため、Herokuだと結構ギリギリの速度になることもあったので、なんとかしなければ！と思っていたのです。 とりあえず、私の開発環境を載せておきます。 Mac Yosemite Ruby 2.2 Rails 4.2.1 PostgreSQL 9.3.4 ひとまずrank関数を使うところまで まず、NewRelicを使ってActiveRecordが出力しているSQLを取得し、それを0xDBEのコンソールに貼り付けて、rank関数を使って業種でパーティションしてランキングを出すところまでしてみました。rank関数は、関数名
Rails複数DB Casual TalksでMySQLとActiveRecordの話をしてきた - かみぽわーる
Rails複数DB Casual Talks - connpass お疲れさまでした。 当日は準備不足で資料がただのリンク集だったのを公開用に当社比800%ぐらい加筆したので、当日参加できなかった人が見ても内容がわかるようになってると思います。 MySQLとActiveRecord @ryopekoさんのツイートふぁぼってたらみんなが複数DBの話するなかでひとりだけMySQLの話するとか公開処刑なのでは！？と思ったけど、ちょうどみんなestablish_connectionの話でおなかいっぱいでしたからね、楽しんでもらえたようでよかったです。 @kamipo fav されたということはレールズで DB 周りのつらい話、何か話してくれると思って大丈夫ですか？— 複数DB (@ryopeko) October 3, 2014 YAPC のときに kamipo さんと HUB で話した時に、レー
Rails SQL Injection Examples
Overview The Ruby on Rails web framework provides a library called ActiveRecord which provides an abstraction for accessing databases. This page lists many query methods and options in ActiveRecord which do not sanitize raw SQL arguments and are not intended to be called with unsafe user input. Careless use of these methods can open up code to SQL Injection exploits. The examples here do not inclu
プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight
おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ
てめえらのRailsはオブジェクト指向じゃねえ！まずはCallbackクラス、Validatorクラスを活用しろ！ - Qiita
てめえらのRailsはオブジェクト指向じゃねえ！まずはCallbackクラス、Validatorクラスを活用しろ！RubyRails ちょっと煽り気味のタイトルにしてみましたが、Railsで開発する時は意識的にOOPに寄せないとオブジェクトの力が活かせなくなるよってことと、Railsが提供しているクラスの責務を分割することを支援してくれる機能について話をします。 ActiveRecordの性質 Rails開発においては、モデル層にロジックを書いてコントローラーは薄くしろ、というのはしつこく言われているので、概ね浸透してきていると思います。 それに加えて、最近私が結構しつこく主張しておきたいのが、モデル = ActiveRecordでは無いよ、ということです。 ActiveRecordは成り立ちから言うと、ロジックとDBへの永続化をまとめてカプセル化するアーキテクチャパターンから来ています。
よくある？Rails失敗談 default_scope編｜TechRacho by BPS株式会社
モデルからデータを取得する際に常に特定の検索条件を指定することができるdefault_scopeですが、 デメリットについてあまり注意を払わずに使ってしまって失敗しました。 サンプル事例 環境 * Rails 3.2.12, 4.0 * MySQL 5.1.65 ※ 実際に問題が起きたバージョンが3.2.12 なのでそちらが中心になっています。 データを「名前」「年齢」どちらか指定された値で並び替えるという処理があったので、 特に指定が無ければid順で取得するという条件をdefault_scope を使って追加しました。 class User < ActiveRecord::Base default_scope -> { order(:id) } end これで、モデルからデータを取得する際に必ずORDERが指定されるようになります。 User.all #=> SELECT "users"
肥大化したActiveRecordモデルをリファクタリングする7つの方法（翻訳）
更新情報: 2013/11/19: 初版公開 2021/01/08: 訳文見直し、追記 こんにちは、hachi8833です。今回は、自分が知りたかった、Active Recordモデルのリファクタリングに関する記事を翻訳いたしました。1年前の記事なのでRails 3が前提ですが、Rails 4以降でも基本的には変わらないと思います。リンクは可能なものについては日本語のものに置き換えています。 なお、ここでご紹介したオブジェクトは、app以下にそれぞれ以下のようにフォルダを追加してそこに配置します。 注記: 以下は使われそうなフォルダを列挙しただけであり、実際にはこの一部しか使いません。 Value Object Service Object Form Object Query Object View Object Policy Object Decorator ⚓ 肥大化したActive
Rails で十分に活用されていなくてもったいない ActiveRecord::Relation のメソッド TOP 10 - 杉風呂2.0 - A Lifelog -
2013年12月2日更新: 参照されることが多いので Rails 4 の情報を訳注として追記しました。また、Rails 4 に関する情報は、 WEB+DB PRESS Vol.73 が非常に参考になるので、一読をおすすめします。 この文章は Mitch Crowe 氏のブログより 2012年4月14日の記事を翻訳したものです。 The 10 Most Underused ActiveRecord::Relation Methods http://blog.mitchcrowe.com/blog/2012/04/14/10-most-underused-activerecord-relation-methods/ 昨日は ActiveRecord::Relation のコードに膝まで浸かって、使われているのをこれまで全然見たことがない面白いナゲットを思い出させてくれた。この記事で、十分に活用
【Rails】ActiveRecord：単一テーブル継承(sti)とポリモーフィック関連を未だにぱっと思い出せないのでまとめ。 - 訳も知らないで
ActiveRecordで単一テーブル継承(STI:Single Table Inheritance)とポリモーフィック関連という2つの便利なモデルの持ち方？関係性？があるのですが、恥ずかしながらいつも混同してしまいます… 多分頭の中では両方とも「似たモデルをまとめる」みたいなぼんやりした認識してるので混ざってしまっているようで… すごい今更ですが ちょっと自分なりにまとめてみようと思います。 単一テーブル継承(STI:Single Table Inheritance) 同じような機能(メソッド)を持つActiveRecordモデルクラスが2つ存在するので、 継承を使って実装しようとした場合。 例として 「Information」モデルを継承した「Warning」クラスと「Notice」クラスを作成するとします。 （例としておかしかったらごめんなさい…） 単純に実装すると、各モデルに対しD
Associations | 優しいRailsの育て方 | ヽ( ・∀・)ノくまくまー
class Member < ActiveRecord::Base has_one :favorite end class Favorite < ActiveRecord::Base belongs_to :member end has_one で関連を定義すると、以下のメソッドが自動的に定義されます。(belongs_to 側にも同様のメソッドが定義されます)。 (関連名)(force_reload = false) : 関連するオブジェクトを取得します。 (関連名)= : 関連するオブジェクトを代入します。(自動的にDBへ保存されます) (関連名).nil? : 関連するオブジェクトが存在しないことを確認します。(なければ true を返す) build_(関連名)(attributes = {}) : 関連するオブジェクトを作成して返します。(DBへの保存はされません) create
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Mobage を支える Ruby の技術 ~ 複数DB編 ~ : sonots:blog
Blog
http://rails.office.drecom.jp/takiuchi/archive/206