・前日。
０５００：起床。
０８３０：二度寝。３時間くらい。
１９００：ミックスナッツ×（２＋２）＋大豆プロテインバー。ミックスナッツは２つだと低代謝になりかねないかなと思ってさらに２つ追加。
電解質：タブレット✕６と水分１．８リットル程度。下痢と断食につき電解質はちょっと多め。
性欲：低～高。
筋トレ：スクワット１０回程度。まぁ今日は変なことしてダウン寄りになっても困るので軽めにやっただけ。
・体調。
晩飯直後は立ち眩みが出たり、１～２時間後には吐き気の手前のような気持ち悪さがあったりしてまだあまり良くはなさげ。まぁここまで何も食ってなかったので下痢とかは発生してないが、微弱な腹痛は定期的に発生する感じ。これは明日もあまり出かけたくはないか。あと、メシは食うなら昼がまだマシかもな。１９時だとまだ夜中の事故が怖い。
・睡眠時間５時間半。
今回は特に事故らなかったな。まだ大便はしてないが比較的安定しているようには感じる。徒歩川崎はしても良い気がするが、もうしばらくは様子見。
・Unity。
最初はUIまわりの選定的な作業から。
まず、UIでボタンを押した際の処理とキーボードなどでの入力の処理が同じになる可能性がある。今のところButtonは特に使う予定はないものの、将来的に使う可能性はそれなりにありそうな気配がある。そのため、InputSystemのSubscribeに渡してる関数を他のところで使い回す可能性があるため、そこらへんの処理は（ローカル）関数にする必要がある。さらに「キーボードとタッチの同時入力」があると困るため、UI側もInputSystemで使っているものと同じ同時入力抑制処理を使う必要がある。今のところ、処理ごとにスコープで区切ってローカル関数を用意し、InputSystemとUIのそれぞれにSubscribeする形が良さそうか。
となると、Subscribeが使えるようなUniRxとの相性が良いUIを選ぶことにはなるかな。サンプルを見るにデフォのUIのやつを使ってるものが多いしUniRxもそっちに対応してるっぽいから、まずはデフォのやつを使ってみるか。
将来的にはInアニメ・Outアニメ中は各種入力を受け付けないようにしたいんだけど、これは今やるべきか否か。早い方がわかりやすい気もしつつ、オペレータをいじるだけになりそうだから後からの追加も難しくはなさそうなのと、そもそも現状ではまだInアニメ・Outアニメに相当するものを用意するのが難しいので、ここらへんは後でかな。作るとしてもグローバルなフラグは影響範囲が大き過ぎるので設計をどうするかもそれなりに考えないといけないし。前の仕事のプロジェクトではそこらへんで問題が出たりしてたしな。
で、UIとModelのどちらを先に作るかを考えてたが、どっちかだけ先に作ってもまだ何も動かないんだよな。であればまずはどんな形であれ動くものができるようにするか。具体的には「ユニットの配置ができる」ようにしたい。それができれば後は色々と追加していくだけのはずだし。ユニットといっても単に画像と座標がある程度でそれ以外のものは初回は要らない感じで。
ステージ情報は保存できないといけないのでJSON形式にできるようにするかとか考えてたが、JSON形式と相互変換が可能なのであれば「Model <=> JSON <=> View」みたいな感じで無関係なクラス同士のコンバートをJSON経由でできるか？それも考慮した変換にしたいところか？
ModelとViewで違いそうなのは例えば「画像（テクスチャ）」あたり。Modelの方はEnumとかで、Viewの方は画像の実体あるいはファイル名とかになりそうだし。でもまぁそれはそれでJSONからの変換時に画像を呼び出したりすれば良いか。実際に保存するのはModelの方だからViewからの逆方向の変換はほぼ考慮する必要はないかと思うし。JSON経由で変換できるなら疎結合にできるし、ModelにせよViewにせよ単体テストもしやすくはなるはず。
あと、生成済みのやつに更新したJSONを渡した場合に差分だけ増減させる処理もあった方が良いか？エディットモードでいじる場合まずはModelをいじることになるが、そこからJSONを生成してViewに渡したら差分だけうまいことやってくれるとありがたい。少なくともModelとViewを個別に追加・削除するとなるとエンバグで齟齬が発生する可能性も高くなるし。
しばらく考えてみたがJSONの差分から作るのは難しそうか。少なくともこっちはこっちでバグが出そう。それよりは「ユニットの追加」「ユニットの削除」「ユニットの位置変更」みたいな形で作業ごとに明確に区切ってModelとViewの変更処理を並べて差が出ないようにした方がバグは少なそうか。
ただ、依存関係の都合でPresenterからViewを直接操作はできないんだよな。あと、オブジェクト指向や疎結合を考えると相手が保持するリストを直接外部からいじるようなのは望ましくはない。同様にリストの追加処理とかをPresenter側で持つとModelやViewでそこらへんの単体テストができなくなる。そう考えるとバグを抑えるには処理を並べるんじゃなくてModelとViewの整合性テストを書く方が良さげか。
というわけでリストの追加とかは各自の内部でやるとして、あとは素直に作ってみるかな。まぁそろそろ外出したいので帰宅後になるか。出かけるのは大便してからにしたいところだが、まだ便意が微妙。
ひとまず最低限のModelを書き始めてるけど、JSON化するには[SerializeField]の設定まわりが地味に面倒だな。アクセス権限を考えるとprivateなやつに[SerializeField]をつけて、それとは別にgetterとか用意しないといけないか。たまに見かける書き方だったけど、こういう制限があったんだな。こういう時にTestを書けるのは検証がラクで良いな。
・大便。
いつもの硬さに戻ったな。もうちょっと段階的に回復するかと思ったが結構早い。これならまぁ遠出も問題なさそうかな。でもまぁ大きな用事があるわけでもないし念のため散策とかはあまりせずに早めに帰宅しよう。
・体調。
出発段階でわりと良好。昨日は睡眠まわりが大きく乱れたし多少の不安を抱えながらの睡眠だったのもあって心配だったが、むしろ最近の中でも高い方か。しかし改めて観察すると世界認識が難しくなってはいるな。あるいは「なっていた」と表現すべきか。やはり睡眠時間の短縮の影響が大きいように思う。そこらへんが一度大きく崩れた影響で逆に適応が強めに働いたか？まぁもうしばらく様子を見ないとわからんが。
・休養期間。
とうとう来月から仕事だけど、長かったような短かかったような。いや、普通に長かったな。
今月も残り２週間、なんなら今年がもう残り２週間だが、冬季休暇を合わせると３週間で一ヶ月弱あるからまだ少し長いんだよな。ともあれ今回は色々できて良かった。今年は明確に体調の改善ができたしな。今はまたちょっと落ち気味とはいえこれは睡眠時間の短縮を試みてる影響が大きいから想定範囲内。来週末あたりに世界認識ができるくらいまで回復できてると理想だが。
・外出終了。
今回はちょっと脱力感が強めだったな。眠気は感じないし身体も重いわけじゃないんだけど、力が入りづらくて歩きづらい感じ。それでも歩けないわけではなかったので徒歩川崎はしてきたが、これはとっとと引き返して良い状態だったな。
そして暑かった。予報で最高気温２０℃というのは見てはいたが、よもやこの時期に半袖がちょうど良い状態になるとは思ってなかった。なんなら帽子をかぶった方が良かったくらい暑かった。
で、明日からはまた冷えていくんだよなぁ。なんなら例年を下回る気温というのを見かけたが。これはまぁ体調が崩れても仕方ないが、脱力感はたぶん下痢と断食の影響の方だろう。明日からは気温の変化の方で別の体調の崩れ方をすると思う。
・昼寝。
また断続的に２時間ほど寝てた。まぁ昨日睡眠まわりが大きく崩れたんだから本来これくらいが普通ではあるか。あと一週間は普通に様子見してて良いと思うが、５時間睡眠に慣れなさそうなら６時間睡眠でいけるように再調整が必要かもしれない。
・Unity。
とりあえず素直に書いていってPresenterのところに差し掛かったが、Modelの方は結果的に普通にリストに触れるので普通に追加・削除はできるとして、Viewの方はどうするか。
基本的にはOnNext経由で触ることは確定だけど、OnNextにラムダ式を渡してそこの引数にリストを渡してもらえればリストの追加・削除処理がここで書けるんだよな。で、View側ではこれを呼んだ後に改めて表示に必要な処理を行ってもらえば良い。リストの追加・削除部分を１つの関数でまとめられるのは良いが、しかしそうなると今度はView側で行う処理が分散してしまうことになる。結局一長一短であるのならView側に全ての処理を任せた方がやはりシンプルではあるか。
あー。View側に通知するのはまぁ良いんだけど、「ユニットを選択して配置」という処理は「View側で実際にユニットを追加する処理」と「ユニット選択画面からの遷移」が同時に走るんだよな。ここの実行順序が制御できない状態なのはどうなんだろう。何かしらのロードとかの都合でView側でのユニット追加が間に合わず、先に画面遷移が完了してそれにアクセスするような処理を行えてしまうのは問題だよなぁ。だからまぁ今回は問題なかったとしても実行順序の制御方法については事前に考えておきたい。
つっても今回みたいな形だと「Viewが実際にユニットを追加～表示できたらイベントを発行し、そっちの方をもとに遷移を実行」とするしかないか。
あー。通知の接続をしてたけど、最終的に実際にあれこれするViewのところでModelのあれこれもすれば良いのか。より厳密にはViewで接続せざるを得ないので、そのSubscribeの中でPresenterのAddUnitと自身のAddUnitを呼ぶ感じ。
うん、比較的キレイにできたかな。「モデルのAddUnit→ViewのAddUnit→遷移」という形で処理順序もキレイに整理できたし。
というあたりで１８時。最近はフロー２の進捗が悪いというかネタ出しモードになれてないんだよな。代わりにプログラマモードにはなってる。仕事期間を考えるとちゃんと切り替えられるようになりたいところだが。
どこかのタイミングでフロー２に専念する日を作ろうかなぁ。仕事期間で言えば土曜がフロー２で日曜が個人開発とか。まぁ仕事期間では個人開発よりフロー２の作業を優先するかと思うが、その場合も平日が仕事用のプログラマモードで休日をネタ出しモードにしたいか。そうだな。１日のうちで切り替えるよりはそちらの方がまだ現実的、か？うーん。ネタ出しモードはわりと蓄積が大事なので、やはり仕事期間でも電車内で蓄積→休日に発揮みたいな形が良さそうではあるな。その意味では休養期間でも今のような形でUnity作業→フロー２を少しやるというところまでは良くて、土日はフロー２に専念しても良いかもしれない。まぁすでに土日だし、なんなら土曜ももう終わろうかという感じだが。さらに言うなら再来週の土曜にはもう帰郷するので試せるのは実質明日と来週の土日だけだが。それでもまぁ試しはしようか。
というわけでUnityの方はコミットして切り上げ、しばらく休憩したらフロー２の作業はしよう。ネタ出しモードに向けた事前準備に専念する形で良いかな。
・メシ。
とりあえず今日からは元に戻す。で、月曜は改めてボトル鍋を試してみよう。来週一週間はまたボトルのを試してみて、下痢が再発しなければひとまずOKとはしたい。
ただ、「下手すると今回みたいな下痢の状態になる」というリスクは常に存在するんだよなぁ。正露丸でも即効性はなかったし。断食でそもそも出るものを制限するとしても、水分は補給しないといけない都合上ゼロにもできないんだよな。通常の鍋料理であれば鍋自体が十分な高温になるので問題ないが、レンジ調理だと容器がそこまで加熱されないからなぁ。可能な限りリスクを０にしたいところでもあるが、朝の短時間でやらないといけないという都合もある。どうするか。
何よりの問題は豚肉の加熱まわり。逆に言えばネギまわりとかは別に気にしなくて良いので、単純に豚肉にだけ注力すれば良い。
で、具体的に問題になるのは「豚肉そのものの加熱の状態」「豚肉の移動時の接触」「豚肉を運ぶ際に利用する箸などの接触」あたり。豚肉の加熱状態に関してはレンジの時間で調節できるので、残る問題は各種の接触。
豚肉自体の接触で問題となるのが「レンジに入れる容器との接触」。上記の通り容器自体はそこまで熱くならないので菌が残る可能性があり、注ぐ際にそれがそのままボトルに入る可能性がある。これに関しては注意していても限界があるので「容器も十分に加熱される」と良いのか？接触するにしても内側～せいぜい縁まわりなので、レンチン後にやや長めに放置しておけば水蒸気で殺菌はある程度できそうな気もする。あるいはいっそアルコールティッシュで拭いてしまうという手もあるか。特に注ぐ際に影響する部分さえ拭いておけば影響はかなり軽減できそう。やるとしたらその２つかな。
で、あとは「箸の接触」。これも具体的には「ボトルに注ぐ際の導線的な形で箸を使う際に箸についた菌が流れ込む可能性がある」という感じ。注ぎ口から直に入れようとしてもこぼれてしまうんだよな。これに関しても上記の通り水蒸気＋アルコール除菌でいけそうだし、一応さらに別の箸を使ってしまうという手もある。でもまぁついでだから水蒸気＋アルコール除菌でこちらも対処してしまうか。
というところかな。まぁ対処自体は思い付けたので、来週はここらへんを試してみよう。
・フロー２。
ネタ出しに関してはむしろ土日でがっつり入力して平日で実際にネタ出し～土日にラフやらSDやらをやりつつ余った時間でまた入力、って感じが良さそうか。明日はもうとっととフロー２に専念してみるか？Unityまわりを区切りの良いところまで進めたいが、どこが区切り良いか。
まぁ現段階でユニットの配置はできたので、あとはここからあれこれ拡張していく形だから現段階でも区切りは良いっちゃ良いか。とりあえずどっかに次の作業をメモしておいて、明日はフロー２専念にしようかな。
