2012年8月31日金曜日

Twitter BootstrapでSticky Footerを作成する

Twitter Bootstrapで画面下部に固定するfooterを作成したのでメモ

環境

Twitter Bootstrapv2.0.4

IE7.0以上,opera,firefox,chorome等Twitter Bootstrapに対応しているブラウザ対応

Twitter Bootstrapは便利なツールなのですが、footerを画面下に配置するcssの設定が見当たらなかったので、実装しました。

footerの仕様

HTML画面の下部にfooterを表示する。
画面の表示量が少ない場合は、画面最下部にfooterを表示する。
画面の表示量が多い場合は、スクロールして画面最下部に到着してからfooterを表示する。

このようなフッタをSticky Footer(スティッキフッタ)と呼びます

html


<!DOCTYPE html> 
<html lang="ja"> 
  <head> 
    <meta charset="utf-8"> 
    <title> ProjectName</title> 

    <!-- Le styles --> 
    <link href="./develop/css/bootstrap.css" rel="stylesheet"> 
    <link href="./css/common.css" rel="stylesheet"> 
    <link href="./develop/css/bootstrap-responsive.css" rel="stylesheet"> 
  </head> 
<body> 
  <div class="wrapper"> 
    <div class="navbar navbar-fixed-top"> 
      <div class="navbar-inner"> 
        <div class="container-fluid"> 
          <a class="brand" href="#"> <span class="header_title"> ProjectName</span> </a> 
        </div> 
      </div> 
    </div> 
    
    <div class="container top_start_point"> 
      test!!
      <div id="push"><!--//--></div>
    </div> <!--/.container--> 
  </div> <!--/.wrapper--> 
  <footer> 
      footer content
  </footer> 
  <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"> </script> 
  <script src="./develop/js/bootstrap.js"> </script> 
</body> 
<</html>

divで囲むwrapperクラスを用意します。これはbodyタグのfooterタグ以外を囲むタグです。
footerタグをdivで囲むwrapperクラスの外に設定します。

CSS

上記のhtmlで指定したcommon.cssの内容です。


html {
  height: 100%;
}

body {
  height: 100%;
}

.wrapper {
  min-height: 100%;
  height: auto !important;
  height: 100%;
  margin: 0 auto -2.3em;
}

footer {
  height: 2.3em;
}

.push {
  height: 2.3em;
}

.top_start_point {
  padding-top: 60px;
}

wrapperクラス内のmin-heightは領域の高さの最小値を設定します。
marginのautoはセンタリングを設定します(margin 上マージン auto　下マージン)
footerタグをdivのwrapperクラスの外に設定します。

top_start_pointクラスは画面の内容が開始する位置を指定しています。
ヘッダーを使用する場合に必要になるので注意してください。

私はTwitter Bootstrapを使うのは、まだ次期尚早かなと思うのですが、個人開発者はもう使ってのもよい段階に入っていると思います。
私も自分のWEBアプリをTwitter Bootstrapに差し替えるつもりです。(完了したら報告します)

個人実装で全てのブラウザに対応するのは苦しいので、Twitter Bootstrapのようなcssフレームワークは今後はやると思います。

でわ

参考サイト

この記事がお役にたちましたらシェアをお願いします

2012年8月28日火曜日

遺伝子治療革命の感想とゲノム時代の到来

これからはゲノムの時代だとよく言われています。しかし、実際ゲノムについて知識のある人はほとんどいないのが現状です。
近い未来、現代のIT技術のようにゲノム技術が当然のように利用されるのは間違いありません。
そんなゲノムの現在と簡単な知識を得るのに適した本が以下の本です。

基本的なゲノムの知識は、現在のパソコン知識のように普通の人も必要となる時代になるでしょう。
遺伝子スクーリニングから取得したゲノム情報からゲノム検索し、医療対策を行う時代は必ずやってきます。
上記の本はとってもわかりやすく記述されているので、知っておいた方が良いと思った基礎知識は学生時代のように丸暗記してしまうのがお薦めです。
私はルーズリーフで重要な箇所を抜き出して丸暗記しました。おかけで、wired等のゲノム関連の記事がとっても読みやすくなりました。

