Railsチュートリアルでの気付き

1.やってみて

自身の予想よりもボリュームがあり、かなり時間がかかってしまいました。また時間が空くと思い出す時間が必要となってしまい次の内容に進むまで時間がかかりました。それでも最後までやり遂げることで色々インプットが増えたのかなと考えています。

2.身についたこと

一部元々知っていたこともありますが改めて知ったものも含んでいます。

Linuxの基本コマンド

環境構築について、Rails チュートリアルの公式サイトにはAWSのCloud9が推奨されていますが、Cloud9がうまく起動せず*1ローカルに仮想環境を立て、そこでRails チュートリアルを実施しました。具体的にはls,pwd,chmod,grepなどです。

業務ではwindowsしか携わっていないので、新しい気持ちで携われたのかなと思っています。lsコマンドはWindowsには無いので打つとエラーになりなんで無いんだよ！と思うことが時々ありました（笑）

MVC アーキテクチャ
パーシャル

Model•••データの管理を司るレイヤー

　　　　DBとのやり取りやデータの操作行う。ビジネスロジック担当。

Controller•••ModelとViewの振り分けを司るレイヤー

　　　　リクエストに応じてModelに対してデータの入出力やデータの出力結果をViewに対して引き渡す。

View•••画面出力を司るレイヤー

　　　　HTMLを生成しクライアントのブラウザに送りユーザが操作できる。同じコードを切り出して別テンプレートにすることをパーシャルと言う。

テスト自動化

単体〜結合のレベルテストをコードを書いてそれをフレームワーク（Rails）が勝手にやってくれます。自動化することにより工数の削減が期待できます。

エクセルスクショをしなくても良い。

スクショを取るだけの簡単な作業を行わない代わりにテストコードに対する知識が必要ですね。

TDD（テスト駆動開発）

テストコードを記載してその機能を実装します。実装後GREENになった部分についてテストコードを変更せずに実装したコードをより良く修正することができ、品質を担保しつつ綺麗なコードを書くことができます（リファクタリング）。実装したコードの可読性向上や修正・拡張しやすいコードを書けるなどのメリットがあります。

Webアプリケーションのセキュリティ

SQLインジェクション

⇨本来検索されてはいけないデータが表示され、情報漏洩の原因となります。

条件文を書く際、画面からの引数を元にSQLクエリを発行したい場合があります。例えば名前を検索する機能があったとして、画面からの検索条件のエリアに以下の文字を入力します。

A' OR '1' = '1

その際は以下のようなクエリが発行されます。

SELECT * FROM users WHERE name = 'A' OR '1' = '1';

このクエリが発行されることにより本来検索されてはいけないデータが表示されてしまいます。それを防ぐためにRailsでは以下のように"？"を設定することでエスケープしてくれます。

User.where("name = ?", name)

JavaだったらSQLインジェクション対策はPreparedStatementでしょうか。

パスワードのハッシュ化

⇨パスワードをDBに保存する際には平文で保存しないようにしましょう。DBが盗み見されてもパスワードの安全性を保つ必要があります。DBにはハッシュ化された値を保存し、画面から入力された値のハッシュ値とDBに保存されているハッシュ値が同じ場合認証が成功する仕組みです。

２段階認証

⇨ユーザ登録、パスワード変更の際にメールを送信し、メールに記載されたURLにアクセスすることでアカウントの有効化やパスワード変更完了となります。２段階認証を行うことで第三者がパスワードの変更できずアカウントの乗っ取りを防げます。

メールでなくてもログインするたびにSMSでセキュリティコードを発行するシステムも色々存在します。

REST（REpresentational State Transfer）

Webアプリケーションの設計方法の一つ。URLによってデータをどのようにするかを判別することができます。RDBのCRUDと基本的なHTTP リクエストに対応しています。

URL	HTTP リクエスト	controller内アクション	CRUD	用途
/users	GET	Index	Read	ユーザーの一覧を表示する
/users/1	GET	show	Read	ID=1のユーザを表示する
/users/new	GET	create	Read	新規ユーザを追加するページを表示する
/users	POST	new	Create	新規ユーザを追加する
/users/1/edit	GET	edit	Read	ID=1のユーザを編集するページを表示する
/users/1	PATCH	update	Update	ID=1のユーザを更新する
/users/1	DELETE	destroy	Delete	ID=1のユーザを削除する

1対1、1対N、N対NのDB構造

1対1

⇨例えば学生情報とそれに紐づく身体情報。学生情報には氏名や性別などの情報があり、身体情報には過去の病歴などの情報があるケースです。

正直あまり1対1でテーブルを分けるメリットがないのではないかと考えており、強いて言えば今回のように機密的な情報を別テーブルにすることが挙げられます。

1対多

⇨例えば学生情報とそれに紐づく成績情報。成績情報には修得した科目の評価が存在します。学生一人に対して成績情報が複数あるイメージです。Rails チュートリアルだとユーザーに紐づくマイクロポストが該当します。

多対多

⇨例えば学生情報とそれに紐づく履修している科目情報。科目情報には科目名や単位数が存在します。学生は複数の科目を履修できるし、科目情報からは見ると複数の学生が履修することができます。Rails チュートリアルだとユーザのフォローフォロワー関係に該当します。

多対多の場合、中間テーブルを作成し１対多のリレーションにすることで対応できます。上記の場合中間テーブルとして学生IDと科目IDが存在する履修情報を作成できます。

3.躓いたこと

HTMLのバリデーションによってRailsのバリデーションが確認できない。

メールアドレスのバリデーションをmodelで以下の通り正規表現でのチェックするようにしたので、期待した結果は更新ボタン押下時に画面上部に”メールアドレスが不正です”と言ったエラーメッセージが出ることです。

VALID_EMAIL_REGEX = /\A[\w+\-.]+@[a-z\d\-]+(\.[a-z\d\-]+)*\.[a-z]+\z/i
 validates :email, presence: true, length: {maximum: 255},
format: {with: VALID_EMAIL_REGEX} ,
uniqueness: { case_sensitive: false }
 

違う結果としてエラーメッセージが出る。。。

f:id:tagoaskubeya:20190729220618p:plain

調べてみるとHTML側でメールアドレスのバリデーションを勝手にやってくれるみたいです。今回はそれが不要なので以下の通りform_forヘルパーの引数にhtml: {novalidate: 'novalidate'} を適用するとHTML側のバリデーションが解除されます。

<%= form_for(@user, url: yield(:url), html: {novalidate: 'novalidate'} ) do |f| %>
<%= render 'shared/error_messages', object: f.object %>

<%= f.label :name %>
<%= f.text_field :name, class: 'form-control' %>

<%= f.label :email %>
<%= f.email_field :email, class: 'form-control' %>

<%= f.label :password %>
<%= f.password_field :password, class: 'form-control' %>

<%= f.label :password_confirmation %>
<%= f.password_field :password_confirmation, class: 'form-control' %>

<%= f.submit yield(:button_text), class: "btn btn-primary" %>
<% end %>