ActiveRecordの読み込みが実際にトリガーされた場所をログに記録するgem - Qiita
ActiveRecordは必要になるまでDB読み込みをしません。 なのでやたら複雑なビューの中でクエリを弄ったり、コントローラーが肥大化してる状態でひどいSQLがログに流れてくると、パっと見ではどこが原因なのかすぐに分からない。 なので、SQLが実行された時にそれが実際にトリガーされたソースコードの位置も一緒にログに吐いてくれるgemを作りました。 bulletで分からないような、ビューのループの中で直接モデル読んでるみたいなヤバイ箇所を速やかに見つけるためのものです。 joker1007/activerecord-cause 仕組み的にはActiveRecordのロギングの仕組みを丸パクリしてcaller_locationsを足した感じ。 全ての読み込み位置を表示するわけではなく正規表現でマッチするパスを持ったソースコードの位置のみをログに記録します。 Railsで利用する場合は自動的に
FactoryGirlのtransientとtraitを活用する - Qiita
FactoryGirlでテストデータを定義する時に、transientとtraitを活用すると色々捗るという話。 transientは実際に作成するデータと直接関係無い新しいattributeを定義する機能。 そこで定義されたものは実際のmodelにはセットされないしattributes_forでも出力されません。 何のために使うかというと作成時に挙動を変更するためのフラグや追加データとして利用するのが一般的です。 traitは属性の定義を一纏めにして名前を付けられる機能です。 parentを指定したfactoryの継承とは違い、traitは単体ではfactoryとして機能しません。 あるfactoryの特定の状態に名前を付けて、付け外しできるようにする、というのが主な使い方になります。 例えば、あるfactoryをある時はadminある時は非adminで作りたい時等に有効です。 個人的に
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
開発しやすいRails on Docker環境の作り方 - Qiita
最近、Rails界隈でDocker使い始めました、という話を聞く機会が増えてきたので、自分が開発環境整備用に構築したDockerの設定をまとめておく。 ちなみに、production運用については以前書いたので適当に探してくださいw 結論から書いておくと、volumeをちゃんと活用すればいい、ってだけの話です。 まず、本番用と開発用のDockerfileは分けた方が良い。一つでやろうとするとどうにも無理がでるので。 自分はDockerfileとDockerfile-devというものを用意している。 docker-composeはほぼ必須です。少なくともrailsプロセスとDBだけでも二つは必要だし、Dockerfileを分けてると事故るので。 Dockerfileはこんな感じ。 FROM mybase:ruby-2.3.1-debian RUN echo "deb http://http.
Rails4.2のweb-console上で直接Rakeを実行する - Qiita
ActiveRecord::PendingMigrationErrorでエラー画面に飛んだ時、下に出ているweb-consoleのreplからrake db:migrateが実行できれば便利なのに、という話をしていて、ほぼそれだけのためにgemを作りました。 joker1007/web-console-rake Gemfileに書いておくだけで、web-consoleのreplでrake(taskname)というメソッドが使えるようになります。 オプションを渡せばspringにも対応します。 rake "spec"とかやればテストも流せます。(意味は余りない) 中身はめちゃくちゃダーティハックな感じで、ちょっと面白かったw
RubyとvimでQuick JUnit風にテスト実行 - Qiita
Java & Eclipseの開発環境には、Quick JUnitというテストを迅速に実行するプラグインがあります。 Ruby & vimの開発環境においても、ほぼ同等の事が実施可能です。 以前、私のブログで、プロダクションコードとテストコードを素早く切り替えるテクニック、 vimから即座にRSpecを実行し、結果をバッファに表示するテクニックを紹介しました。 詳細は、以下を参照してみてください。 RubyでTDDをやる際に、ちょっと便利になるVimの設定 - joker1007の日記 rspecをvim-quickrunから非同期で実行する - joker1007の日記 今回は、そこから一歩進めて、特定のテストケースだけをvim-quickrunから実行する設定を紹介します。 そもそもrspecには -l オプションを付けることで、特定の行だけテストを実施してくれる機能があります。 指定
本番機などで外部と余計な通信をしたくない時にbundlerを使う場合 - Qiita
privateなgithubリポジトリのgemを参照していたのだが、本番機に余計な秘密鍵を置きたくなかったので、 スマートにローカルから参照する方法を調べてみたところ、 bundlerの1.2.0からbundle package --allというものが使えるようになっていて、 gitのリポジトリやpathで参照しているgemもまとめてvendor/cacheにパッケージングしてくれるようになった。 つまり、こんな感じ。 # CIサーバー等 bundle package --all ## capistranoのcopy方式等で本番機側にアプリケーションをデプロイする。 ## capistranoのレシピ上で、以下の形でbundlerを実行させるようにする。 bundle install --deployment これで、vendor/cacheに入ってるgemを参照して、そこからインストール
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
rails_adminをカスタマイズする方法まとめ - Qiita