さて、パーソナルなゲノム治療が定着するのは、日本では欧米より時間がかかるような気がします。
まずは、自分のリスクを知りたいかという問題があります。
普通の人より発症リスクが高い病気にどう向き合うのか。また、介入予防措置ができない病気(アルツハイマー等)の発症リスクが高いと分かった場合にどう向き合うのか。自暴自棄にならないか。さらには、保険料の値上げや加入の拒否も考えられます。
日本人は人からどう見られるかというのを異常に気にするのでこのへんは揉めるのではないでしょうか。

だだし、病気の発症前に予防するチャンスが生まれるのも事実です。
リスクはコントロールできれば最大の武器となります。この辺はスポーツやビジネスと同じですね。

あと、DNAのリスク予測の現在のデータは北ヨーロッパ出身者を対象とした研究です。日本人のデータも沢山蓄積して欲しいところですが、嫌がる人が多いでしょうからデータの収集に苦労するような気もします。

とはいえ、未来は出生時に強制的に遺伝子スクーリニングを行うことになるでしょう。
ゲノム時代を迎えると、さらにソフトウェアの技術が重要となりそうです。
ゲノムは、プログラマーにとっても興味深い技術だと思うので、是非勉強してみてください。
将来、ゲノムに関わって巨万の富を得るプログラマーが出てくると思います。

この記事がお役にたちましたらシェアをお願いします

2012年8月21日火曜日

Get data Like a twitter scroll on Ruby on Rails3

Environment

ruby-1.9.3-p0, rails3.2.2, postgres

Grade

normal

I created a mechanism that Application get data like a twitter scroll.
In case of Rails 3, you should use jquery.pageless. This is help you to create Endless Page Scrolling.

If you search Endless Page Scrolling way on Internet, you find Endless Page on rails cast or Endless Page Scrolling with Rails 3 and jQuery.
But, you should avoid using these ways.
Because "Endless Page" article does not support jquery on rails3. If you use rails2.x, this way is very good.
"Endless Page Scrolling with Rails 3 and jQuery" article is not simple. This code is complicated.

how to use jquery.pageless

Download jquery.pageless file. set some files on your application. you have only to imitate sample.
But, if will_paginate gem does not exist, this tools does not work.
jquery.pageless need will_paginate gem.

how to change loading view

If you use jquery.pageless, you are able to create view like a twitter scroll. but I think you want to change load view.
At that case, you should change part of jquery.pageless.


  var loaderHtml = function () {
    return settings.loaderHtml || '\
<div id="pageless-loader" style="display:none;text-align:center;width:100%;">\
  <div class="msg" style="color:#000000;font-size:1.1em"></div>\
  <img src="' + settings.loaderImage + '" alt="loading more results" style="margin:10px auto" />\
</div>';
  };

you can change here font size, color, load view.

This is very useful. I will recommend.

Thanks for reading. bye!

helping site

jquery.pageless.js

この記事がお役にたちましたらシェアをお願いします

Ruby on Rails3でtwitter風データロード

twitter風のデータロード画面を作成したのでメモ。

環境はruby-1.9.3-p0, rails3.2.2, postgresです。

難易度★★★☆☆

twitterのように画面をスクロールしてデータをローディングする仕組みを作りました。
結論を言うと、Rails3の場合はjquery.pagelessを使うと簡単に作ることができます。

しかし、ネットで検索するとrails castのEndless PageやEndless Page Scrolling with Rails 3 and jQueryばかりがHITすると思います。
しかし、これらを使うのは避けてください。
まず、rails castのEndless Pageの記事内容はrails3のjqueryには対応していません。rails2.xならこちらで良いでしょう。
Endless Page Scrolling with Rails 3 and jQueryの記事内容はシンプルでなく、おせじにも良いコーディングとは言えません。

jquery.pagelessの使い方

ダウンロードして、サンプルと同じようにファイルを配置するだけでOKです。
注意する点として、will_paginateがないと動作しないのでgemにwill_paginateも必ず設定してください。

loading表示の変更

