■

・前日。
０９００：ミックスナッツ×２。
１２００：鍋。
１４００：昼寝１時間。睡眠慣性やや強め。
１７００：そぼろ＋ピーマン＋コーヒーゼリー。
２０００：ミックスナッツ×２。
電解質：タブレット✕３と水分１．８リットル程度。
性欲：低～中。
筋トレ：腕立て１０×３回。起床の時点で右腕がちょっと痛かったが寝てる時の姿勢の影響っぽくて昼以降は特に痛みがなかったので腕立てはやっておいた。

・睡眠時間６時間。
４～５時間のところでたぶん目は覚めてるんだけど早すぎるので二度寝したところ合計６時間くらいのところで目が覚めた、はず。ほぼほぼ記憶がないので以前の状況とごっちゃにしてるかもしれない。
ともあれいつもより起床時刻は遅かったものの６時間睡眠なのもあってかやや起きやすくはあったかな。まぁそれよりはやはり事前に用意しておいた「起きた後用のタイマー」でちゃんと区切りをつくって朝のあれこれの作業ができたのが大きいとは思うが。

・睡眠。
最近は寝つきの良さがだいぶ安定してるので一応メモしておくか。
寝る前の眠気は特に寝づらかった頃と変わった印象はない。さらに言えば別にそんなに眠くない時すらある。
一番変わったのは横になって目を閉じた後の思考量かな。あれこれ考え続けるようなことがなくなった。瞑想の効果のようにも思えるが、体感的に一番大きいのは睡眠時間を減らしたことなんだよな。単純に睡眠時間が減ったこともそうだし、「睡眠時間が少なくても良い」と心の底から思えるようになったのも大きいと思う。睡眠時間に問題があると考えれば考えるほど寝づらくなってる感じがあったし。
なのでまぁ寝つきに問題が発生することはそうそうない気がするし、仮に発生したとしても横になってから２～３時間寝れないとかじゃない限りは問題視する必要すら感じない。まぁ日中に寝れる環境があるかどうかも結構重要に感じるし、リモートワークじゃない状態では結構キツそうかなと思うが。なのでまぁ今後の仕事期間で睡眠まわりに問題が発生するとやや困るかもしれない。そのためにも現時点で短めの睡眠時間で安定させたいところ。

・メシ。
今日のメシは「うまかっちゃんもどき」と「肉系の惣菜」にする予定ではあるんだけど、コーヒーゼリーとの相性を考えるとうまかっちゃんもどきの方はやはり夕方にしたい感じはある。しかしそうなると惣菜は朝のうち、あるいは前日の夜とかに確保しないといけないんだけど、仕事先の周辺のスーパーに大きく依存するのでいけるかどうかわからんな。３度行くつもりはなかったが、最終チェックのために改めて９時出発で派遣先の近所を回ってみても良いのかもしれない。つっても行く先は後は会社とは反対方向の近所にあるスーパーくらいだけど。
それよりは「うまかっちゃんもどきに胡椒を入れない」とか「逆に惣菜系には胡椒を足したりしてみる」とかの方が良いか。まぁすでに今日のうまかっちゃんもどきはボトルに胡椒と一緒に詰め終えてしまってるが、惣菜系に胡椒を足すのは今日からでもできるか。
でもまぁ来週からは低温調理肉も試せるし、そっちは低糖質タレを使うことになるので結局またコーヒーゼリーとの相性は悪くなるか？あるいは今回のタレは辛めになるだろうか。なんにせよ試すまではわからんかな。仕事期間のメシであと決まってないのはこの部分だけなので、早めに確立してしまいたいところ。

・外出終了。
今回は道中ちょっと眠気が強かったな。今日は６時間睡眠だったから問題ないかと思ったが、睡眠時間の影響はやはり当日ではなく翌日の方に出るのか？
で、ここ１週間くらいずっと下痢気味で最近はちょっと悪化してきたので正露丸を買ってきた。体感的には気温が低くなった影響のように思えるが、タイミング的には睡眠時間を減らしたあたりからなので自律神経まわりの問題経由で睡眠不足が原因な可能性も否定できない。あとは前々回の鍋の豚肉の火の通りが悪かったのでそれの影響とか。正露丸を飲んでも治まらないようなら断食も一考かな。
しかしまぁ走る時にお尻がププッピドゥしそうになるとは思ってなかったな。想像以上に尻が緩むか。室内でも普通に座るポーズだと事故る可能性があるのでできれば寝転がりながら作業したいが、今の状態で寝転がると眠気に押し負けるかもしれない。しかし事故るよりはまだマシか。

