開発しやすい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.
Bigquery上で実行するバッチ処理のテストコードを書く (Ruby編) - Qiita
bigquery上でデータを加工して集計する時、このSQLが本当に合ってんのかテストコードで検証したくなる。 しかし、こういう外部サービスを使った処理のテストコードを書くのはとても面倒臭い。 とはいえ、書かんわけにもいかんし、実際に動かしてみないと分からないこともあるので、実際にbigqueryで処理を実行してテストする方法をまとめてみる。 テストデータのロード bigqueryにデータを突っ込む方法はバルクロードするかStreaming Insertの二つ。 しかし、バルクロードはテストコードを書く時に困るのが、データ量に関わらず処理に一定時間かかること。 どれだけ小さいデータでも最低1分前後は待たされる上に、時々謎の刺さり方をして最悪数分かかる場合がある。 一方でStreaming Insertはまずテーブルを作っておかなければいけないし、Streaming Insertのレスポンスが
Real World Refinements - Qiita
Ruby AdventCalendarの最終日です。 締切をオーバーしました……。orz Refinementsの使い道が無いとか、使ったことがないという人が結構居るみたいなので、いくつかのユースケースを紹介しようと思います。 テストコードのDSL 一つはrspec-parameterized。 # Table Syntax Style (like Groovy spock) # Need ruby-2.1 or later describe "plus" do using RSpec::Parameterized::TableSyntax where(:a, :b, :answer) do 1 | 2 | 3 5 | 8 | 13 0 | 0 | 0 end with_them do it "should do additions" do expect(a + b).to eq answ
そろそろポリモーフィック関連について一言いっとくか - Qiita
class Notification < ActiveRecord::Base belongs_to :notifiable, polymorphic: true end class Message < ActiveRecord::Base has_one :notification, as: :notifiable end class Like < ActiveRecord::Base has_one :notification, as: :notifiable end 一行で色んなクラスに対する関連が指定できて便利感がある。 だからって、これを安易に使う前にちゃんと考えよう。 ポリモーフィック関連は単に関連の定義を省力化するためのものじゃない。 ポリモーフィックという名前が示す様に、これは多態性を持ったものに対する関連を定義する事であって、インターフェースに対する関連の定義だということ
ActiveRecordの読み込みが実際にトリガーされた場所をログに記録するgem - Qiita
ActiveRecordは必要になるまでDB読み込みをしません。 なのでやたら複雑なビューの中でクエリを弄ったり、コントローラーが肥大化してる状態でひどいSQLがログに流れてくると、パっと見ではどこが原因なのかすぐに分からない。 なので、SQLが実行された時にそれが実際にトリガーされたソースコードの位置も一緒にログに吐いてくれるgemを作りました。 bulletで分からないような、ビューのループの中で直接モデル読んでるみたいなヤバイ箇所を速やかに見つけるためのものです。 joker1007/activerecord-cause 仕組み的にはActiveRecordのロギングの仕組みを丸パクリしてcaller_locationsを足した感じ。 全ての読み込み位置を表示するわけではなく正規表現でマッチするパスを持ったソースコードの位置のみをログに記録します。 Railsで利用する場合は自動的に
Sprockets再考 モダンなJSのエコシステムとRailsのより良い関係を探す - Qiita
すいません。締切守れませんでした…。 やっぱ、java-jaの忘年会の翌日は辛い…。 はじめに Webシステムを開発していると切っても切れないのがJavaScriptです。 Railsはかなり早い時期からalt-JSや結合、minify等を組み込めるようにフレームワークにそれを取り入れてきました。 それを支えているのがRails3.1から導入されたsprocketsです。 それに伴なってJSのライブラリをどうやって管理するかという点について、独自の路線を取ることになりました。 JSのライブラリを同梱したgemパッケージにラップしてrubygemsとして管理する方法です。 ある程度は上手くいっていたし、今もその流れは続いているんですが、時々問題になることもあります。 例えばメンテナの対応時期がズレてて古いバージョンのままだったり、似たようなgemが乱立してややこしくなったり。(backbon
Railsをバージョンアップし続けるために必要なこと - Qiita
本当は、RubyWorld Conf辺りでこういう内容も交えてなんか話せればいいなあと思ってたんだけど、CFPに落ちたのでQiitaにポエムを書いてみました。 Railsはそれなりに学習コストはかかりますが、慣れてくるとデフォルトで便利なものが揃ってるしサードパーティライブラリも豊富で、未だに最も便利なWebアプリケーションフレームワークの一つだと思います。 なので、最近のスタートアップ界隈ではRailsで開発をスタートする、という話をよく耳にします。(個人の感想です) しかし、Railsは本体に新しい要素をガンガン取り入れてくるので、バージョンアップのサイクルはかなり早く、それに追従していくのはそれなりに大変です。 Railsで開発をする場合には、一旦レールに乗ったらプロダクトが死ぬまで走り続ける覚悟が必要です。(時速60km以下になったら爆発する) それを最初に理解しておかないと、あっ
RSpec3の新しいFormatter APIについて - Qiita
いよいよRSpec3時代が近付いてきました。 betaとかrcで新しいバージョンが出る度にハマり所を仕込んでくるので、そろそろ落ち着いて欲しい所です。 RSpec3は表記の変更だけでなくて内部実装をがっつりリファクタリングしてるため、Formatterの作りも結構変わっています。 カスタムFormatterを自分で作ってる人とかForkして改造する人以外にはあんまり関係無いかもしれませんが、一応どう変わったのか書いておきます。 (そもそもそういう人は自分でソース読むし……) Formatterの基本となるクラスはRSpec::Core::Formatters::BaseFormatterというクラスです。 これは2系でも3系でも変わってません。 RSpec3系で大きく変わったのは、Formatters.registerというメソッドを呼び出してFormatterクラスを登録しなければいけな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