あっさりとtwitter風のロード画面が作成できると思いますが、ロードの表示方法は変更したいと思うでしょう。
その時は、jquery.pageless.jsの以下の部分を変更します。


  var loaderHtml = function () {
    return settings.loaderHtml || '\
<div id="pageless-loader" style="display:none;text-align:center;width:100%;">\
  <div class="msg" style="color:#000000;font-size:1.1em"></div>\
  <img src="' + settings.loaderImage + '" alt="loading more results" style="margin:10px auto" />\
</div>';
  };

文字のサイズ、色、ローディング画像はここで変更できます。

本当に便利なツールなので、是非使ってみてください。
ページングのほうが使いやすいページは、通常のwill_paginateもを利用すると良いでしょう。

以上です。

参考サイト

jquery.pageless.js

この記事がお役にたちましたらシェアをお願いします

2012年8月19日日曜日

Herokuのwebサーバをthinに変更する

Ruby on Rails3で作成したアプリをHeroku上でthinを利用して動作させるためのまとめです。

環境はruby-1.9.3-p0, rails3.2.2, postgres, Herokuです。

難易度★★★★☆

thinに変更したほうが良い理由

Heroku上のrailsアプリは、デフォルトだとWebrickが動いています。
Webrickはデフォルトで使われるWEBサーバーですが、パフォーマンスがかなり悪いです。
Herokuでも実運用ではthinを使うように推奨しています。
thinはコンパクトでWEBrickよりも速く技術的にも枯れていて、普通のWEBサイトであれば十分な性能をもっています。

フリー(無料)で変更できるの？

現在(2012/8月)確認した限りは無料で変更できます。add-onと異なりクレジットカードの登録をしていなくても大丈夫です。

利用しているWEBサーバーを調べる

Heroku上のrailsアプリは、デフォルトだとWebrickが動作しているはずです。
herokuにログインしてコマンドで確認してみましょう。


heroku ps

以下が結果です。


Process  State       Command
-------  ----------  ---------------------------------
web.1    up for 45m  bundle exec rails server -p $PORT

上記表示の「bundle exec rails server -p $PORT」の場合はWebrickが動作していることを示しています。

アプリのGemfileにthinを設定

さっそくthinを導入しましょう。アプリのフォルダに移動します。


vi Gemfile

gem 'thin'

bundle install

installに成功したら、ローカルでthinサーバーの動作を確認すると良いでしょう。
ローカルで動かす場合はrails server thinでthinを起動することができます。

Procfile（プロックファイル）を変更する

HerokuでWebrickをthinに変更するには、Procfileを変更する必要があります。
Procfileには、アプリケーションで動かすプロセスタイプのリストを記述します。
プロセスタイプには、web, worker, urgentworker, clock等があります。
先ほどのWebrickのプロセスはwebプロセスになります。


Process  State       Command
-------  ----------  ---------------------------------
web.1    up for 45m  bundle exec rails server -p $PORT

foremanを導入

Procfileの変更は、foremanというgemを利用して確認します。
この情報はかなり少なかったので苦労しました(Heroku使っている人はWebrickのままなのかな？)
これは、HerokuのDavid Dollar氏が作成したgemで、Herokuでも採用されています。
このforemanは依存するバックグラウンドプロセスを簡単に管理できます。
それでは、アプリに導入しましょう。


vi Gemfile

gem 'foreman'

bundle install

installに成功したらProcfileを作成します。


vi Procfile

以下の行を追加します。


web: bundle exec rails server thin -p $PORT -e $RACK_ENV

Procfileが完成したら、内容が正当かどうかをforeman checkコマンドを実行してチェックします。


foreman check

valid procfile detected (web)

上記のメッセージが出れば正常です。$RACK_ENVをセットするファイルを作成します。


echo "RACK_ENV=development" >>.env

準備完了です。プロセスを起動します。


foreman start

