2020-07-11

7/9 本日の学び

■できたこと、躓いていること

ごめんなさい、今日は何も進んでません。

職場の仕事が終わらず、今までそれをしていました。

なんとか終わったので、明日は作業します。

寝て、明日はまた新しい気持ちで取り組めますように。

2020-07-10

7/9（木）本日の学び

■できたこと（といいますか再認識したこと）

「migrationファイルはすごく繊細なんです」とメンターさんが言ってましたが、その意味を痛感する日でした。

・ないテーブルに対して外部キー制約は結べないし、

・migrationの順番も先に読み込んで欲しいテーブルから作成しなければ、認識してくれない。

DBはLGTMもらっても全く安心できません。実装が進めば進むほど、手直しが必要になる分野だなぁと思いました。手直しを減らすには、いかに、このアプリを作成する時点で、あらゆるユースケースを想像できるかが大事で、想像できる人がデータベースを制するのだなぁとつくづく思いました・・・！

あとは、payjpを利用するにあたり、アカウントを作って、秘密鍵と公開鍵をゲットしないと実装できないので、今日はそれもしました。

それらの鍵を使ってまた適当なファイルにコードを組んでいきたいと思います。

■次の目標

金子さんがコードレビュー頑張ってくださっているので、LGTMもらったらクレジットカードテーブルを作ります。

今日は本当にたくさん学ぶことが多くていい日でした。

共同開発以前は、エラーが本当に嫌いで嫌いで、試験のエラー問題も苦手で・・。

考えたり、参考記事を探す作業が本当に辛くて、エンジニア向いてないんじゃない？って思ってました。

今はエラーに対する見方がちょっと変わりました。

成長起爆剤とも思いますし、あと、このエラーを解決することで、まだ未体験の人の将来の手引きになるかもしれないと思うようになったのです。いつかどこかでメンバーの役に立てるかもと思うと俄然やる気が起こるのです。

間違いなく共同開発での皆さんが私を変えました。

4人が4人とも、全く違う色を持っていて、私はめちゃくちゃ恵まれたチームに組んでいただいたと心底思います。

しっかり者でアイデアが豊富で、私よりずっと進行や取りまとめが素晴らしい木村さん。いつも冷静沈着で調べ物が上手で、根気強く実装に取り組む山川さん。的確で分かりやすいアドバイスでメンバーの難問を解決してくれる頼もしい内海さん。毎日誰よりも遅くまで勉強して頑張り屋で責任感の強い金子さん。

たった数日しか皆さんと一緒に作業してませんが、みんな人に与える人ばかりです。

まだ、始まったばかりなのに、なんだか卒業間近に書くような内容になってしまいましたが、今日一番学んだことだったので書きました。

改めて明日ももっと頑張ろうと思いました。

2020-07-09

7/8 本日の学び

■躓いているところ

・環境変数のこと忘れてしまった。言葉の意味も説明できないし、なぜここで使うのかもピンとこないので明日復習し直す。

・秘密鍵、公開鍵の言葉の意味

・Payjp.api_key = ENV['PAYJP_PRIVATE_KEY']を.bash_profileへ記述の意味

　これを書くとどんなメリットがあるのか？ないとどうなるのか？

・７つのアクション以外のアクションを定義するにはどうやって？

一つずつ潰していくしかない。

■今日できたこと

・コンフリクトの解消

今日はほとんど実装らしい実装をしていないので、明日はテーブル作成してコミットまで終わらせよう。

2020-07-08

7/8(水)定期MTG　個人目標のメモ

■個人目標（アイウエオ順です）

・内海さん

- 外部キー制約がついているものの登録

・金子さん

- マークアップの実装を開始するところまでいきたい

・木村さん

-　トレロの上二つを終わらせたい

・山川さん

- マークアップの実装を開始したい

・中村

- クレジットカードテーブル、モデル、migrationの生成まで終わらせて・・

- productsコントローラーで各アクションの実装を開始していたい

2020-07-08

7/7　本日の学び

■今日進んだこと

・DBをmasterブランチへマージ

今回受けた指摘一覧

・dependentオプションを使おう

親子関係のあるテーブルで、親のデータを削除したときに、子のデータが残ったままだと、整合性が取れずにエラーが出る。親のテーブルにdependentオプションを書くことで、自動で子のテーブルが削除されるように設定する。

対象となる子の特徴：親の外部キーにforeign_key:trueと書いていて、アソシエーションがbelongs_toの関係にあるもの。

例）親：productsテーブル　子：images,likes,commentsテーブル

このような子は親のデータが消えると、外部キーの参照元が消えるためどうしたらいいか分からなくなりエラーが出る。

なので、親のデータを消したら、同時に関連する子のデータも消えるように設定する。

■躓いているところ

コンフリクトを起こしてしまったようです。

明日、メンターさんにチャットで質問します。

ーーーーーーーーーーーーーーーー

