■

・前日。
０９４０：朝の。朝から補中益気湯を入れたかったので、ついでに朝食も摂取。朝食はたぶんどのタイミングで摂取しても今のところ体調への影響は特に変わらなそうだから好きなタイミングでやるか。
１２００：鍋＋スロージューサー。
１５００：ステーキ。
１８００：間食。
２０２０：マンナン米＋カレー＋スロージューサー。

・個人開発。
あれこれやってはいたんだけど、その中で「これが作れれば確かに金になりそうだなぁ」というのは思いついたんだけど、いかんせんサーバサイドの対応が必要になるんだよなぁ。そろそろ観念してサーバサイドを真面目にやってみるかぁ。今までもちょっとしたレスポンスを返す程度のことはやったりしたけど、その程度では苦手意識は払拭できなかったしなー。コレが作れるレベルになれば他のこともそれなりにできるようになるだろうし。
とはいえ今の自分が作るとなると半年はかかりそうか。逆に言えば半年で到達できそうならやる価値は十分にあるかな。コンテンツじゃなくてサービス系なので継続的なフローが期待できるっちゃ期待できるし。
ということで、サーバ系の書籍が色々と欲しいな。まず基礎の時点からできてないからな。

・睡眠時間６～８時間くらい。
やや寝つきが悪かったが、原因はわかってるのでまぁ良し。寝る前にサーバ絡みのあれこれを思いついてしまって「利用規約とかも学ばないといけないのかぁ」とかなってしまってた。まぁ急ぎじゃないからゆっくり確実に学習をしていけばちゃんと辿り着けるはずではある。利用規約とかまで考えるとさすがに半年じゃキツそうだが、まぁ今年いっぱいかけるつもりならいけそうではある。

・サーバ。
今までの「家」と「金」の学習時間をサーバに充てれば良さそうかな。土日であれば個人開発の時間も充てて問題ないし。まぁ個人開発は他のネタ出しとかもした方が良さそうだが。サーバだけじゃなくて、この機能を使ったコンテンツも作らないといけないし。
機能そのものはそこまで複雑じゃないし、「他の誰も作らなそう」というレベルのものではないものの、なんにせよ自分が欲しいし先に誰かが作ったとしてもそれを使えば良いだけ＆サーバの学習自体はムダにはならないので進めていこう。
とりあえず改めて基礎からやっていきたいが、そもそも基礎項目を何も知らないのでそこからか？ただ、基礎から順番に学ぶのってつまらなくてキツいんだよな。まず目指すサービスに必要な項目から調べていって、そこからトップダウン式に必要な基礎を見つけてそれの学習を進めるか。
必要な機能は「お金を受け取る」のと「お金を振り込む」処理かな。あとはその前提としての「認証」があり、クライアントに情報を渡すための「JSON出力」やら「ストリーム？」あたりが必要になる。今日中にここらへんをざっと調べてみて、明日はまた別の本屋に行って美術書とかと一緒にサーバ系の本を探してみようかな。

・サーバ。
というわけで必要なものを調べていく。
「DB」も要るんだったな。ただ、これはその手のサービスもあるのでどこまで自分でやるのかもよくわからん。最近だとどういうサービスがあるかもわからんからな。ここらへんは軽く設計してからサービスを調べて何をどう簡略化できるかを調べた方が良いか。
ひとまずPayPalで支払う方法を調べてるが、対応する書籍はなさそうだな。APIが公開されてるのはわかってるので、こっちをサーバから呼び出す方法を調べる感じになるかなぁ。「REST」とか以前に調べた気がするがすっかり忘れてるので、まずはここらへんからかなぁ。
「サーバレス開発」とか初めて聞いたな。ここらへんの開発環境はここ１０年くらい追えてないので、改めて調べ直さないとな。
「セキュリティ」もそうだな。必要だな。これが加わるとなると今年中にいけるかどうかが怪しくなってくるが、まぁやらないわけにはいかないしな。
ここまでのを大雑把にわけると「環境（開発環境～実際に動かすサーバまわりの環境）」「技術（認証、API、セキュリティ、etc.）」「規約」あたりになるか。このサービスそのもののクライアント側も必要になるが、今は一旦置いておくか。しかしクライアント側を固めないと呼び出し方も固まらないか？やはりいつものように螺旋のように「全体を大雑把に把握→一つ一つ見ていく→改めて全体を把握→一つ一つ見ていく」を繰り返すしかないだろうか。
じゃあ一旦今回のサービスの流れを洗い出すか。

