■

・前日。
０９００：ミックスナッツ×２。
１２３０：鍋。
１５００：性欲処理。
１７３０：そぼろ＋ピーマン＋コーヒーゼリー。
１９００：ミックスナッツ×２。
２１００：普通のコーヒー。簡易デザートとしてのパルスイート入りコーヒー。ただ、それならココアとかの方が適切な気もする。無糖のココアパウダーが必要にはなるが、ココアバターもあるしインスタントなものとしてはなかなか悪くない気もする。ただ、ドーパミン系の問題を悪化させる懸念がある。
電解質：タブレット✕３と水分１．８リットル程度。
性欲：中～高。
筋トレ：肘膝腹筋２０×３回。

・予定。
結局ホームズに行く理由もなくなったので、明日以降はまたいつも通りかな。睡眠時間５時間に慣れていれば徒歩川崎したいが、そうでないなら近場での買い出しだけでも良いかもしれない。当日の朝に判断する形かな。

・通販。
今日の外出で見てきた感じ、なんにせよ低糖質のタレはあった方が良さそうだったので注文完了。ついでに一応また低糖質クッキーを注文はしたが、可能な限り我慢はしてもらいたい。が、ムリかなぁとも思う。というか「意志の力でどうこうしよう」というのは基本的に無理筋に見える。もっとシステム的に半強制的に実行されるようにした方が良いはず。

・カレンダー。
結局買って帰ってはきたけど、やはり置き場所に困るか。このサイズの資料は今まで持ってなかったからな。資料まわりも一旦整理したいところではあるが、他のに比べるとどうしても優先度が落ちてしまう。

・睡眠時間５時間。
少しずつだけど起きやすくはなってるな。

・予定。
とりあえず身体の方は動けそうではあったものの、目覚め用の動画まわりでわりと時間を食ってしまったのと、そもそも１２時あたりまで雨っぽくて外出したくない感じがあって９時の段階ではまだ出発保留中。一応、昼めしのうまかっちゃんもどきとかはすでにボトルに入れ済みだが。
どうするかな。ゴミ捨てもあるから早めに出かけたい感じもありつつ、やはり雨は面倒な感じもある。買い出しとかの用事は色々とあるけど明日の鍋の具材以外は今日中である必要はないし、鍋の具材も夕方とかの購入でなんら問題はない。ゴミ捨ても次の土曜まで保留にはできるし。とはいえ今月は早めの起床から９時あたりの出発まで一通り慣れていきたいところでもある。さりとて１０時前に出発しても近所の店は開いてはいないので近場で買い出しするだけってのもできない。
とりあえず１０時頃に近所で買い出しして帰ってくる想定でいくか。

・予定。
１０時少し前には出かける予定が普通に１０時半まで遅れてしまった。ゴミ出しは次回だな。
まぁ今日は雨もあったしまだ睡眠不足の影響もありそうなので仕方ないとしても、「何時に何をするか」をある程度固めておかないとズルズルと先延ばしになってしまうな。仕事に復帰する前の慣らし期間としてちゃんと仕事期間の挙動にちゃんと近づけていきたい。
となると当面の目標は９時に外出か。その時間帯ではほとんど店は開いてないので必然的に徒歩川崎と組み合わせる形になるかな。その時間帯の１時間弱の徒歩で問題なければ電車での１時間弱も体調は崩しづらくなるだろうし。
それ以外はまぁフリーか。向こうで散策しても良し、買い出しだけしてすぐに帰ってくるも良し。

・フロー２。
PIXTA側に追加で投稿してたやつが一通り通った。こっちの投稿はもう引っかからなさそうかな。となると後はAdobe側がどうなるかといったところ。

・Unity。
今日もちまちまと作業していこう。
複数フレームに分割して処理を実行するとなるとModel側の処理もそれを考慮して書かないといけないが、処理落ちするのはプラットフォーム依存の話なのでModelで書くべきではないんだよな。で、ちゃんと別スレッドで実行することができれば一応処理落ちはせずに済む。ということで、そもそもUnityで処理落ちしないような完全に別スレッドの処理が書けるのかの確認から、できそうなら設計あたりまでをまずはやろうか。
別スレッドはできるっぽいな。シンプルなLog出力の無限ループを別スレッドで実行できてるっぽい。ただ、このままだと使いづらいからここでUniRxだのUniTaskだののスレッドの話が出てくるって感じか。今回はどっちを使おうかな。最近だとUniTaskの方が良いっぽいが、UniRx自体への慣れにもなるのでUniRxでも悪くはない。まぁまずは一旦設計の方を先にやるか。
処理の流れとしては「入力の受け渡しを行う（LateUpdateのタイミング）」→「全ユニットのパス計算」→「描画に反映」という感じ。この中のパス計算が衝突判定とかを何度も行う都合で１フレームでは処理できない感じ。
ざっとだけ調べたが、スレッド内で「LateUpdateのタイミングまで待つ」みたいな処理もできるっぽいな。であれば、LateUpdateのタイミングで毎回スレッドを生成するのではなく、１つをスレッドで回し続けることは可能か。重要なのはそれらの処理が一式終わるのを待ってから遷移しないと困る場面もあるってところかな。外部から制御しても良いが、どうせこのループで入力を見るんだから処理の最後で入力を見て必要なら遷移を行う形にするか？あるいは遷移まわりはどこか別の一箇所にまとめた方が良いか。まとめた方が良さそうかな。遷移待機中は他の入力は無視する対応とかも必要そうだし。