明日、メンターさんに質問しようと思います。
コンフリクトを起こしているようです。
その画像↓
https://gyazo.com/dcd038af6719fad27bd1691e27ad26b6
カリキュラムで習ったコンフリクとの表記は
<<<<<<< HEADと>>>>>>> masterという記述が、=======で区切られて追記されていました。今回私が見たものは表記が異なります。
■発生までの経緯
①issue13のブランチを切ってクレジットカード実装に必要なgem payjpを導入
②その後、テーブルの修正が整ったので、コードレビューをしようと思いブランチをissue11（DB専用のブランチ）に切り替えて、修正したいファイルのみ選択してコミット、プッシュ
③LGTMをもらったのでmasterブランチにマージ
④その後GitHub Desktopに戻ってリモートの差分をプルするのを忘れたまま（これが原因？）ブランチをissue13に切り替えて、テーブルを作成しようとした。
⑤その前に何となくgem fileを見たら添付画像のようになっていた
■解決策は手動マージ？
参考サイト
https://weblike-curtaincall.ssl-lolipop.jp/blog/?p=1464
https://chulip.org/entry/20120831/1346381439
>>>>>>> Stashed changes
で囲まれている内容がどうもコンフリクトが発生している箇所のよう。
git checkout コマンドで、コンフリクト発生箇所をマージしてあげると解決するそうですが、恐ろしいので、メンターさんに明日チャットで質問しようと思います。
これのせいで誰かに多大な迷惑かけていることになってないか、そっちが心配です。大丈夫かな・・・

ーーーーーーーーーーーーーーーーーーー

2020-07-06

7/6本日の学び

今日の進捗状況

■できたところ（でもまだ○じゃなくて△の状態です）

READMEの修正をコードレビュー中

・主な修正点

- credit_cardsテーブルのカラムたち

- prefictures_id(active_hash)に訂正して追記

- shopping_daysテーブルの作成

やっぱりデータベースの考え方、楽しいけれど難しいけれど楽しいけれどの繰り返し。

active_hashの理解が乏しい中、えいやっとコードレビューの依頼をしたら、

やはりたくさんコメントつきで返ってきました＾＾；

chat-spaceの時からそうでしたが、i-dateさんのレビューは本当に分かりやすいです。

すごく丁寧で、自分が分からないところを言語化してくださるからなのかな。

コメントに質問を書くのはルール違反かもしれませんが、ここぞとばかりに

質問をつけて返してしまいました。

■つまずいたところ

・各idのリレーションをコードで書くとしたらどんなふうに？

・payjpで発行されたトークンの永続化を書くとしたらどんなふうに？

・payjpのテーブルはpayjp側で自動で作成されるんだろうか？

READMEでLGTMもらったら次にこの辺を詰めていかないといけません。

まだまだ調べきっていないので、明日も引き続き調べます。

分からないところを言葉にできただけ上出来、上出来と自分で自分を持ち上げつつ＾＾

-------------------------------------

（以下、自分のメモ書きです）

データベースにあるcredit-cardsテーブルには、

カード情報は一切登録しない設計になっている。じゃあ何を登録するのかというと

・user_id（これは私たちが作ったuserテーブルから引っ張っているid）

・card_idとcustomer_id(payjpから引っ張ってきた登録したカード情報に紐づくid)

この３つの情報がデータベースのcredit_cardsテーブルに保存される。

そうすると次に考えるのが、payjpにもカード情報を保存するテーブルが存在していて、そこに16桁のカード情報、セキュリティコードとかが保存されるということ。

このテーブルはきっと私が作成するんじゃなくて、自動でpayjpに登録されるんだろうな。ものすごくそうであって欲しい。調べないとよく分からないなぁ。

データベースにも保存しちゃダメ（法律上）、サーバーにも情報を漏らしたらダメ、だからpayjpのような決済代行サービスが存在するんだな。

そして商品を購入するたびに、カード情報登録時に発行されたトークンを永続化するコードや、各idのリレーションを示すコードを、該当のファイルに書いていかなければならない。よく寝て、頭の中しっかり整理されますように。

-------------------------------------------------

2020-07-06

7/5 今日の学び

■今日できたところ（進捗率は全体の15%ほど）

・payjpの仕組み８割理解した

--------------------------------

(自分用メモです。読み飛ばしてください）

-　payjpとは、web上でクレジットカードの決済[代行]をするサービス

-　webブラウザとpayjp間でカード情報をを登録（ここで登録は完結）

- 　サーバー側には、カード情報はカードトークンに置き換えられて送信される

- カードトークンは使い捨ての暗号のような許可証のようなもの。1度決済に使ったら新たなカードトークンを発行しなければならない（つまり、購入時に毎回カード情報を登録しなければならないということを意味する）。そんな面倒なことを避けるために、payjpの顧客idと、ユーザーが入力したカード情報をリレーションで紐づけ、トークンの永続化を実現する。

---------------------------------

・credit-cardsテーブルの書き方が見えてきた

## credit_cardsテーブル
|Column|Type|Options|
|------|----|-------|
|user|references|null:false,foreign_key:true|
|costomer_id|integer|null:false|←顧客ID情報（payjpから返ってくるデータ）
|card_id|integer|null:false|←カードID情報（payjpから返ってくるデータ）

### Association
- belongs_to:user