・サーバ：フロー。
０：クライアント側で初期設定を行う。（できるだけ簡潔なのが望ましい：専用アカウントじゃなくて他のところのアカウントが使えるとベスト）
１：クライアント側から入金指示を行う。（他にも色々と情報が渡ってくるが、なんにせよここで通信）
２：なにかしらのセキュリティチェック？（APIに丸投げで良いのかどうかもわからん）
３：まずはクライアント→自分のとこに入金
４：自分のとこ→該当のユーザに出金（上記でそもそも分岐させた方が良いのかどうかもわからん。ここは法律寄りの話になるんだろうか？）
５：上記フローが正常に行われたらコンテンツの方にコールバック（紐付けまわりをどうするかが固まりきってないというか手札をそもそも把握してない）
ひとまず大雑把にこんなところか。わからないことだらけではあるが、何をすれば良いか自体はわかってるので、あとは手札とか情報を調べるだけではあるな。お金の出し入れが２回あるので、片方こけたらどうするのか？みたいなエラー処理の問題もあるので設計を詰めるべきところもあるが、これもまた情報次第か。
とりあえず最初から順にやっていくかな。まずは「PayPalを使って独自のユーザ名を登録し、該当ページに来たらそのユーザ名が表示される」くらいの処理ができると良いかな。これだけでもすでにAPIと独自DBの話が出てくるし、最初の難易度的にはちょうど良さそう。

・サーバ：初期設定。
PayPalのアカウントとかを使うのは良いとして、そこから何をどう受け取ってこちらの情報と紐付ければ良いのか見当がつかない。
というわけで、まずは「自動ログイン」あたりから調べてみるか。これを他のサービスのアカウントでできればそれでいけるはずだし。
「Cookie」が出てきたな。そしてそうなると例のアレの表示もしないといけないのか。基本的に自分とは無関係だったからちゃんと調べてないが、アレもちゃんと調べないとなぁ。
「セッション」がまずわかってないな。文脈からぼんやりとどういうものかは推測できるが、ちゃんとした認識ができてない。
「トークン」もそうだな。ゲーム的な意味でのトークンしか知らない。実際には大学で見かけた単語な気もするが、なんにせよ記憶にはない。
そして自動ログインだと「他のサービスのアカウント」とかとは関係なさそうというか、クライアント側からは自動ログイン用のキーを返すだけになりそうなので、今回の実装にはちょっと足りないな。
というわけで「他のサービスのアカウント」でググったら「ソーシャルログイン」という単語が出てきた。たぶんこれだな。
たぶんこれっぽい。そしてなんか想像以上にLINEアカウントでのログインって多いんだな。決済まわりがいけるようならこれで試すのが良いか？
こう見てると決済手段とログイン方法自体は分けた方が良いか。ていうか、そうなってくるとログイン自体が不要でもあるか。支払う側はそれで十分だしな。受け取る側は何かしらの設定が必要になると思うが、それもそれでソーシャルなのでなんとかなればなんとかなるし。
決済の方法は色々と見つかるが、自分から誰かに入金する処理まわりはなかなか見つからんな。銀行のAPIとかあったりするので、これで自前でやるか？リスク的にあまりやりたくないが。
既存サービスを参考にしてみるか。skebとかたぶん入金も出金もしてるよな。
skebはTwitterでログインか。そしてクライアントとクリエイターでそれぞれクレジットカードと銀行口座を指定する形式、と。これは確かに個人で管理するリスクは高いな。ただ、個人でもここまではいけるという話でもあるか。しかし自分の想定ユーザ層はどちらももっと若いので、やはり別の方式が欲しいところではあるな。
ここからはどうするか。一旦skebと同じ方式を考えてから他の支払い方法で置き換える方法を検討するか、最初から他の支払いでの設計を進めるか。
なんにせよサンプルがないと作りづらいか。まずはサンプルを探してからだな。
今日はそろそろ終わりにしたいが、この状況だと買う書籍の絞り込みが難しいか？こんなピンポイントな部分の書籍ってあるだろうか。あるいはどうせ書店にわざわざ行くのであれば、適当に関連しそうなものを見つける感じでいくか。

・本屋。
どこ行くかな。紀伊国屋に行こうかと思うんだけど、川崎の外れの方に行くか、横浜方面に行くか。
横浜の方が土地勘はあるが、メシを食うアテがない。
川崎の外れは外れなだけあって電車でもちょっと徒歩が多くて遠い。どうせ歩くなら普通に歩いて行った方が普通の川崎駅より少し近いまであるし。こっちもメシのアテはないもののそもそもどういうのがあるのか知らないので確認しておきたい感じはあるか。こっちに行ってみるかな。

・サーバ。
今日の最後にまとめておこうか。
アカウント管理と支払いは別にして良いってことは、アカウント管理の方はGoogleアカウントを使えれば良さそうかな。
支払い方法に関しては未定。自前でクレジットカードの情報を保持するのは個人じゃリスクが高いので、できれば決済サービスを使いたいところ。使う決済サービスはわりとなんでも良さそうだが。
こっちからの支払い方法の手札が少ない。というか銀行口座をもらってもどう支払えば良いのかがわからん。まさか手作業じゃあるまいし。APIが用意してあるところもあるにはあるが、企業用のAPIじゃないとムリそうだったりしてよくわからん。場合によっては会社を作らないといけないのか？そこまでいくともう本当に今年中じゃムリそうだが。
そもそもDBは要るのか？というあたりもある。ユーザ名とかは最悪各自のCookieとかに入れておくこともできるし、それ以外のパスワードとかは全て決済サービスとかに押し付けることも不可能ではないのかもしれない。なんにせよ使うにしてもそこまでがっつりってわけではなさげ。
ひとまず重要なのはこんなところか。「認証」と「決済サービス」まわりをまずは重点的に調べていきたい感じかな。