・昼寝。
作業中に眠気っぽいのを感じたので横になったらそのまま２時間ほど寝てしまった。まだ今の睡眠に慣れてないっぽいか。今週いっぱいはかかるかなぁ。

・Unity。
処理の制御についてあれこれ考えてるが、２つのフェイズには２つのPresenterを用意して切り替える形が妥当だろうか。構図としてはエディットモードにおけるUIのポップアップ的な重ねての表示に近く、そちらの場合はUIごとにPresenterを用意するはずだからな。そうなると、モードごとにRoot的なPresenterを用意し、その中のフェイズごとにさらに個別のPresenterを用意するのが自然に見える。切り替え方だけスタック式とスイッチ式でちょっと違う形になりそうだが。まさかフェイズを切り替える程度でPresenterを何度も生成し直すわけにもいかんし。別にやっても良いがムダではあるよな。
というわけで複数のPresenterの管理について今のうちに対応しないといけなさげ。スタック式はまぁTopだけ実行すれば良いとして、スイッチ式はどうするかな。スタックのを流用して片方だけスタックに乗せる形が妥当？あるいはそのままswitch(phase)で呼び出すのを変えるだけにするか。何をどれくらい流用・継承するかにもよるな。
毎フレーム実行する処理を持つならPresenterもMonoBehaviourにしないといけないか？と思ったが今回はUniRxのEveryUpdateとかがあるんだったな。あるいはTaskのループで実現しても良い。ここの選択の幅も出てしまったので考える必要があるか。
まずそもそもの処理の開始地点から考えるか。PresenterはViewと同時に生成される、というかサンプルではViewのコンストラクタで生成される。ので、その画面の開始地点はそのPresenterのコンストラクタになる。画面全体のPresenterはそこからすぐに実際の処理をUpdate的に回す処理を開始して良いが、その中のサブPresenter的なやつは必要な状況に応じてのみ実行される必要がある、はず。たとえばスタック式ならTop以外の処理は抑制されないといけない。その意味ではサブPresenterはPresenterを名乗らない方が良いか？でも処理の実態はそちらではある。しかし少なくとも「サブ」とかは名前に付けて明確に区分けする必要はありそう。
スタックとかを持つ場所は画面全体用のPresenterそのもので良いか。会社だったらここらへんは継承したりそれ用の処理を行うやつをメンバーとして保持したりする方が良さそうだが、今回の個人開発のレベルならそこまでする必要もないだろう。ただ、生成・破棄とは別に処理開始・処理終了の呼び出しは（特にスイッチ式において）必要になるので、そのインターフェイスとかは必要かな。しかしそれはサブ側だけにするべきかメイン側とも共有すべきか。そもそもメイン側のそこらへんの処理は誰に呼ばせるのか？という話もあるし、メイン側はその画面が続く限り永続なので生成・破棄のタイミングで開始・終了を行うだけで良いはずだしそうあるべきだろう。となるとサブ側だけで良いか。
というよりは別の捉え方になるかな。すなわち「ポーズ」と「ポーズ解除」。メイン側がポーズされることはないが、サブ側はスタックやスイッチでポーズ・解除されることがある。ここらへんは「ポーズによる開始なのか生成直後による開始なのか」を引数で渡しても良いが、普通に生成・破棄とポーズ・ポーズ解除を別関数で用意して良さそうかな。その意味ではPausablePresenterという名前のインターフェイスを用意するのが適切だろうか。将来的に「メインでも使いたい！」となった場合にはSubとか付いてるとリネームが必要だが、Pausableなら実態を表してて特に変更の必要はなさそうだし。
睡眠慣性はだいぶ解けてきたかな。とはいえなんか腹が減ったので休憩がてら夕飯を食ってから実装に入るか。どちらのタイミングとしても悪くはないし。

・ローストビーフ。
久々に食ったがまぁまぁ良さげだな。今回はオーストラリア産のを買ってしまったが探せば国産のはありそうだし。まぁ牛肉であることと全体食ではないことと野菜がないことが多少の問題ではあるが、他に食うものがなければこれで良さそう。割り箸とかがあれば向こうの昼飯としても食えそうだし。
むしろ単品だと辛さとかがないぶんコーヒーゼリーとの相性がさほど良くないな。うまかっちゃんもどきと順番を逆にしたい感はある。まぁローストビーフはまたしばらく食う予定はないが。
しかし次の肉は何にしようか。低温調理も試したいがタレが届かないとちょっと試しづらい。まぁ１回くらいタレは自作しても問題はないが、一応他のレパートリーも調べてはおきたいか？一応、改めて見てきたらいけそうなのもなくはなかったし。まぁ土日の味噌豚とかぶったりしそうな感じなので微妙そうでもあるが、試してないのに断定するのもそれはそれで微妙だしな。

