JS（ジャバスクリプト）を使って計算してみよう
本日の実装は、viewとJSを繋いで計算できるようにしました
結論は、計算をやってもらえるのは楽でいいですね！
JSに触るのは一週間か二週間ぶりなので、特徴を忘れていました。。。
もう、久しぶりのJSのエラーが大量に出てきて嬉しくなってきました！
今回は
innerHTML = Math.floor（）
を使いました
（）に何を入れたら良いかさえ忘れていましたがメンターさんのアドバスと直感でできてしまい思わずメンターさんに私のアウトプットにつきまってもらいました。。。
ここいらで、JSの復習もやっていきます！
エラーが出た時
本日も元気よくエラー文と一緒にアプリを作っていました！
特にモデルを作成していました
結論、ファイル名に「＿」を決して入れるなかれです。。。！
ここに至るまで、全角はないか（ありました！）・単語ミス（意外なことにこっちはありませんでした。。。）はないか・モデルにバリデーションを書き損じはないかなどなどいろいろメンターさんに相談する前に確認しましたが、ありました。。。
そして、最後最後まで解決できなかったがファイル名に「＿」を入れたことで大変です
まだ、メンターさんに質問できる段階でしでかしてよかったです！
これ、私一人だったら気づくのにどれだけ時間を使ったことか。。。想像したくないです。。。
今後ITエンジニアとして活躍するためにも、なぜと好奇心を持ってエラー文に挑戦していきます！
今週一週間学習して
今週一週間の学習を通していろいろ学びましたが、学習時の心構えというかITエンジニアになるにあたり意識すべきことがありました
結論、開発はチームでやるのだから勝手に手順を変えてはいけないです！
現在の学習では、プロジェクトが段階的になっているので一つ進むとブランチを切ってマージしています
そんな中、つい思いつきで記述をすると思わぬエラーが起こることがわかりました。。
まず、手順を厳守！明日から肝に銘じてITエンジニア目指して頑張ります！
No such file or directoryが出てきた。。。
本日は、アクティブコードの実装を目指していました
結論環境が変化していました！
いつもはbrew install imagemagick⇨bundle installで解決していました
ですが.rbenv/shims/bundle: line 21: /usr/local/Cellar/rbenv/1.1.2/libexec/rbenv: No such file or directoryと、言われてしまいNo such file or directoryから余計なことを先に記述したのではとここまでの記述をコメントアウトしました。。。
ですが、見事にハズレました！
なので、メンターさんに相談したところ今回は、環境が変化により上記のエラーが表示されたとのこと
噛み砕くと、No such file or directoryの前に記述してあるファイルがない。。。
なぜか、brew install imagemagickのUpgradingの中でrbenv 1.1.2 -> 1.2.0がありこいつが今回の原因でした
Upgradingにより現状のbrew install imagemagickでは、rbenvの1.2.0ファイルが存在していません
だからターミナルでNo such file or directoryそんなファイルないよと言われたのでした。。。
つまり、Upgradingで環境が変化したので変化に応じた記述をすれば解決です！
解決方法は大きく分けて二つとのこと①rbenv rehashで新しいバージョンにする
②rbenv 1.1.2を削除して新しくする
私は①を選び無事にbundle installが通りテーブルも完成しました！
今までUpgradingは、セキュリティの改善やアプリの問題の解決など良いものだと考えていました
ですが、ITエンジニアにとってUpgradingすること環境が変化しそのせいで、不利益が生じることを学びました
ITエンジニアとして働き出したらこの辺り気を付けていきます！
テストコードを自分で書き出してみて
本日は、テストコードを実装しました
結論を言うと今回は、Userモデルの単体は正常系が一つに対して、異常系の多さに驚きました！
学習を進める中で、テストコードは一度やりました
ですが、今回自分で実装してみて異常系がどんどん出てきて底はあるのはわかっているのですが、なかなか底は見えませんでした
その理由は、実装のカラムの数が８個と前回学習した時の倍以上あります
更に、バリデーションもpresenceと正規表現で漢字・仮名・平仮名で制限をかけていますし、アルファベットや数字を考えるとどんどん記述したい内容が出てきました！
そこで、こんなに数が多くて良いのかメンターさんに質問しました
普段のrailsですと、簡単に記述し可読性を上げるために余分な記述を省くイメージがあってからです
メンターさんの返答は、簡潔に言うと「今回はテストなので、記述が多い方が粗を出せて良いんですよ！」とのことでした
なので、私の努力は決して無駄ではありませんでした！
対して、正常系が一つだったのは新規登録のみだからでした。。。
deviseは深くて広いですね！
本日もdeviseを学習しました！
本日の結論は、パスをカラムに保存する時も変換用の記述がなくてもdeviseがやってくれていたです
パスを繋ぐ際カラム名の記述ミスを無くすためにDB設計を横目にform_withのカラム名を記述していました
今回は、パスワードに関しては暗号化をするためにencrypted_passwordを記述しました
このお陰で、テーブルをみるとパスワードが暗号化されて何が載っているのか全くわかりません。。。
で、この便利機能自体は知っていたのですが。。。どこでパスワードを変換しているのか考えていませんでした
なので、ご存知の方はお察しの通りこのままでは保存できません。。。
悩んだ末、ローカルのコードを確認したところ「encrypted_passwordが間違っているよ！」とターミナルに言われました
そして、メンターさんに質問しました。。。
ターミナルに「ここが違う！」と言われたことを踏まえて仮説を伝えると。。。
端的に書くと「encrypted_passwordは、カラム名では使うけどパスとしてはpasswordでOK！」と言われ、思わずdeviseって痒いとこまで手が届いてほんっとうに便利ですね！と笑ってしまいました！
いや、devise以外だと毎回これでもか！と記述するので、deviseには頭が上がりません。。。
deviseの便利さについて
結論を言うとdeviseってものすごく便利ですね！
本日そう思ったのは、最近になってdbから取得する情報のやり取りを少し理解できました
そんな中で学習中にUserの実装を行なっていて、いつもならルーティング・コントローラーを記述していく段階になりました
この時になり知りました
モデルでデフォルトで記述されているメールやパスワードにはある程度実装されていること、Userのコントローラーの記述が不必要であり、メールやパスワードにはデータの取得時の制限などが既に存在していることを学びました。。。。
deviseの実装は、便利なのだとよくわかりました
まだまだdeviseの便利な機能はある様なので、明日も成長できるよう学んでいきます！
