ユーザー管理機能

[ritsu1022]

実装概要

• Deviseの導入を行う。新規登録/ログイン/ログアウトができるまで実装する。モデルの単体テストまでを行い、コードレビューを依頼する。LGTMが出たら完了とする。

実装方針

• ブランチを作成する。
• Deviseを導入する。
• ユーザー管理機能を実装する。
• モデルの単体テストコードを書く。
• プルリクエストを作成してメンターにレビューを依頼する。
• LGTMをもらい、マージをする。
• デプロイをする。

実装条件

• [x] モデルにてバリデーションの記述を行うこと。
• [x] 必要な情報を適切に入力して「会員登録」ボタンを押すと、ユーザーの新規登録ができること。
• [x] 必要な情報を適切に入力して「ログイン」ボタンを押すと、ユーザーのログインができること。
• [x] 新規登録・ログイン共にエラーハンドリングができること（入力に問題がある状態で「会員登録」または「ログイン」ボタンが押された場合、情報は受け入れられず、各ページでエラーメッセージが表示されること）。
• [x] エラーハンドリングによって新規登録/ログインページに戻った場合でも、入力済みの項目（パスワード・パスワード確認用以外）は消えないこと。
• [x] エラーハンドリングの際、重複したエラーメッセージが表示されないこと。

新規登録/ユーザー情報

• [x] ニックネームが必須であること。
• [x] メールアドレスが必須であること。
• [x] メールアドレスが一意性であること。
• [x] メールアドレスは、@を含む必要があること。
• [x] パスワードが必須であること。
• [x] パスワードは、6文字以上での入力が必須であること
• [x] パスワードは、半角英数字混合での入力が必須であること
• [x] パスワードとパスワード（確認）は、値の一致が必須であること。

新規登録/本人情報確認

• [x] お名前(全角)は、名字と名前がそれぞれ必須であること。
• [x] お名前(全角)は、全角（漢字・ひらがな・カタカナ）での入力が必須であること。
• [x] お名前カナ(全角)は、名字と名前がそれぞれ必須であること。
• [x] お名前カナ(全角)は、全角（カタカナ）での入力が必須であること。
• [x] 生年月日が必須であること。

トップページ

• [x] ログアウト状態の場合には、トップページ（商品一覧ページ）のヘッダーに、「新規登録」「ログイン」ボタンが表示されること。
• [x] ログイン状態の場合には、トップページ（商品一覧ページ）のヘッダーに、「ユーザーのニックネーム」と「ログアウト」ボタンが表示されること。
• [x] トップページ（商品一覧ページ）ヘッダーの、「新規登録」「ログイン」ボタンをクリックすると、各ページに遷移できること。
• [x] トップページ（商品一覧ページ）ヘッダーの、「ログアウト」ボタンをクリックすると、ログアウトができること。

補足情報

• 配布しているビューファイルのname属性などは、初期値として「hoge」と設定しているため、実装する際には自身のデータベース設計に合わせて変更すること。
• 配布しているビューファイルにも、コメントアウトにて実装の案内が記述されているため、適宜読んで実装を行うこと。
• 「rails g devise」のコマンドで生成されたマイグレーションファイルには、デフォルトでemailとpasswordカラムが生成されるよう記載されている。そのため、この2つのカラムに関しては、自身でマイグレーションファイルに設定を記載する必要はない。
• 以下の項目に関しては、モデルで新たにバリデーションを実装する必要はない（Deviseにデフォルトでバリデーションが備わっているため）。しかし、単体テストコードを書き、バリデーションが働いているかの検証は必要。 ・メールアドレスが必須であること。 ・メールアドレスが一意性であること。 ・メールアドレスは、@を含む必要があること。 ・パスワードが必須であること。 ・パスワードは、6文字以上での入力が必須であること。 ・パスワードとパスワード（確認）は、値の一致が必須であること。
• Deviseによるカスタムコントローラの生成は不要（rails g devise:controllersのコマンドは、必須機能実装においては入力不要）。
• トップページ（商品一覧ページ）とは、app/views/items/index.html.erb を指す。

注意事項

• 機能毎に、commitとpushを行うこと。
• 配布されたビューファイルに最初からコメントアウトで指示などが記されている場合があるが、それらは機能を実装できた時点で削除すること。
• メンターにコードレビューを依頼すること。
• 機能の様子はGyazo GIFを用いて、テストコードが通っている様子はGyazoを用いて撮影し、それぞれのリンクをプルリクエストへ添付すること。
• Gyazoのリンクを添付する際は、何を撮影したGyazoのリンクか分かるように、リンクの前に説明を記載すること。
• コードレビューを依頼する前に、Rubocopを実行すること。
• コードレビューを依頼する際は、テストコードを書き終わってから依頼すること（テストコードの含まれていないレビューは対応しません。実際の開発現場でも同様の対応であるためです）。
• プルリクエストには、「What」と「Why」を記述すること（「What」と「Why」の記載されていないレビューは対応しません。実際の開発現場でも同様の対応であるためです）。
• LGTMが出るまでマージしないこと。
• LGTMが出る前に他の実装へ着手することは、推奨しない（Gitにおける複雑なコンフリクト等を引き起こす可能性があるためです）。

プルリクエストへ記載するgyazo

• [x] 必要な情報を適切に入力して「会員登録」ボタンを押すと、ユーザーの新規登録ができる動画
• [x] 入力に問題のある状態で「会員登録」ボタンが押された場合、ユーザーの新規登録はできず、エラーメッセージが出力される動画
• [x] 必要な情報を適切に入力して「ログイン」ボタンを押すと、ユーザーのログインができる動画
• [x] 入力に問題のある状態で「ログイン」ボタンが押された場合、ユーザーのログインはできず、エラーメッセージが出力される動画
• [x] ログアウトに成功する動画
• [x] テストに成功する画像

参考カリキュラム

• Deviseの導入・実装 応用カリキュラム Lesson2 「ユーザーを登録しよう」 応用カリキュラム Lesson6 「ChatAppのユーザー管理機能を実装しよう」

• マイグレーションファイルのロールバック 基礎カリキュラム Lesson7 「データの保存場所と管理役を作ろう」

• RSpec 応用カリキュラム Lesson5 「PicTweetのモデルの単体テストコードを書こう」 応用カリキュラム Lesson6 「ChatAppのモデル単体テストコードを書こう」 "