06:10:13 web.1  | started with pid 2027
06:11:50 web.1  | => Booting Thin
06:11:50 web.1  | => Rails 3.2.2 application starting in development on http://0.0.0.0:5000
06:11:50 web.1  | => Call with -d to detach
06:11:50 web.1  | => Ctrl-C to shutdown server
06:11:50 web.1  | >> Thin web server (v1.4.1 codename Chromeo)
06:11:50 web.1  | >> Maximum connections set to 1024
06:11:50 web.1  | >> Listening on 0.0.0.0:5000, CTRL+C to stop
06:11:50 web.1  | >> Stopping ...
06:11:50 web.1  | >> Stopping ...
06:11:50 web.1  | Exiting
06:11:50 web.1  | exited with code 0

OKですね。ローカルでアプリの動きを確認する場合はportを5000にして接続します。

コミット

確認を終えたら、上記の変更をgitでコミットします。
このとき.envファイルはgitで記録しないようにします。

heroku更新

あとはいつもと同じgit push heroku masterでherokuを更新します。

thinで動作していることを確認


heroku ps

Process  State       Command
-------  ----------  ------------------------------------
web.1    up for 43s  bundle exec rails server thin -p $..

Commandがbundle exec rails server thinになっています。
thinでアプリが動作しているのが確認できますね。
変更後は動きを確認してみると良いでしょう。Webrickよりサクサクと動くはずです。

今回はちょっと長くなりましたね。お疲れさまでした。
以上です。

参考サイト

この記事がお役にたちましたらシェアをお願いします

2012年8月17日金曜日

NYヤンキース黒田投手の思考とプログラマの思考

NYヤンキースで活躍している黒田選手の記事でとても良い記事があったので紹介します。

記事の内容は、松坂大輔選手やダルビッシュ有選手など、メジャーに来て制球に苦しむ日本人投手が多い中で、なぜ黒田選手が安定した投球を続けられるかについてです。

「こんなものかなと思ってやるしかないですからね。日本で投げていたイメージなんて追い求めていたら、こっちではやっていられない。ボールの違いや中４日の環境にしてもそう。その環境は変わらないんですから、気にしても仕方ない。こっちでも安定しているボールもあれば、まったく使いものにならないボールもある。その中で自分がどうやっていくか。頭を切り替えてやっていくしかない」

「こんなところでやっていけるのかと思うほど、１年目のキャンプは困ったことだらけでした。何もかもすべてでした。でも僕らは無理やりここに連れて来られたわけじゃない。自分で決めてここに来たんです。ボールの違い、中４日での登板、トレーニング環境の違い、すべてを理解した上で『腹をくくって』ここに来たんです。だから、環境の違いを気にすることは趣旨が違うと思っていました。日本と同じ感覚で投げられていないのは確かです。でも、それは求めるものではないと思います」

自分の能力を高めて異なる環境に挑戦していくのではなく、異なる環境に合わせて自分の能力を高めていく。
グローバル化(アメリカ化)で最も大切な考え方を黒田選手はもっていて、さらに実現できています。

IT系のスタートアップでよく利用されるWEBフレームワークにRuby on Railsというツールがあります。このフレームワークの設計哲学は以下の二つです。

