Rails で 先般 クライアント から 基本のデータを Excel で入れられるようにしてほしい という依頼がありました。 編集を行うデータだったら編集画面を作って DB で管理したほうがいいことを伝えましたが、 どうしても Excel がいいそうで。 Excel は必要以上に多機能で、すべてのデータをそのままデータベースに反映するのが難しそうであることから止めておいた方がいいと伝えて、 Excel との インポート・エクスポート が容易な TSV で対応することとなりました。 そのときの方法を書いておきます。
TSV は 内容をコピーしてそのまま表計算ソフトに貼り付けることもできますし、表計算ソフトから TSV に貼り付けることもできるので、 Excel でも扱いやすいです。 データが欠損することがあるので、その点で注意が必要です。
環境
- Ubuntu 14.04 LTS
- Rails 4.1.8
- Ruby 2.2.2
方針
- TSV 取り込みの機能を task で作り、
rake コマンド で取りこめるようにする。
rake db:seed を行ったときに、 TSV を読み込むタスクを実行するようにする。
続きを読む Rails 4 : TSV から seed データ を入れる →
Rails で、エラーが出たときにメールが送信されるようにしました。
環境
- Ubuntu 15.05 (64bit)
- Ruby 2.2.2
- Rails 4.1.8
昔のやり方
Rails 3 のときは、 ApplicationController で rescue_in_public にメール送信のコードを見たことがあります。
|
|
class ApplicationController < ActionController::Base protected def rescue_action_in_public(exception) SystemMailer.system_error( current_user, self, request, exception).deliver super(exception) end def local_request? false end end |
current_user は ログインしているユーザです。 devise を利用しています。
しかし同じことをやっても意図した通りにメールは送信されませんでした。
解決法
Rails 3 のときにもあった rescue_from を使いました。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
class ApplicationController < ActionController::Base rescue_from Exception, :handle_exception private # handle exception # ==== Parameter # * +exception+ def handle_exception(exception) send_error_mail(exception) raise exception end # send error mail # ==== Parameter # * +exception+ def send_error_mail(exception) if !Rails.env.development? SystemMailer.error_mail( exception, current_user, self, request) end end end |
rescue_from Exception とすることで、コントローラ内の処理で発生したすべての例外を拾います。 これが rescue_from StandardError だと 単純に raise "exception!" のように例外を起こしたときの RuntimeError が拾えません。 また、0 = 1 の時に起きるような syntax error は拾いません。 拾うのはプログラムとして動いた上でのエラーです。 そして、コントローラに入る前の処理は拾いません。
重要なのは handle_exception の中の raise exception です。 handle_exception ではエラーをもみ消したいわけではなく、メールを送りたいだけです。 AOP の考え方です。 今回は簡易的に application_controller.rb にメソッドを追加しています。
send_error_mail の中で使われている current_user は gem devise で用意されているもので、ログインしているユーザを返します。 適宜変更してください。 self はどのコントローラで例外が発生したのかをメールに載せるために渡しています。 request はリクエストのURLなどを表示するのに使います。 また !Rails.env.development? で評価を行っているところがありますが、 config に書くようにできれば一番いいです。 Rails 4.2 になったらカスタムコンフィギュレーションが使えるそうなので、アップグレード後の課題としました。
注意点
コントローラに入った後の例外しか処理しないので、 コントローラに移る前の例外は別の方法で補足する必要があります。
それならばコントローラの中ではなく外側で例外処理を書けばいいという考え方もあるのですが、コントローラの中でしか参照できない値や、コントローラの中で使いやすくなっているオブジェクトなどがあるので、 applicatoin_controller.rb に処理を書きました。
続きを読む Rails 4 メールでのエラー通知 →
Rails でシンプルにログローテーションする方法です。
環境
- Rails 4.1.8
- Ruby 2.2.2
- Ubuntu 15.04 (64bit)
設定
Rails の config/application.rb に次の記述を追加します。
|
|
# configure log rotation # split log by 100MB, limit log file count up to 10 config.logger = Logger.new( "#{Rails.root}/log/#{Rails.env}.log", 10, 104857600) |
ここでは 100 MB (104,857,600 バイト) で 最大 10 ファイル まで保存するようにしています。 要するに 1 GB までログを保存する。 また、 10 ファイル を超えると、古いものから削除されていきます。
Rails の標準では daily, weekly などのログの設定方法もありますが、その場合は古いログファイルは削除されません。
テスト方法
例えば development 環境 でテストする場合、 次のコマンドで 100 MB を超えるログファイルをあらかじめ作成しておく。
|
|
dd if=/dev/zero of=log/development.log bs=1M count=100 |
bsはブロックサイズ、countは書き込み回数を表しています。
そこで、 rails s のコマンドでサーバを起動して、 どこかのページにアクセスします。 すると、 development.log, development.log.0 ができているはずです。
Rails のロギングは、 SyslogLogger や Linux の logrotate を使う方法もあります。
Magnum CI は 無料で使える CI 環境で、 きっと愛用している人も多いと思います。 本記事では、 Bitbucket で管理している Rails のコードを、 Magnum CI でテストした時のメモを書いておきます。
続きを読む Magnum CI で Rails をテストした方法 →
中編に続いて処理内容を見ていきます。 webroot/index.php に残されたのは次の4行でした。
続きを読む CakePHP 3 コントローラ実行までのプロセスを追う 後編 →
A Life Summary of an Gypsy
