rails console オススメのirb設定 ??
Ruby を学ぶためのツールとして、主にRailsコンソールを使っていくことにします。これは2.3.3で登場した、Railsアプリケーションを対話的に操作するためのコマンドラインツールです。Railsコンソールはirb (IRB: Interactive RuBy) を拡張して作られているため、Rubyの機能をすべて使うことができます (4.4.4でも説明しますが、RailsコンソールからRails環境にアクセスすることもできます)。
クラウドIDEをご利用の場合は、オススメのirbの設定があります。シンプルなテキストエディタ「nano」を使って、まずはホームディレクトリに「.irbrc」ファイルを作ってみましょう2。
$ nano ~/.irbrc
次に、リスト 4.8のような設定を書きます。この設定によりirbのプロンプトが簡潔な表示に置き換えられ、irbの邪魔な自動インデント機能がオフになります。
リスト 4.8: irbの設定ファイルを追加する~/.irbrc
最後に、Ctrl-Xと押してnanoエディタから離脱します。ファイルを保存するかどうか訊かれるので、yキーを押して~/.irbrcファイルを保存しましょう。
これで準備が整ったので、次のコマンドを実行して早速Railsコンソールを起動してみましょう。
開発中に動作がおかしくなった時
コラム 3.4. Unixのプロセス
LinuxやmacOSなどのUnix系システムでは、ユーザーやシステムが実行させている作業は「プロセス (process)」と呼ばれる、一種のコンテナの内部で実行されています。システム上で動いているすべてのプロセスは、psコマンドにauxオプションを付けて実行することで確認できます。
$ ps aux
プロセスの種類を指定してフィルタするには、psの結果をUnixの「パイプ」|でつないで、パターンマッチャーであるgrepに渡します。
$ ps aux | grep spring
ec2-user 12241 0.3 0.5 589960 178416 ? Ssl Sep20 1:46
spring app | sample_app | started 7 hours ago
表示結果の中で重要なのは最初の列の数値です。これはプロセスid、略してpidと呼ばれるものです。不要なプロセスを排除するには、killコマンドでpidを指定し、Unixのkillコード (Cloud9の場合、シグナル番号は15) を発行します。
$ kill -15 12241
行儀の悪いRailsサーバーなどのプロセスをkillする際には、上のように１つずつkillすることをおすすめします。Railsサーバーのpidを知るには、ps aux | grep server)などと実行します。しかし時には特定の名前を持つプロセスをまとめてkillしたいこともあります。しつこいspringプロセスたちを１つずつkillするのは大変面倒です。一括killを行うには、最初にspringコマンドそのものでプロセスを停止しておく必要があります。
$ spring stop
このコマンドが効かないことも多いので、そのときはいよいよpkillコマンドでspringの名前を指定してkillします。
$ pkill -15 -f spring
開発中に動作がおかしくなったりプロセスがフリーズしていると思えたら、すぐにps auxで状態を確認し、kill -15 <pid>やpkill -15 -f <プロセス名>で整理してみましょう。
https://railstutorial.jp/chapters/static_pages?version=5.1#sec-guard
assert_selectメソッド provideメソッド
・assert_select "title", 〇〇
→〇〇という文字があるか確認できる
・provide(供給)し、yield（生み出す）
エラー
$ rails test
ActionController::UnknownFormat: StaticPagesController#about
is missing a template for this request format and variant.
Railsでは、「テンプレート」とは「ビュー」を指します。
テストをするか
◆チュートリアル 3.3.1
それではいつ、どんなふうにテストを行えばよいのでしょうか。この点を理解するために、テストを行う目的をもう一度確認してみましょう。著者は、テストには次の3つのメリットがあると考えます。
- テストが揃っていれば、機能停止に陥るような回帰バグ (Regression Bug: 以前のバグが再発したり機能の追加/変更に副作用が生じたりすること) を防止できる。
- テストが揃っていれば、コードを安全にリファクタリング (機能を変更せずにコードを改善すること) ができる。
- テストコードは、アプリケーションコードから見ればクライアントとして動作するので、アプリケーションの設計やシステムの他の部分とのインターフェイスを決めるときにも役に立つ。
上の3つのメリットは、テストを先に書かなくても得ることができますが、それでもテスト駆動開発 (TDD) という手法をいつでも使えるようにしておけば、間違いなく多くの場面で役に立ちます。テストの手法やタイミングは、ある意味テストをどのぐらいすらすら書けるかで決まると言ってよいでしょう。たいていの開発者は、テストを書くのに慣れてくるとテストを先に書くようになります。その他にも、アプリケーションのコードと比べてテストがどのぐらい書きにくいか、必要な機能をどのぐらい正確に把握しているか、その機能が将来廃止される可能性がどのぐらいあるかによっても異なってくるでしょう。
こういうときのために、「テスト駆動」にするか「一括テスト」にするかを決める目安となるガイドラインがあると便利です。著者の経験を元に、次のようにまとめてみました。
- アプリケーションのコードよりも明らかにテストコードの方が短くシンプルになる (=簡単に書ける) のであれば、「先に」書く
- 動作の仕様がまだ固まりきっていない場合、アプリケーションのコードを先に書き、期待する動作を「後で」書く
- セキュリティが重要な課題またはセキュリティ周りのエラーが発生した場合、テストを「先に」書く
- バグを見つけたら、そのバグを再現するテストを「先に」書き、回帰バグを防ぐ体制を整えてから修正に取りかかる
- すぐにまた変更しそうなコード (HTML構造の細部など) に対するテストは「後で」書く
- リファクタリングするときは「先に」テストを書く。特に、エラーを起こしそうなコードや止まってしまいそうなコードを集中的にテストする
上のガイドラインに従う場合、現実には最初にコントローラやモデルのテストを書き、続いて統合テスト (モデル/ビュー/コントローラにまたがる機能テスト) を書く、ということになります。また、不安定な要素が特に見当たらないアプリケーションや、(主にビューが) 頻繁に改定される可能性の高いアプリケーションのコードを書くときには、思い切ってテストを省略してしまうこともあります。
NO IMAGE設定
・ヘルパーにモジュールを書く（モデルではない。→ モデルに書くにはクラス）
・今回はimage_tagヘルパーをモジュール内のメソッドで処理している
・いろんなテーブルで同じ処理をするのでapplicationhelperに書く
・alt属性はimageは設定出来ているが、画像が読み込まれない時のこと。今回は名前（name）を文字で出している。
1 module ApplicationHelper
2 def user_image(user)
3 return image_tag(user.image, alt: user.name) if user.image?
4 if user.image.blank?
5 img_url = 'NO_IMAGE.jpg'
6 end
7 image_tag(img_url, alt: user.name )
8 end
9 end
2. ←「user_image」というメソッドを作る。 (user)は仮引数なのでなんでも良い。
3. ←もし「user.image」が真の場合はreturnを返して抜ける
4. ←抜けなかった場合、もし「user.image」がblankの場合に、、、
5. ← NO_IMAGE画像を変数に入れる
6. ←上記の変数の処理をする（※viewの処理を既にここでしている
