20201129_アウトプット(PAYJP疑問点の解消・フォームオブジェクト)
今日行ったこと 4時間
PAYJPにおける疑問点の解消
補足カリキュラム(1つのフォームから複数のテーブルに情報を保存するアプリ作成)
新しい発見
PAYJPの実装方法を通して、理解が浅かったところ・確認したい点をメンターさんに聞いた。
モジュールバンドラーとパッケージ管理システムの違い
モジュールバンドラーとは、JavaScriptがブラウザ側においてサーバーともやりとりしたい時に、
(1)高級言語を機械語に翻訳(コンパイル)
(2)モジュールという単位にわけて管理。依存関係を考慮しながら、ブラウザに読み込む時にタイミングの調整
をする役割だと理解。今回PAYJPにおいて、webpackerを用いて、公開鍵を念のため環境変数にすることはこちらにあたると理解。
ごっちゃになっていた
yarn install
を行うのはパッケージ管理システムのことだった。(Node.jsというJavaScriptのサーバーサイド側の話だった。)yarnとnpmとはNode.jsを管理するために必要なパッケージ管理システム。ライブラリ(Railsでいうと「Gem」)をインストールする時に、依存関係を考慮しながら取り込んで管理する役割があることを理解。
PAYJPリファレンス
今回、APIを使うために、ビューの大元(
app/views/layouts/application.html.erb
)に、<script type="text/javascript" src="https://js.pay.jp/v1/"></script>
を記述して、ブラウザでアプリを開いた時にpayjp.jsが読み込まれるよう実装した。その時に、リファレンスの1と2があって勘違いしていたところがあった。実装するときは、リファレンスが複数あっても混ぜたりせず、基本的にそのリファレンス通りでOKと理解。
createToken
とgetToken
の違いとしては、createToken
は新しく生成するもの、getToken
はPAYJPにあるのが前提でそれを取得しにいくものと理解。(今回は、テストで作っており、毎回生成しているのでcreateToken
になることを理解。)
Herokuの環境変数
世界中で見られるようにするのがデプロイ。そのためにはサーバー構築が必要。そのための手段としてHerokuがある。なので、PAYJPの公開鍵と秘密鍵を環境変数に設定することはアプリ(デプロイ)ごとに必要と理解。
FormData
PAYJPにデータを送る際、フォームデータを活用した。その記述で以下のように記述した。
const formResult = document.getElementById("charge-form"); const formData = new FormData(formResult);
- ふと、
const formData = new FormData(document.getElementById("charge-form"));
でも実装できるかなと思ったらできた。
- 複数行になっても、定数には一つの内容を書いた方が、可読性・メンテナンス性が向上すると理解。
キーとバリュー(複数モデルとコントローラーがあった時)
アソシエーションを組んでいれば、他のモデルのカラムを、他のモデルのコントローラーに定義して活用できると理解。
今回で言えば、PAYJPには金額が必要。その際、金額はitemテーブルにあり、購入画面はorderテーブルだったとしても、ordersコントローラーに
@item = Item.find(params[:id])
を定義すれば、itemテーブルのカラムをoederテーブルにおけるコントローラーでも使えることを理解。コントローラーのどのアクションに定義するかは、どのアクションで使うかによる。今回、金額を使うのはプライベートメソッドに定義している
order_params
メソッドになるので、それを定義しているcreateアクションでOKと理解。キーに対するバリューは、直接文字列を指定することもあるし、他のアクションを引用して指定することもあると理解。
感想
昨日の銭神さんの記事について、Twitterで発信したら返事とフォローしてくださって朝びっくり!大興奮!(笑)とても嬉しかったです(本当にありがとうございます)
難しい内容を、分かりやすく簡潔に、相手がわかる言葉で話せる人が一番かっこいいと思う。今は、自分が理解するのに精一杯だけど、これからもコツコツ知識をつけて、銭神さんのようなわからない人に対して、分かりやすい言葉で伝えていけるような人になりたい。
その時に、方法だけでなくて、理由も理解した上で、答えたり話せる人になりたい。
銭神さんの記事にはRailsだけでなく、アプリケーションを広い意味で捉えた時に大切なことが溢れているので、今後も見ながら、特に最終課題が終わってオリジナルアプリケーションを作る時に活用します!😍
- 夜、チームミーティングのファシリテーターを経験した。緊張して今日のプログラミング勉強はソワソワしてしまい(笑)終わるまでカリキュラムに集中できなかったけど、とっても良い経験になった!
【引き受けた理由】 やってみませんかと言ってもらえて嬉しかったため。
とりあえずやってみよう精神でチャレンジしたかったため。(メンバーの皆さん優しいので、その中でチャレンジ出来るのは本当にありがたい。)
少しでもメンバーの役に立てるようなことをしたい。
【準備したこと】
集まってくれるメンバーのニーズ・聞きたいことの要点整理
そこから何を持って帰って欲しいか考える
そのために今のタイミングでやったら役に立ちそうなお題・手段を考える
【失敗したこと・学びになったこと】説明している時、雑音が入り音声聞こえていなかった😱
今後は「聞こえていますか」と音声チェックをしよう。
zoomのチャット機能について「何かあったらヘルプを求める」という頭しかなかった。今後は「何かあったらお知らせしてくれるかもしれない」という視点も持つ。
【感想】
- やってよかったです。本当にありがとうございました。そしてやってみたら良い経験になるだろうなと見極めて、任せてくれたり、それまでの間、フォローし続けてくれたり、ライフコーチの方の支えが絶妙でまたそこも勉強になりました。いつも感謝です。