・Unity。
というわけでゲームモードの方のスイッチ式は仮実装完了。まぁスイッチ部分だけだが、これで問題なさそうな感じは得られた。
で、あとはTaskまわりだな。ここさえ実装できれば今日はもう終わりで良いと思う。で、どうするか。
ひとまずUniRxのままいくか。会社でUniRxの方を使うならそれで良いし、UniTaskの方を使うなら差分を見てUniTaskの有用性も感じられる。
ここで改めてAddToの問題が出てくるか。やはりPresenterのコンストラクタにViewを渡してもらうか。なんか相互参照っぽくて若干の気持ち悪さがあるが、実際には別に相互参照にはなってないはずだしな。いや、そうか？View側がPresenterを持っていて、Presenterの関数をObservableだかなんだかが持っていてそれがViewの寿命に依存していて、であれば結局どちらもView側が持つような形ではあるか？まぁ一旦はこの方向でいくか。もしProfilerとかで画面遷移のたびにメモリが増えたりしてるようなら改めて対応するってことで。
というわけで引数にViewをもらってAddToする方向で実装。タスクもUniRxの書き方でわりと簡単に書けた。Startから直接AddToは書けず、Subscribeを挟まないといけないのがまだよくわかってないが。Select→Subscribe→AddToみたいな感じの形式の１つって感じか？返り値が違うのはまぁわかるんだけど、感覚的にどう捉えれば良いのかがまだちょっとわからん。理屈というよりはもう少し使って馴染まないとダメそうか？
ともあれスレッドをAddToで自分自身と一緒に破棄できるようになったので、メイン側はこれで問題ないな。
いや、メイン側のスレッドはそれこそメインスレッドで実行して良いか？少なくともメイン側をサブに移す理由は特にないっちゃない。まぁメインでやる理由もないっちゃないが、Instantiateとかはメインスレッドでしかできなかったりするので、基本はメインスレッドで良い気がするな。サブPresenterの方でさらに別タスクを回せるならなおのこと。一旦メイン側はメインスレッドで回すように書き直すか。
というわけで書き直した。Startの引数の変更とかじゃないのが少し気になるが、まぁ個人開発ならこれで特に問題はないか。
あとはサブ側だな。
サブ側のTaskをどうするか。Task自体は常に存在させておいて必要な時だけ実際の処理が行われるようにする？あるいはポーズ解除のたびに毎回Taskを生成する？どちらも微妙には見えるが、意味論的にも管理的にも後者の方がマシではあるか？
Observableの状態だと外部から止める手段がない、か？そもそも何かしらがSubscribeでくっつかないと動く必要自体がないしな。つまり、Subscribeの方を解除すればそれだけで実質的に削除にはなってる、のか？ここらへんは内部構造的な話になるのでただ作ってるだけでは理解は深まらなさそう。RxなりUniRxなりについてもっと調べる必要があるか。ただ、今日はもうそっちまで調べる時間はないな。
とりあえず今回はDisposableをメンバで保持しておいてOnPauseの段階でDisposeしてしまう方向で実装。
ひとまず今日はこんなところか。明日は改めてUniRxのSubscribeとか寿命まわりとか上記に関連する部分を調べつつ、残りの接続を進めていく感じかな。しばらく休憩したらフロー２に戻りたいが、ここで動画を見るとたぶんまた引きずられるんだよなぁ。どうしたもんか。まずは無思考で休もうとは思うが。

・フロー２。
最近何も作れてないので多少の焦りが見えるが、重要なのはあくまで仕事期間でも安定した作成を続けられること。そのためにはネタ出しを安定させるのが良いし、そのためにはネタやその事前の段階を今のうちに十分詰めておく方が良い。なんなら今週いっぱいは何も作れなくても良いまである。
代わりにちゃんと詰めはしないとな。一旦の理解は深まり、それをもとにしたネタ出しは一応できてるが、まだ全体的にぎこちない。あと何度か螺旋を回らないとスムーズにはいかない感じ。
で、今のフェイズはネタ出しをもう少しやる感じかな。それで現状のを出し切ったら改めて理解とかを進める感じになるか。まぁネタ出しさえできればラフ～SD回しとかもできるので焦りの解消にも一応役には立つ。そっちは本題ではないが。
しかし今のモードだとネタ出しが難しいな。プログラミング寄りだと難しいのか？あるいはしばらくネタ出しから離れてたから戻るのに時間がかかるのか。
そうなるとできるところからやるのが結果的に早くはなるかな。どんな形であれ情報が入ってくればネタ出しはしやすくなるはずだし。