DRY(Don't Repeat Yourself)=同じ記述を繰り返さない
CoC(Convention over Configuration)=設定よりも規約

railsでWEBアプリを作る場合、フレームワークに合わせた仕様にすればするほど素晴らしく高い生産性を発揮することができます。「ああしたい」「こうしたい」とフレームワークの制約を外れれば外れるほど生産性は落ちます。

railsがスピード重視のスタートアップで使われ、顧客の要求が多い受注で利用されないのはこういった理由からです。

railsに限らず、iphoneやandroid等のアプリ開発でもプラットフォームの標準ルールに沿って作ると使いやすい物になります。

標準化された環境を受け入れ、その中でどうするかというのはとても重要なのです。

黒田選手はメジャーという環境を受け入れ、メジャーで力を出せる投球術を身につけたのでしょう。もしかしたらその投球術は日本では通用しないかもしれません。

ITの世界でも色々と便利なツールが作成されています。利用していると「ここはこうするべきだろ」「わかってねえな」と思うことがしばしばあります。
しかし、自分の思い込みで変更してしまうより、標準化されたものをそのまま利用することで最新技術の導入や後々のバグの対応が楽になります。
制約のある中で対応していくのも立派な技術です。

定期的に自分がおかれている状況と環境を考える習慣は身につけておきたいと思わされた良い記事でした。

「日本人投手がメジャーで生き抜くために必要な哲学」
黒田博樹の成功と松坂大輔の蹉跌

この記事がお役にたちましたらシェアをお願いします

2012年8月15日水曜日

WEBアプリやスマートフォンアプリを量産し思ふこと

ここ2,3年でWEB,スマホアプリを量産して思ったことの一つは、基本の理解と暗記の大切さです。

開発は時間に追われます。最初に引いたスケジュールとリリース日は第三者の「願望」であり、計画通りに進むことはまずありません。
仕様の追加や変更は当たり前、計画通りに進めるというよりは帳尻を合わせるといったほうが適切でしょう。プロジェクトは常に不安定です。

そんな忙しい日々が続くと、成果(アウトプット)とリリース日のみに気を取られ、自分の能力を高めることを忘れがちになります。
もちろんあなたが企業の従業員であるならアウトプットは最も重視しないといけません。
しかし同時に、「理解する」「暗記する」という作業は怠らないようにしないといけません。特に「暗記する」ことは大切です。

進捗に追われると今後につながる重要な調べ物を「理解した」だけで終わらせてしまうことが少なくありません。でも、「理解した」つもりでも人はすぐに忘れてしまいます。
大切なことは「暗記」して血肉にしないといけません。「暗記」は「理解」のベースになります。できる人というのは「理解」と「暗記」のバランスが抜群なのです。

今のアプリ作成はフームワークとモジュールを組み合わせることが一般的です。
例えばログイン処理を実装する場合、railsではdeviseを利用するのが一般的です。
しかし、deviseを使わず自分でゼロから実装し、ログインの仕組みを理解し、処理の考え方を暗記することはとても大切です。
ログイン処理一つでも、CSRF,SQLインジェクション,メッセージダイジェストとソルトを利用したパスワード処理等を学べます。
基本の知識を身につけると、他の言語での開発はもちろん、その他の技術の理解にも役立ちます。

最近の技術の進歩と速度は素晴らしいです。
だからこそ、きちんとした基礎を積み上げることが理解を助け、良い成果を出すことに繋がります。
なので開発者は、少しの時間でよいので、基礎を勉強する時間を捻出すると良いと思います。

この記事がお役にたちましたらシェアをお願いします

2012年8月11日土曜日

Ruby on Rails3で作成したアプリのセキュリティチェックその2 HTTPヘッダインジェクション

Ruby on Rails3で作成したアプリのテスト時にチェックするセキュリティについてのまとめです。

環境はruby-1.9.3-p0, rails3.2.2, postgresです。

難易度★★☆☆☆

HTTPヘッダインジェクション

リダイレクトやクッキー発行など、外部からのパラメーターを元にHTTPレスポンスヘッダを出力する際に発生する脆弱性です。
クッキー発行はガラケーの開発以外では関係ないことがほとんどなのでここでは説明しません。
HTTPヘッダインジェクションが発生するのは、リダイレクト時の処理が一番多いでしょう。

パラメーターからurlを取得してリダイレクト

パラメーターからurlを取得する場合に、HTTPヘッダインジェクションの発生に注意する必要があります。

parameter


http://www.yourapplication.com/controller/action?referer=path/at/your/app%0d%0aLocation:+http://www.malicious.tld

上記は?以降にクエリパラメーターを設定しています。%0d%0aは改行のパーセントエンコードです。

code


redirect_to params[:referer]

結論から言うと、railsの場合は上記のようなコードでもHTTPヘッダインジェクションは発生しません。フレームワーク側で対策がしてあります。
railsの開発ではHTTPヘッダインジェクションを意識するケースはあまりないと思います。

HTTPヘッダインジェクションが発生する原因

HTTPヘッダインジェクションは、レスポンスヘッダの改行には特別な意味があるのに、外部から指定された改行コードをそのまま出力するのが問題となります。
parameterの例の場合は後半のURLがLocationに設定されます。つまり、後半のURLページにリダイレクト遷移されてしまいます。
例えば、後半のurlに悪意の第三者が罠のページを仕込むと、利用ユーザーはそちらの罠ページに遷移してしまいます。その罠ページでパスワードやログインIDを入力させることもできます。

urlは仕様として改行文字を使うことができません。なので、本体urlには改行チェックをおこなわないといけません。
しかし、自分で実装して改行をチェックするより、ライブラリを用いて処理するのがもっとも安全です。

railsのredirect_toはHTTPヘッダインジェクションに対応されています。

自分で実装するのを控えるのがHTTPヘッダインジェクションセキュリティ対策の基本です。

参考サイト

参考書籍

この記事がお役にたちましたらシェアをお願いします

2012年8月10日金曜日

Ruby on Rails3で作成したアプリのセキュリティチェックその1

Ruby on Rails3で作成したアプリのセキュリティチェックのまとめ記事その1。

環境はruby-1.9.3-p0, rails3.2.2, postgresです。

難易度★★★☆☆

SQLインジェクション

SQLインジェクションは、パラメーターとして指定された文字列の一部がリテラルをはみ出すことにより、SQL文が変更されることです。

SQLインジェクション対策

静的(動的)プレースホルダを利用してSQLを呼び出す

例:ログイン

メールアドレスとパスワードでログインするアプリの場合を考える

1.インジェクションサンプル

入力値


mail: test@co.jp(正しいメールアドレス)　

password: '' or 'a' = 'a'

ログインコード


Users.where("mail = " + params[:mail] + " and password =" + params[:password])
↓
select * from users where mail = test@co.jp and password = '' or 'a' = 'a'

上記のようなログイン処理の場合、パスワードを知らない悪意のあるユーザーがログインできてしまいます。
SQLインジェクションの原因は、パラメーターとして指定した文字列の一部がリテラルをはみだすことでSQL文の文字構造が変化してしまうことにあります。(そもそも上記のようなログイン処理を実装してはいけません)
SQLインジェクションの対策方法は、プレースホルダを利用することです。

ログインコード改良


×Users.where("mail = " + params[:mail] + " and password =" + params[:password])

○Users.where("mail = ? and password = ?", params[:mail], params[:password])

もしくは

◎Users.where(:mail => params[:mail], :password => params[:password])

Hashを使ったコードの方が個人的には読みやすいと思います。

以上です。

参考書籍

この記事がお役にたちましたらシェアをお願いします

2012年8月8日水曜日

WEBサービス【Neighbor】公開

新しいWEBサービスを公開しました。
その名も

Neighbor

です。

Neighborは地域で繋がるコミュニティSNSです。

地元の遊び場、デートスポットの紹介
住環境に関する質問やトーク
医療施設などについてのぶっちゃけトーク

のようなことに利用すると便利だと思います。

また、twitter, yahoo, googleアカウントがある人はより簡単に登録できます。

他にも色々と素早く対応していきたいと思います。
よろしくお願いします。

この記事がお役にたちましたらシェアをお願いします

2012年8月3日金曜日

Herokuのエラー処理

Ruby on Rails3で作成したアプリをHeroku上で動かす際のエラー処理についてのまとめです。

環境はruby-1.9.3-p0, rails3.2.2, postgres, Herokuです。

難易度★★★☆☆

はじめに

この記事はHeroku上で動くアプリのエラーをどう扱うかを試行錯誤したまとめです。正直、あまり良い方法とは思えなかったのですが、現在は記事の内容で対応しています。

対応方法

アプリに例外が発生したらエラーのメールを投げることでエラーを管理者が確認できるようにしました。
exceptional_notificationというpluginが例外を自動キャッチしてメールを投げてくれるのですが、私のアプリは独自処理で例外をキャッチしていたのでexceptional_notificationを使用できませんでした。なので、自分で実装することになりました。

詳細

Heroku

Herokuは，Ruby on Rails/RubyのWebサービスのホスティングサービスです。無料で手軽にWEBサービスを構築することができ、アプリケーションの負荷が高くなれば有料にすることもできます。
小さくはじめるスタートアップに非常に向いているサービスです。

Herokuログ

Herokuのlogはターミナルから「heroku logs」で確認できます。logの内容はproduction.logです。

Herokuログの問題点

log rotateができません。なのにアプリが動作している限りログは追記されていくので、後でエラーの原因を調査しようと思っても、ログを追うことができません。

エラー処理仕様

例外はキャッチして独自のエラーページを使用する。しかし、例外を独自処理でキャッチした場合exceptional_notificationは使えない。
exceptional_notificationのようにエラー発生時にメールを送りたい。でも、独自で例外を補足したい。
有料のadd-onやサービスは利用したくない。なるべく無料が良い。
無料のheroku logsだけでは不安である。エラーは発生時に知りたい。

我がまま過ぎるって？でも、そんなもんです人間は。金がないなら知識と技術で解決しましょう。さあ実装です。

Gmailを使う

エラーメッセージのお知らせにはgmailを利用します。無料で一日500件まで使えます。500件以上利用する場合は、あきらめてメールサーバーを立てるか有料サービスを使いましょう。サービス立ち上げ時には十分な件数のはずです。

/config/environments/production.rbに設定を記載します。


  config.action_mailer.default_url_options = { :host => 'your_app.heroku.com' }
  config.action_mailer.delivery_method = :smtp
  config.action_mailer.smtp_settings = {
    :address => 'smtp.gmail.com',
    :port => 587,
    :domain => 'your.host.name', # if local,  localhost.localdomain    
    :user_name => "your_username", # full email address (user@your.host.name.com)
    :password => "your_password",
    :authentication => 'plain',
    :enable_starttls_auto => true,
  }

開発環境でも利用したい場合は/config/environments/development.rbにコピーしてください。
GmailでIMAPが利用できるように設定されていることも確認してください。
GmailでIMAPを有効化にする

mailerを作成


  rails g mailer TestMailer sendmail_confirm

メーラーを作成します。作成されたコントローラー/app/mailers/test_mailer.rbに処理を記述します。


class TestMailer < ActionMailer::Base
  default :from => 'full email address'

  # Subject can be set in your I18n file at config/locales/en.yml
  # with the following lookup:
  #
  #   en.notice_mailer.sendmail_confirm.subject
  #
  def sendmail_confirm(exception)
    @exception = exception
    mail :to => "send_email_address", :subject => '[Web application Error]'
  end
end

sendmail_confirmアクションは引数で例外を受け取っています。
mailメソッドを呼び出すタイミングで、テンプレートtest_mailer/sendmail_confirm.text.erbが呼び出されます。
text.erbには、メールの内容を記述します。

text.erbを作成


エラーが発生しました、

<%= @exception.message %>

エラーの内容を出力するようにしています。他にも欲しい情報があれば、ここに記述します。

独自エラー処理に追加

独自エラー処理はapplication_controller.rbで処理するのが一般的です。なので、ここに作成したメール処理を追加します。


  # 例外ハンドル
  # ルーティングエラーと、データが見つからない場合は404エラー扱い
  rescue_from ActionController::RoutingError, ActiveRecord::RecordNotFound, :with => :render_404
  rescue_from Exception, :with => :render_500

  # 404エラーはログを取りエラー画面を表示
  def render_404(exception = nil)
    if exception
      logger.info "Rendering 404 with exception: #{exception.message}"
    end

    flash[:msg] = 'ページは見つかりませんでした。'
    render 'shared/error' , :status => 404
  end

  # 500エラーはログを取りエラー画面を表示
  def render_500(exception = nil)
    if exception
      NoticeMailer.sendmail_confirm(exception).deliver 
    end

    flash[:msg] = 'サーバーエラーが発生しました。'
    render 'shared/error', :status => 500 # statusがないとcompleted OKになってしまう。
  end

赤い太文字の箇所が追加した処理です。メールでエラーを投げて、独自のエラー画面に遷移するようにしています。

ユーザーは大きな不具合以外は意外と報告してくれないので、メールでエラーが送信される仕組みはあると便利だと思います。

以上です。

参考サイト