ActiveRecord のモデルを整理する7つのパターン - tkawachi Blog
7 Patterns to Refactor Fat ActiveRecord Models という記事があり、読もう読もうと思いつつ1年くらい経ってしまった。 ようやく読んだので理解した内容を書いておく。 コード例は元記事のもの。 Rails で thin controller, fat model を心がけていると、model がマジで激太りしてヤバくなる。 実際に自分が仕事で書いている rails アプリも激太りしててヤバい。 この blog の筆者が作っている CodeClimate で C 判定をもらう程度には肥満体型になっている。 Mixinに抜き出さない! Model が太ってきた時に考えるのは ActiveSupport::Concern を使って感心事を抜き出して、Mixin にすることだと思う。 実際に手元のアプリでも models/concerns/ なんていうディレ
Hello! Elasticsearch. – Medium
Elastic Stack (Elasticsearch) Advent Calendar 2020 の 12月21日のエントリーです。
dstatをfluentd + GrowthForecastで可視化する - Qiita
dstatの結果をfluentd経由でGrowthForecastに投げる方法は、ぐぐると何件かブログ記事がでてきます。 ただ、どれもdstatを改造したり、プラグインを改造したりしてて、あまり使い勝手がよくありません。 というわけで、gemでいれれるプラグインだけを使って、可視化できる設定を探してみました。 準備 必要なgemをインストールする。 <source> type dstat tag dstat option -cm delay 3 </source> # GrowthForecast用にメッセージを加工する <match dstat> type copy # CPU関連の結果だけを取り出す <store> type map tag "perf.cpu" time time record record['dstat']['total cpu usage'] </store> #
関連モデルの命名 - 鳩舎
今日は Rails での『関連モデル』の名前について考える。 構造としてはこんな感じ。 ・ルーム(Room)に所属するユーザー(User) ・ルーム(Room)での管理者権限を持つユーザー(User) どちらの関連も N:N の関連。いわゆる has_may な感じ。 で、こういう時の命名って Room モデルと User モデルだから RoomUser とか UserRoom とかっていうモデルやテーブルを作りがちなのだけれど、今回は同様の形態の関連が2つあるのでちょっと微妙な事になりそう。 っていうか、まずもって RoomUser モデルってなんだよ。なんのモデルだよそれ。って感じなので名前を考える。 ルーム(Room)に所属するユーザー(User) 関連モデルのデータは大抵2つのフィールドを持っている。 Migration あたりから抜き出すと t.references :room
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/fl04t/items/57ebb0fe8009d00c8499
