20201121_アウトプット(ER図・README・DBとアプリの関係性・ユーザー管理機能)

アプトプット画像

今日行ったこと 5時間

  • ずっとモヤモヤしていたER図・README・DBとアプリの関係性についてメンターさんへ聞く 

  • ユーザー管理機能の実装(deviseの導入、MVCの実装)



新しい発見

ER図ってどこまで書けばいいの?
  • ER図は想定されるテーブル全てとそのアソシエーションも記載すると良い。
READMEって共通で書くこと決まっているの?(色々な人のGitHubを見ても様々でわからない)
  • READMEは、表紙であり、目次。つまり、その目次を通して何を伝えたいかによってREADMEの内容が変わることを理解。

【例】

  • ポートフォリオのような何を使って何を作ったのかアプリの良さを相手に分かりやすく伝えるための目次

  • チーム開発のようなチームの基準として環境構築の設定・全体像の共通認識を図る・後から入ってきた人でも取り組みやすい等のための目次

  • 教材のようなアプリをクローンして練習するための目次




DB(データベース)とアプリの関係性について
  • チーム開発をしたことがないため、データベースの作成・マイグレーションファイルの編集等が、どこまで「自分のパソコンのみ」の影響なのか、「自分以外のパソコン」にも影響をもたらすのかずっと分からなかった。

  • 結論は「コード」(文字通り、VSコードなどに書いてあるコード)は、GitHubのクローン機能などを通じて、自分のパソコンに入っているものと、他のパソコンに入っているものの共通化を図ることができる。つまり、マイグレーションファイルに書いてあるカラム(表の見出し)についても、GitHubでマージ後にプルすれば、他の人が書いたコードを自分のパソコンに取り入れることができる。

  • 反対に、GitHubのクローン機能などを通じてもできないことがある。それは、DB・Gemのインストール・Yarnのインストール。(今の時点で把握できたのは3つ)

自分で取り入れる必要があるもの ターミナルでのコマンド コマンドによってもたらすこと
DB rails db:create
rails db:migrate
自分が使っているアプリ(シークエルプロ等)にテーブルの作成とカラムの作成を行う
Gem(Gemを取り入れている時のみ) bundle install 自分の💻と他の💻のバージョンを考慮しつつGemを使えるようにする
Yarn(jsファイルがある時のみ) yarn install 自分の💻と他の💻のバージョンを考慮しつつjsファイルとcssファイルをくっつける


  • なので、開発環境のDBに関しては、反映させられるのは「カラム名」までで、実際のデータ内容は自分のパソコンのみ。(自分のデータを他の人に反映できないし、逆もしかり)

  • なお、本番環境のDBに関しては、共通で使えるためのデータベースを設定するので(それがデプロイでもある)データの保存先が一元化される。

  • 本番環境も、アプリをアップした段階ではコードの記述内容は反映するものの、デプロイ先で指定したDBにマイグレーションファイルに基づいたテーブルは作成されていないので、デプロイ方法に応じた言語でmigrateする。(例えば、Herokuであれば、heroku run rails db:migrate


●DBの細かい順序

(1)rails newによってDBに関する仕様書(database.yml)がアプリ内に生成
(2)rails db:createによって(1)に基づいたDBが自分のDBアプリに生成
(3)rails db:migrateによって自分のDBアプリにマイグレーションファイルに基づいたテーブルが生成



deviseについて(忘れていたこと)
  • ストロングパラメーターに関わるコントローラーの記述について。deviseに関しては、処理を行うコントローラーがGemないに記述されているため編集することができない。(ビューのように表示させることもできない)

  • なので、全てのコントローラーを継承しているapplication_controller.rbに「deviseコントローラーだったら」というbefore_action+if文をつけて、ストロングパラメーターによってDBに保存したいキーを指定するメソッドを書く。

  • Railsのpermitメソッドと、deviseのpermitメソッドは別物。

それぞれ pemitメソッド
Rails params.require(:モデル名).permit(:許可するキー)
devise devise_parameter_sanitizer.permit(:deviseの処理名, keys: [:許可するキー])

なお、処理名とは、

処理名 役割
:sign_in サインイン(ログイン)の処理を行うとき
:sign_up サインアップ(新規登録)の処理を行うとき
:account_update アカウント情報更新の処理を行うとき



感想

  • ずっとモヤモヤしていたER図やDBのことを理解できてすっきり!

  • そして理解したことによって、他の方のGitHubが少し読みやすくなった気がする😳(これは嬉しい!)

  • deviseについてGemの導入のことは覚えていたけど、コントローラーのことはすっかり忘れてた。知識の穴が埋められた✨

  • deviseとモデルの「permit」は違うことについても、昔の自分がモヤモヤしていたのはここだったのかー!と発見があり嬉しかった。あと過去のカリキュラムに戻った時に、書いてあることが「なるほどね!」と思うことが多く(当時は「ふうん」という感じだった)実装してて楽しい。



これから理解したいこと(覚書用)

  • Formオブジェクト(モデルの存在しないデータを更新)


  • エラー解決

  • カラムの追加方法、ロールバック

  • 環境変数(OSの知識)

  • 環境構築、バージョン対応

  • GitHub(他のアプリケーションと連携・自分に取り入れること)

  • Herokuのデプロイ方法 👉11/15・16学習 50%進む

  • README(DB設計だけでなく、全体について取扱説明書としてどんな風に書くと良いのか)

  • リファクタリング

  • データベースをインポート、エクスポート

  • Docker