Ruby on Rails開発のインターン (Day 12)

こんにちは、皆さん!

今日は昨日直したばかりのHeroku上でTuneMyGCをテスト。これで問題が解決できるといいが...


  • トピック:
  1. Railsで404と500エラー時のレイアウトを編集する
  2. Herokuでメモリ使用量を確認する


  • 疑問:


  • 問題:


  • 学習した内容:
  1. 自分のエラーページを作る方法
  2. Heroku上でメモリ使用量を見る方法


  • 今後やってみたいこと:


  • リソース:
  1. Dynamic Rails Error Pages | mattbrictson.com


Railsで404と500エラー時のレイアウトを編集する

ウェブサイトを転々としているとたまに404または500エラーと書かれたページにたどり着くことがあるかと思う。デベロッパーなら、その時のレイアウトも構築したいもの。


最初にまず、エラーが発生したときにRailsの中では何が起きているか説明させてください。例えば、404エラーが発生したとしよう。そしたら、ウェブサイトは/404にリダイレクトしようとする。よって、Railsは'/404'がconfig/routes.rbの中にないか探し始める。つまり、僕たちがやるべきことはそのページを作り、config/routes.rbを編集し、そこに行かせればいいのだ。


では、実際の作業に移りましょう!
まず、下記のコマンドでエラーページを処理してくれるコントローラーを作りましょう。

$ rails generate controller errors not_found internal_server_error

次にすることはコントローラーの関数を書くこと。しかし、エラーを処理する際の関数は普通のと少し違う。

class ErrorsController < ApplicationController
  def not_found
    render(:status => 404)
  end

  def internal_server_error
    render(:status => 500)
  end
end

見ての通り、ステータスを明白にしなくてはいけない。これはこの2つのケースがデフォルトのステータスである'200'ではないので、しっかりコントローラーに伝える必要があるというからだ。
次に、コントローラーのポイントする場所を明示する。これはこれまでとそんなに変わらない。

match "/404", :to => "errors#not_found", :via => :all
match "/500", :to => "errors#internal_server_error", :via => :all

デフォルトでは、エラーページはpublic/フォルダーの中にある。そこに404.html500.html があるのが確認できることでしょう。
しかしながら、今は自分で設定したページに変更したいので、下記のラインをRailsconfig/application.rbファイルに追加して設定を変更しましょう!

# Application class
config.exceptions_app = self.routes

この設定の変更により、エラーが発生したとき、Railsはもともとのpublicフォルダーで探すのだが、見つからなかった場合、config/routes.rbで探すという設定を追加したことになる。

public/404.htmlpublic/500.htmlを削除する

これでエラーが発生したときに先ほど作成したページに行くようになる。つまり、404の時はapp/views/errors/not_found.html.erbを、500の時はapp/views/errors/internal_server_error.html.erbを表示するようになる。

  • Before:

f:id:Programming_Shop:20180728082938p:plain

  • After:

f:id:Programming_Shop:20180728083001p:plain

Herokuでメモリ使用量を確認する

ここまで、僕はずっとローカルでメモリの使用量を見てきた。けど、Heroku上でのメモリ使用はそれと違うから、そちらも確認したい。ここでは、どのようにHeroku上でのメモリ使用量を確認するかについて紹介する。


最初にHerokuでメモリ使用量をみれるように設定を変更する。ターミナルで下記のコマンドをたたくことで達成!

$ heroku labs:enable log-runtime-metrics

Herokuに反映させるために一度Herokuをリスタートさせる。

$ heroku restart

この後、Herokuのログをheroku logsで出すと、下記のようなメッセージが見られるでしょう。

2018-07-19T22:08:53.002898+00:00 heroku[web.1]: source=web.1 dyno=heroku.101841384.9d514caa-3366-4316-9647-fe2806ee7203
sample#memory_total=242.52MB sample#memory_rss=242.51MB sample#memory_cache=0.01MB sample#memory_swap=0.00MB 
sample#memory_pgpgin=62376pages sample#memory_pgpgout=291pages sample#memory_quota=512.00MB

この場合、僕はsample#memory_totalからわかる通り、242.52MBのメモリを使用していることになる。


また、heroku logs -tコマンドでライブでHerokuのログを確認することもできる。


もし、月に7ドル払うことで、Hobby dynosを使用することができ、おまけに下記のようにHeroku上のメモリ使用状況のグラフが見れる。
f:id:Coding_Studio:20180721025502p:plain

まとめ

今日は少し時間があったので、職場のルビーコードをより深く掘り下げてみた。それで学んだのがエラーページの処理の仕方を学んだ。明日は次に修正するマップを掘り下げていきたいなと思っているところ。


ご精読ありがとうございました。また次回まで✌





Day 11はこちら↓↓
programming-shop.hatenablog.com