Stripeを知らない状態から使って20時間で中古本販売プラットフォームを作ってみた / JP_Stripes in Aizuに参加してきました
この前、会津若松市内で行なわれたJP_Stripesに参加してきました。 今回はその感想と、そこで私が行なったLT「20時間で作る中古本プラットフォーム」の内容を書いていきます。
「MaaSアプリのその後、無人コンビニアプリとかマッチングアプリとか試飲サブすくとか」(デザイニウム前田さん)
普段、決済サービスを利用客の立場からしか見ない私ですが、企業の目線からの話を聞くことができました。
店舗側としては、電子決済の入金日が翌日入金か月末振込かで導入しやすさが変わるそうです。さらに、決済された金額は、全額会社持ちではなく、関係者に分配しなくてはいけません。分配のしやすさなども決済サービスの決め手になるそうです。
割引に釣られて、いろいろな決済サービスを多様している僕ですが、企業側のことも考えないといけないんだと分からされました。やっぱりエンジニアだからって、ソフトウェア関連の技術しか手を出さないと置いていかれそうだなと感じました。
最近、「会津大学教養学部」なんてイベントを開いて、心理学に手を出したりしていますが、間違ってないななんて思いました(笑)
「システムの一貫性に寄与する設計」（@acomagu）
いつも分かりやすくためになる説明をしてくれるacomaguさんが、今回は一貫性のある設計について詳しく話してくれました。今回は、いろんな層の人が来ることを意識してか、とても分かりやすい説明をしていただきました。
内容は、ほとんど忘れてしまいましたが、「イベントソーシング」の話がとても心に残っています。
確か、次のような話でした。
ウェブサイトのカウンターを考えてみましょう。直感的な手法では、アクセス毎にサーバー側上の変数に1を足すようにするでしょう。しかし、これでは同時にアクセスがあった場合、正しく記録できない可能性があります。そこで、イベントソーシングを使います。イベントソーシングでは、値を直接変えるのではなく、「何時にアクセスがあった」ことをデーターベースにログのように追記で記録します。これによって、同時に書き込みがあっても、データーベースから行数を数えることで正しいカウンター表示ができます。
最近、「とりあえず動くものを作るだけの人」から脱却しようと設計を意識するようにしているのですが、やってもドメイン駆動設計にするだとかFlux使ってみるだとか表面的な話ばかりで、実際のデータ管理の所までは考えきれていませんでした。今、間違えた場所を記録できるタイピングアプリのようなものを作っているのですが、実際に使ってみようと思います。
「Stripe触ってみた！ 〜Jekyll + AWS S3に組み込み〜」（Tokunology 徳納さん）
簡単に決済の設定から、QRコードを作成して投稿できるデモを見せていただきました。テスト環境ではなく、ちゃんと決済出来るようになっていてさすがです。
あとで、「Google Chart API」で簡単にQRコードを発行できることを教えてもらいました。僕が発表した「20時間で作る中古本プラットフォーム」では、下のサイトを使っていたのですが、表示に時間がかかり悩んでいました。僕の発表では、結構無計画なLTをしてしまいましたが、こんな話が聞けてLTやってよかったと思えました。誰かに見せるの重要だなとしみじみ感じさせられました。
「20時間で作る中古本プラットフォーム」（@gpioblink）
ここからは、僕がLTで発表した「20時間で作る中古本プラットフォーム」について説明していきます。
レシートプリンターを使いたかったこともあり、サーバーサイドは中古本書店のローカル環境でサーバーを動かす前提で作っていました。そのため、残念ながらデモサイトはありません。。ソースコードはこちらからどうぞ！(サーバーの方はまだしも、フロント側のコードは参考にしないでください🤐。とりあえずタイマー代わりに無限ループしてたりいろいろメチャクチャです。。)
最近、コードを書き始める前に、全体の設計を紙に書くようにしています。個人的な話ですが、これがあると自分がどこにいるかすぐに分かり開発効率が上がります。
今回は、こちらで紹介されているCleanMonolithアーキテクチャのサンプルコードを元に拡張していく形で開発を進めました。
そのため、設計の土台はサイトで紹介されている全体図をベースにして書き込んでいきました。
主に今回やったことは次の通りです。
- Printer関係のマイクロサービスを追加して、「決済済みの注文情報からレシートを印刷する」ユースケースの作成
- 決済プロバイダーのモックをStripeと接続できるように変更
- 決済完了時の副作用としてStripeのwebhookを受け取れるように変更
当初はこの3つの予定でしたが、StripeのCheckout時に送信するMetaDataをうまく追加できませんでした。そのため、Stripe側とサーバー側の決済情報を一致させるために
- サーバー側の注文IDとStripe側の決済IDを関連付けるデーターベースの作成と、使用するためのユースケースの作成
を追加で行なっています。
実際に20時間のペース配分がどうだったのか(予定では15時間だったが結局20時間していた)は、下のスライドでぜひ見ていってください。
うまくプリンター部分が完成しておらず、本番では謎の文字化けコードが出力されたりしていました。goからうまくプリンターが見えていないようで、execとかでとりあえず動くように急いでいましたが残念ながら間に合いませんでした。PHPやPythonにあるライブラリではうまく行くのですが。。同期のAndroidエンジニア@yt8492などから、この部分だけPHPで切り出せばとアドバイスをいただきました。マイクロサービス風の設計をしているので、これを思いつかなかったのはちょっと情けなかったです。。今度これを拡張した在庫管理アプリを作る予定なので、そこでプリンターを扱う部分を書く際に一緒に直したいと思います。
編集後記
最近、情報に溢れてしまうからとTwitterをあまり投稿したり見ないように個人的に制限をかけていますが、過去のイベントのログを取る意味ではめちゃくちゃ便利ですね！
ハッシュタグだけでイベントを振り返れました！！昔はLTのときだけTwitterする人とか名乗っていましたが、それも悪くないかもしれません。現在、Twitterをメンションか自分から発信したい内容があるときしか使わないようにしています。今後は、ちょっと範囲広めて、イベントの時は積極的に使って行こうと思います。