・惣菜。
仕事期間を想定して買ってきたが、いけそうなのは「焼き鳥（パック）」「パストラミ」「サラダチキン」あたり。油や糖質の質を考えなければ「炙り焼きチキン」もある。候補自体は色々とあるし閉店時間も２３時間だから売れ残りづらくはありそうだが、野菜の摂取がないのが難点ではあるかな。まぁもともとが焼き鳥の全体食想定だったから、それと比べれば悪くもないかな。特に上で挙げたやつは１つだけではたぶん足りないので、２つくらい買うから結果的に全体食寄りにはなる。

・スクエニ。
このまえさっと書いたのを思い出したが、よくよく考えると「FFをもう買うことはない」ってのはだいぶ前からだったが「スクエニそのものに期待しない」ってのはわりと最近のことなんだよな。
で、いつ頃からだろうと考えてたけど、チョコボレーシング（GP）が出る前はまだ「お布施を兼ねて買おうかな」とは思ってたのを覚えてるし、その後の評判で結局買わなくなったのも覚えてる。スクエニに期待しなくなったのはそのあたりからかな。

・Unity。
というわけでエディットモード方面の作成から。
で、モード切替もフェイズ切替と同じ処理にしてしまうか。となると、画面自体のPresenterもまたさらに上位のRoot的なPresenterによってPauseされたりResumeされたりする方向で進めてみるか。なので、Root以外は全てPausableのインターフェイスを継承する感じ？
ただ、その場合はRootPresenterに対応するViewが実質何もない、か？あるいは「何も表示しないシーンの空のオブジェクトにアタッチされたView」と対応付けるか。
あと、「子供は誰が作るべきか」というのがあるな。UIベースで考えると「そのUIが生成される際にViewもPresenterも作られるべき」なような気がしつつ、しかし実際には事前にPresenterを用意しておいた方がやりやすい場合もある。改めてUnityにおけるMVPの定義に戻ってくると「Presenter：画面に依存するがプラットフォーム（Unity）には依存しない」なので、インスタンス化処理はView依存な気もする。Newで作られるのかInstantiateで作られるのかはプラットフォーム依存だしな。少なくともフロー自体はPresenterでやったとしても生成処理自体はView側でラップする必要がある。サンプルとか見てもそんな感じっぽいしな。
ただ、そうなるとPresenterが真に切り替えるべきは子供のPresenterではなくそれに相当するViewの方なのか？Viewも同様にPausableのインターフェイスを用意する？
より厳密に言えば「作る」ではなく「持つ」方が問題か。作るのはまぁViewで良いが、「親Viewが子Viewを持ち、親Presenterが子Presenterを持つ」として、そこでさらに「Viewが自分に対応するPresenterを持つ」ならそもそも親Presenterが子Presenterを持つ必要性がない。が、持たないとPresenter側が子供を制御するには自身に対応するView経由でその子供を取得、、、しなくて良いのか？切替処理自体をViewに持たせて、Presenterからはそれを操作する？そもそも切替処理自体はどちらが持つべきだ？
改めて定義を見返せば切替処理はほぼ「機能・表示のオンオフ」ということだから、Unity依存というよりは処理に近い。ので、Presenter側がやるべきかな。View側で用意するのはオンオフ本体だけで、実際の切替処理はPresenter側で行う。となるとやはり子の取得自体は必要か。
うーん、しかしサンプルでは親Presenter的なものが子Presenter的なものを作ってる場面もあるか。そしてそれを後からViewに渡してる。
そもそもPauseとかは直接関数を呼び出すのかSubscribeを経由するのかという問題もあるか。どれくらいオペレータベースにするのが良いのか。SubscribeでViewもPresenterも同時にオンオフみたいなことをするとして、そこの処理順序が不定になるのは良いのか？という話もあるし。
想定していたところとは別の部分でだいぶ時間がかかってしまってるな。まぁこれはこれで仕事期間でも「オペレータをどれくらい使うべきか」というあたりで役には立ちそうだから学習としては良いと思うが。
方針の１つとしては「View同士」あるいは「ViewとPresenter」などはお互いに関数などは呼ばず、必ずSubscribeのような形を経由して変更し合う、というのが考えられる。結合をできるだけ疎にする方向。方針の１つとしてはアリだと思うが、上記の順序などを考えると「親View→子View、子Presenter」みたいなSubscribeはなしで、「親View→子View→子Presenter」みたいな接続にしないといけないか。実行順序に関しては素直な関数呼び出しの方がわかりやすそうではあるかな。
あとそういや「ステージ」自体も別Viewにする必要があるのか。ゲームモードでもエディットモードでも使うがタイトルとかでは使わない「ステージそのもの」に対応するView。なので「ステージView＋ゲームView」や「ステージView＋エディットView」みたいな形で２つのViewが同時に存在することがある。UIのポップアップに似てるっちゃ似てるが、こっちの場合はどちらも有効な存在ではあるんだよな。
となるとPresenterも２つ同時に存在することになるか？それはちょっと微妙な気がするんだよな。Viewが２つ存在する想定までは良いと思うが、実際のフロー制御に関しては１つで問題ない。となると、ステージViewは誰が生成してどこで管理してPresenterからはどう触るべきか。
初めてMVPを適用するにはちょっと特殊な事例だったか。とはいえ練習台にはちょうど良いのに変わりはないか。今日は設計を詰めるだけで終わりになるかもしれない。
あー。「ステージViewとゲームViewが同時に存在する」んじゃなくて「ステージViewのモード（子）としてゲームViewとエディットViewが存在する」と考えると色々な辻褄が合うな。Presenter側としても表現しやすくなるし。となるとなおのこと「親子管理はどうあるべきか」「関数呼び出しとSubscribeはどうあるべきか」が重要にはなってくるが。
思考だけではどうにも手詰まりな感じが出てきたので、改めてMVPの解説を読み直してみるか。
少なくとも「ModelとPresenterの結合はSubscribeなどを利用した疎結合」重視だな。
というかあれだ。そもそもアセンブリの切り方的にPresenterはViewが見れないんだったな。なので必然的に疎結合となるしかないのか。ここらへんの依存関係がまだちゃんと理解できていなかったか。
今までの自分の書き方的には「親View→子View→孫View」「親Presenter→子Presenter→孫Presenter」という感じで親が常に子を生成させたいんだけど、ViewとPresenterを対応付けるためには「View→Presenter」が全ての対で行われた方がラクではある。で、そこに「親View→子View→孫View」をつければ最低限の対応付けは完了。問題は親Presenterがどうやって子の切替を行うか。
まず、子Presenterを切り替えると同時に子Viewも切り替えないといけないので、PresenterからViewを切り替えるために少なくともSubscribe的なことはしないといけない。であれば子Presenterの切替も同じくSubscribe経由にしても特に問題は生じない。
例えば雑な名称として「ChangeChild(childIndex)」というのを用意してみるが、それでSubscribe的な接続をするとなるとまず「親Presenter→親View」への伝達が発生する。で、親Viewは渡ってきたchildIndexをもとに実際に子Viewの切替を行うわけだが、これはまぁ関数呼び出しでもSubscribe経由でも良い気はする。で、子が切り替えられた際にそのコールバックで対応するPresenterもオンオフすれば親Presenter→子Presenterの接続が成立するし、実行順序も保証される。であればひとまずはこの方向で良さそうか。
ということで一旦この方向で実装を進めたいのだが、たぶんその前にフォルダ構造を変更した方が良いな。GameとEditの上にStageが挟まるようにして、その変更だけで一旦コミットしてしまいたい。差分的にはこれが新規ファイル扱いになるから、一旦コミットしないと差分が見えなくなるし。
あぁ。フォルダ構造を変えたからVSで開いてたファイルが一通りエラーになったか。まぁ仕方ないか。
粛々と進めているが、ReactivePropertyの初期化時に設定した値ってその後にSubscribeされたところにもちゃんと通知されるんだろうか。されるとしてそのタイミングは？サンプルを見る限り通知される想定の書き方に見えるんだけど。今のところ初期化の都合でそうならざるを得ないんだけど、もし思ったような挙動になってなかったらここは書き直しかなぁ。
うーん。「Root→Title,Stage,Option」「Stage→Game,Edit」みたいな形で子View・Presenterを持つのは良いと思うんだけど、であればさらにその下の「Game→Simulate,Exec」も同様に子View・Presenterの形式で持った方が良いのか？少なくとも子Presenterは持つわけだから子Viewも持たないとおかしくはあるか。ただ、そうなると誰がどの処理をするかもちゃんと仕分けする必要がある？というか、Update系のタスクが複数同時に走るのはマズそうだからStageもGameもPresenterではUpdate的なタスクは持たず、Simulate,Execのような末端のみがUpdate的なタスクの実体を持つ形にするべきか？そんな気はする。まぁViewというか画面構造自体はそれぞれが担当するものを持つ必要があるとは思うが。
あー。Presenterが直接子Presenterを生成しない都合で入力のObservableを渡せないか。となると、Subscribe経由で渡すか、あるいは子に所持はさせないでSubscribeだけ登録できるようにするか。たぶん後者の設計が良いんだろうとは思うので、その方向で検討してみるか。
うーん。Viewで接続していくしかなさげだが、これってViewの管轄か？まぁ入力まわりはサンプルでも「PresenterでもViewでもどっちでも良いっちゃ良い」という感じの扱いになってはいるから間違いってわけではないのかもしれないが、なんかしっくりはこないなぁ。まだViewを「見た目」として捉える意識が強いせいも大いにあるとは思うが。
そういや今の状態だと十字キーと決定ボタンとかの同時押しは抑制してないしするべきでもないとは思うが、それはそれとして同一フレームで実行された場合に「決定処理→十字キーによるカーソル移動」などが発生すると困りはするか。
「親View→子View」や「View→Prefab」みたいに所有している相手に対しては直接関数を呼んで良いのかなぁ。というか、無理矢理相手に登録させる関数を用意したところで、やっていることが同じだからなぁ。サンプルを見る限り普通に呼んだりもしてるのでまぁ今回は普通に呼び出すか。
とりあえず構造を一通り今回用に変更して入力がちゃんと届いているところまで改めて確認。そして、先にReactivePropertyとかを初期化したあとにSubscribeを登録してもちゃんと通知が届いてるっぽいのも確認。少なくとも今回の設計で初期化順序は問題なさげ。
あとはこの状態で改めてモード変更の処理をやれば良いわけだが、もう１７時か。ざっと考えたが「子Presenter→子View→親View→親Presenterの入力」的な逆流＝Subscribe設定が必要で少し時間がかかりそうなので続きは明日かな。子から親に逆流するからChangeChildよりはChangeViewとかの名前の方が良さそうか。というか子供が変更先を知っている必要があるのか？という問題もあるし、そこらへん含めてまた明日。

・フロー２。
昨日繋いだやつで改めてネタ出し。
まぁまだスムーズにはいかないというか、改めて難しい部分に直面したりしてる。でもまぁ時間をかけて考えればおそらく突破できるレベルだし、今のうちにあれこれ考えておけば仕事期間でバリエーションも出しやすいだろうし問題はないかな。

・パワーナップ。
今日はやはり寝転がりながらの作業になってしまい、がっつりとした睡眠というよりは軽く休んだ際に１～２分ほど寝てしまってそれに気付いて起きて、それで多少眠気が改善されたので作業したり二度寝を試みたが上手くいかないという感じで、数分の睡眠を２回やった程度になった。
まぁ時間換算では特に問題はないんだけど、もう少しちゃんと寝ても良かったかな。ただ、下痢の問題もあったので昼寝をちゃんとするのがなんか難しく、その流れで夕寝も難しかった感じ。下痢の感じは後半にはだいぶ良くなってたんだけどな。