卒業してこれからITエンジニアとしての人生を生きていくにあたって!

本日を持ってテックキャンプを完全に卒業しました。。。

プログラミングを学んで感じたことは、この業界で生きていきたいです!

こんなに学習が楽しいと感じたのは、いつぶりか思い出せないです。。。

これが、仕事になるとおそらく私の理想とぶつかっていくことがほとんどなのかも知れません。。。

やっぱり辞めたいと考えることもあると思います

ですが、ここで学んだプログラミングの楽しさ自体が変わることはない!

これからもっと楽しい体験も待っているのでしょう!

なので、明日からもITエンジニアになるために面接も頑張っていきます!

そして、スタートラインに立って私花輪誠太郎は走り出します!

ライフコーチ・メンターさん達ありがとうございました!

可読性を上げるためには?

本日は、明日の発表のために資料作りと来週の面接対策のための企業分析を行なっていました

結論息抜きに作成したアプリを眺めているとこのコードは読みやすいのか?

と、疑問が湧きました。。。

これに関して、カリキュラムにはJavaScriptで例題がありそこには

可読性の高いつまり、読みやすいコードを書くメリットは主に3点あげられていました

①個人・組織の生産性が上がる

②保守性が上がる

③柔軟な開発体制が構築できる

これらが、あげられていました

詳細は、今後学んでいきます!

ただ、単純にITエンジニアとして働くにはチームで作業することを意識していきます!

エラー文が出ないけど、挙動がおかしいのでMVCを遡って原因を探してみました。。。!

 本日は少し前のエラーについて記述していきます。。。

結論は、エラー文が出ないエラーの時はMVCを遡れ!です!

 この時は、ログインしているユーザーなら自分が出品していない商品なら購入可能のはずでしたが何故かトップページに遷移してしまい途方に一瞬くれそうになりました。。

最初は、トップページに遷移するのはviewで記述したパスが間違っていると仮説を立てました

そこからはrails Routesでパスを確認しましたがIdも引数から引っ張ってきていたので

この仮説は間違っていました

次の仮説は、今回のアプリではコントローラーで以下の制限をかけていました

f:id:makoto_karin:20211027191413p:plain

f:id:makoto_karin:20211027191436p:plain

こちらのスクショで修正した後のものになりますがbefore_actionのmove_to_indexの中にShow今回の購入用のアクションが記述してありました

こいつが悪さをしていたとは。。。。

 この時の私の仮説と思考は、MVCの中でviewに関しては問題はなかったので次にMとCに取り掛かりました

ただ、Mに関しては関係がないと考えていました

理由は、この問題はdbが関係していないつまり、データの取得に関してノータッチでありページの遷移には無関係だからです

なので、Cのコントローラーに目を付けました!

 やっと、MVCの流れと役割から仮説を立て除外することができるようになってきました!ほんとに最初は、手当たり次第いじり回したのが懐かしいです。。。

今後も仮説をたて実証して問題を解決していきます!

昨日やったからといって、確認を怠るな!先入観を捨てろ!

 本日は、本番環境で購入ができないエラー文が出ないエラーに苦戦しました。。。

結論昨日にやったからといって確認を怠らず手順をやり直そうです!

先入観を捨てろ!

 昨日S3の実装も完了したので、本番環境でエラーが出ないか確認をしていました

ここで、購入時トークンが生成されないよとログから言われ原因を考えました

私の最初に立てた仮説は、コントローラーのクリエイトでトークンが生成されていないと考えローカル環境でデバックを行いました

ですが、ローカルではトークンは生成されていました

次に考えたのが昨日のS3の設定時に記述を間違えて消した箇所があるのではです

結果は、大外れでした。。。

なので、メンターさんに連絡するまでにやった行動を伝え昨日の実装を伝えたところ昨日記述した環境変数が怪しいとアドバイスをもらい確認しました!

heroku configで確認すると

f:id:makoto_karin:20211026190838p:plain

昨日記述したはずのPAJ関係のキーがごっそり抜けていました。。。。。。。

f:id:makoto_karin:20211026191056p:plain

修正がこちらになります。。。

これは、トークンが生成させる訳ことなんてできません。。。

 今回のミスは、ローカル環境では記述していつも通りherokuの環境にheroku config:setしていると先入観を持って向き合ってしまったことです

私がITエンジニアとしてこれからも学んで成長していくためにも、今回のことを肝に銘じて同じ轍は踏まないよう同じ手順を怠らずに実行します!

卒業を控えて今週の学習の方向性を考える

本日も、学習を進めていましたが早いもので今週の金曜日にはテックキャンプを卒業することになります

そんな、最後の数日の学習の方向性ですが。。。

結論、独り立ちすることを考えるとデバックと検索力と仮説力を磨きます!

理由は、この2ヶ月を振り返ってメンターさんの問題解決を観ていてこの三つがないと現場に出ても成長できないのではないと感じたからです。。。

詳細は、また後日に書こうかと思います

先ずは、卒業の日まで学習を続け更にその先のITエンジニアとして成長し続けるためにもテックキャンプで吸収できるものを吸収します!

Javascriptで取得している情報を確認したい!

本日はJavascriptのデバックをしました!

結論情報で何を取得したいか確認したいならデバック!

console.log()
debugger

 

f:id:makoto_karin:20211022193219p:plain

今回は、cardの中のnumber・cvc・exp_month・exp_yearに情報が入力されているかを確認したくてデバックを使用しました

詳細は省きますが、私はなかなかこの四つの情報がうまく入りませんでした

そこでメンターさんに相談するとデバックを勧められました

なのでカリキュラムをひっくり返して調べました!

実際にデバックを使用すると欲しい情報以外が出てくる出てくる。。。

原因は、()の中の引っ張り出してきたい場所が見当違いの記述をしていたからでした。。。

ここまでの学習で、繋がりを目でみて探すことはしていましたが実際に取得した情報がどこから来るものなのかわかっていませんでした

ITエンジニアとして働く前に、自己解決の糸口の見つけ方やどう情報を取得しているのかの仕組みを知るためにも、デバックを練習していきます!

どんな情報が来ているか知るためにコンソールを活用しよう

本日も最終課題のやっていましたが、今回は条件式を使う機会が多い日でした

結論は、条件式に限ったことではありませんが狙った情報が本当に来ているかを目で直接確認するためにもコンソールは便利でした!

f:id:makoto_karin:20211021200359p:plain

user_signed_in?については、またの機会に記述します!

今回の主役は、その後ろの

@item.order == nil

です

私は、Orderテーブルに無いならという条件を記述したいと考えました

そこで当初はNilではなく見当違いの記述をしていました

そこで、メンターさんに相談したところ「ここにはどんな情報が欲しいですか?」

と尋ねられ素直にOrderテーブルに無いという情報が欲しいと答えました

そうするとコンソールを使うことになりました

長くなりそうなので、簡潔にお伝えするとコンソールを使用して、Orderテーブルに無いつまりNilになる条件をみつけました

そこから、条件式はもっと単純に考えて良いことがよく分かりました。。。

 

最近は、条件式にメソッドばかり記述していたのでここまで簡素な記述で良いとは思ってもみませんでした

ですが、コンソールを使用したことでどんな情報がviewに取得されているのかを知ることができました

今回のようにどんな情報が欲しいのか知るためにもコンソールは欠かせないものなのだと実感しましたし、コンソールの使い方を習得できればITエンジニアとして働く上での心強い手札になると感じました

 

これからは、コンソールの使い方を練習して学習を進めていきます!