■

・前日。
０８３０：ミックスナッツ×２。
１１００：性欲処理。
１１３０：からあげ＋枝豆。
１３００：低糖質クッキー。
２０００：焼き鳥＋コーヒーゼリー＋ミックスナッツ×２。
電解質：タブレット✕３と水分１．８リットル程度。
性欲：低～高。
筋トレ：腕立て１０×３回。

・断食。
金曜日のタスクに突っ込んでて定期的に断食について考えはするんだけど、当面は必要ないかなぁ。特にこれで検証したいこともないし、リモートワークじゃなくなるのでダウンが発生した場合のリカバリが難しい。今月やらないなら来月以降もしばらくはやらないと思うし、タスク自体削除してしまうか？あるいは仕事期間で発生した何かの対処のために一応残してはおくか。まぁ不要ならスキップすれば良いだけだから残してはみるか。

・睡眠時間５時間。
意識さえすれば安定して７時台に起きれる感じだな。ただ、今回は７時ちょっと手前くらいに起きたので３０分くらいの振れ幅はある感じ。そして５時間となるとたぶん昼寝がまた長くなりそう。その前に眠気が強まるかな。まぁまずはパワーナップなり多相性睡眠なりで身体を慣らしていこう。

・電解質。
結局レモン汁による補充は忘れてるが、特にこむら返りは発生してないな。とりあえず今月いっぱい現状維持で問題なければ来月からタブレットは２つに減らしてみても良いが、さすがに仕事開始のタイミングに合わせるのは微妙か。まぁ来月以降であればいつでも減らして良いという感じにしておこう。

・朝のメシ準備。
一通りやって１５分くらいか。７時起床ならだいぶ問題ないし、最悪８時起床でもなんとか間に合いはするかな。
で、やはり注ぎ口のない＆普通のお椀でやるとボトルに注ぎづらいしお椀側の容量がギリギリ過ぎてこれまた入れづらい。とっとと注ぎ口ありのボウルを注文してしまうか。
あぁ、日時指定どうするか。指定してしまうと結構かかるが、指定しなければ明日には届く。明日はちょっとバッグを探したい感じはあるものの、実際にバッグを使うのは月曜とかだし早めが良いから時間指定なしでいくかぁ。

・Unity。
今日はとりあえず入力でキャラを動かすところから。UniRxやMVPへの慣れもあるからこれだけで今日は終わってしまうかもしれない。
で、前回と同じく入力はInput Systemを使いたい。で、UniRxとの接続の仕方を調べると、やはり一手間は必要っぽいか。
https://qiita.com/Yuzu_Unity/items/1d0b39d17888fda552bd
ただ、この入力まわりの確認でTestが使えるのは大きいな。今まではキャラを動かすところまで実装してからのチェックだったので、入力が取れてないのかその後の処理がおかしいのか分からなかったからな。ここでついでにTestまわりに慣れていこう。
で、LINQ的な書き方をしてる部分の意味がわかってないので１つずつ見ていこう。
「Observable.FromEvent」はイベント処理をオブザーバブルに変換するものらしい。ここではInputAction.CallbackContextの中のperformed、すなわちInputSystemの何かしらの入力があった場合のイベント処理を変換している。
「Select」は実際の（ボタン）入力の取得。
「ToReadOnlyReactiveProperty」は最終的に使うReactivePropertyへの変換。入力まわりは取得するだけなのでReadOnlyの方を使っていると考えられる。
ってところか。まだわからないのは「なんでFromEventまわりはこの書き方でいけるのか」と「ReactivePropertyの厳密な挙動」か。前者はまぁそういうものだで済ませることもできるが、自前でEventなどをこさえた時にもこの書き方でちゃんと動くのかどうかの確信が持てないのがなんとも。ただ、調べるとなるとシステム側のコードとかを見るしかない気がするので、数をこなして慣れる方がコスパは良さそうか。後者は連鎖的に変更を通知～処理できるようにしたプロパティだとは思うが、厳密な挙動の把握がまだできていない。まぁこれもまた実際に使って慣れる方が早そうか。

・体調。
そろそろ外出時間だがだいぶ体調は良さそうだな。まぁ少し眠気が出てきた感じもあるが。
やはり睡眠時間の俗説の信頼度はだいぶ低く感じるようになったな。「睡眠時間が短いと短命」みたいなのはよく見かけたけど、睡眠時間以外のパラメータが同じだったかどうかというデータすらない。おそらくはそもそも睡眠時間を短くせざるを得ないような状況の方が問題だったのだろうし、睡眠に問題があったのだとしても睡眠不足の問題であって睡眠時間不足の問題ではないのではないかと思う。栄養不足と食事時間の不足が別物であるように。
縄文時代あたりの睡眠時間が推定できれば良いんだけどな。まぁどちらかといえばやはり時間そのものというより睡眠の捉え方とかそっちの方が重要だとは思うが。

・外出準備。
ていうかまた気温が高いな。昨日もそうだったが。明日はまた最高気温が２０℃くらいになるっぽいし。服装の調整に困る。

・外出終了。
とりあえず近所で肉系をざっと探してきた。平日の帰宅タイミングで寄ることを考えると場所は限られるのでわりと早く終わったかな。
で、まぁやはりちょうど良さそうな惣菜とかはなかったわけだが、低温調理がここにきて再びアリになってきたかもしれない。朝のうちに仕込んでおけば夜には食えるし、今ならタレも低糖質でいける。コスパが悪いうえに全体食にもなってないのが難だし、野菜を加えるにしてもピーマンはちょっと微妙かなという感じだし、近所で安定して買える大きめの肉ってのも意外となかったりはするから不安要素は大きめだが。
こうなると改めて派遣先を見てきたい感じはあるな。まぁ土日だと品揃えが変わる可能性もあるので、行くなら次の平日かな。できれば午後が望ましいが、昼寝とかを考えるとやや難しいところ。睡眠まわりが安定してれば良いが。土日は焼き鳥を食いたいからボトルでの食事を試すのは平日になるので、そこらへんの検証も含めて行ってみるか。ボトルとスプーンとかの利用そのものは今日の昼飯でやる予定だが、持ち運びとかは次の平日になるしな。バッグの検証もできるから悪くないか。まぁ徒歩川崎でも似たようなことはできるが。

・昼飯。
というわけで鍋を事前に調理してボトルに入れた状態で（少し早いが）１１時半に摂取。もう少し温かくても良い気がするので、レンジにかけるのは２分→２分半くらいで良いかも。
あと、肉と豆腐は交互に入れないともう片方が取り出しづらいな。
そして何故か下の方がちょっとレアというか生焼けというかそんな感じだった。下の方が熱がこもるかと思ったんだけど、金属との接触面だからむしろ冷えやすいんだろうか。ともあれ熱はもうちょっと入れた方が良さそう。
大きさは問題なし。鍋の量はちゃんと入りきってるし、折りたたんだスプーンがちょうど入る。

・Unity。
Testを書いてみてるが、InputActionAssetを持たせたいんだけどSerializeFieldに対応したテストの書き方がわからんな。まぁ今回はRousourcesあたりから読み込む方法に変更しても良いんだけど、今のうちにそもそもそういうことができるのかのチェックとかはしたい。
英語の掲示板の方だけど「シーンを読み込んでそこから取得しなっせ」みたいな書き方をしてるなぁ。やはりそういう間接的な取得しかムリそうか。であれば今回は素直にResourcesから読み込んでみるか。できるよな？というかもっと単純なTestを書いてから詰めていくか。
InputActionAssetの形ならLoadはできるけど、それだけでは動かんな。自動では回らんか。まぁただのアセットだしな。
と思ったらEnableにするだけで普通に動いたわ。でもまぁこれで入力単品のテストはできるようになった。ついでにテストでコルーチンとかを使う方法も理解できたし良かったかな。
といったあたりでそろそろ昼寝の時間。眠くはないが横にはなってみるか。少なくとも空系を入れるべきタイミングだろう。

・昼寝。
１０分程度だったのでパワーナップ寄り。眠気はある程度なくなってたので起きることにした。

・Unity。
続きから。とりあえずキーボードの上とかを押したら上に動くだけのやつを作るか。
ただ、実装となるとModelからになるんだよな。で、まぁ入力処理はPresenterでやるとして、座標の保持はModel側だよな？ただ、TransformはUnity依存だし座標は普通Transformで管理するか。いや、Modelの座標とViewのTransformを個別で管理することになるのか。それをPresenterで接続する形か。
画像はどうだろうな。画像の種類というか、そのもととなる何かしらのTypeとかのデータはModelに持たせても良いが、画像本体や画像のパスとかはModelで持つものではないよな。もととなるTypeか何かから実際の画像の生成～設定までをPresenterが受け持つ形かな。必要ならそのための情報も保持する感じで。
今回はキャラクターは１人だけど、将来的にはユニットとして複数存在するはずで、そのうちの１人を操作する形になるはず。ひとまずユニットのクラスを作って今回はそのままModel的な扱いをして、将来的にはそれを複数持たせる形かな。実際にはさらに他のデータも持つことになるか。盤面情報の中に入る形かな。
で、移動時の衝突処理はModelか？別にUnityとかに依存する部分じゃないからな。となると、Presenterは入力を受け取ったらModel側の移動処理を呼び出し、実際の移動処理はModel側でやる流れになるか。
InputActionAssetは今回はTest用のコードを流用してPresenter内部で生成するとして、実際にはもっと根本な部分で作って持つべきだよな。Root用のPresenterが必要な感じか？
ユニットごとにPresenterが必要そうか。というかユニットごとにViewが存在することになるので、それに対してPresenterが必要になる形かな。クラスが同じで別インスタンスってことで良いんだよな？とりあえず今回はユニットのViewは適当なプリミティブにしとくか。
サンプルコードを見てて意味がわからなかったが、入力まわりでBuffer(2,1)するってのはつまり「１つ手前の入力も参考にする」という感じなのかな。そういうこともできるんだなぁ。自前でOld値を保存しなくて良いのは便利そう。
やはり書いてると慣れてくるな。UniRx的な書き方やらMVP的な書き方はもちろんのこと、「Modelに用意された座標を外部から直接操作するのではなく専用の関数を用意することで、"これ以外の動かし方はそもそも想定していない"みたいな設計思想をコードとして実現できる」みたいなのもわかってくる。ここらへんはMVP的にきっちり分かれていることの影響かな。
うーん。入力が取れるところまで一応いったけど、なんか入力が１回しか反応しないな。テストの方も１回しか見てなかったので気付かなかった。たぶんイベントを通知に変換するところがおかしいんだろうとは思うが。
Testを回してみたところ、どうもValueの変化が発生してないな。InputAction自体のIsPressedはちゃんと変化してるから、やはり変換に問題があるっぽい。
あー。Callbackを設定したら「１になるたびに呼ばれる」んだけど「０になったら（ボタンを離したら）呼ばれる」ことがないから通知に変換されないんだな、たぶん。いや、そうか？それはなんか違う気がするなぁ。というかここでやはりFromEventまわりの理解に問題が出てくる感じか。
うーん。Selectの代わりにSubscribeにするとちゃんと毎回検出はできてるからFromEventが悪いわけではなくSelect以降の問題っぽいな。
さらにSelectを抜いてSubscribe内でReadValueAsButtonを呼ぶようにしてもダメだったので、そうなると残るはToReadOnlyReactivePropertyの問題？確かにそうだな。これは結局プロパティであってプロパティの変化があった場合にのみ通知するわけだから、ここの問題か。つまり、このプロパティが０になることがあればちゃんと通知がなされるはず。
ということは本質的には「"Button"でなんとかしようとしているのが問題」って感じかなぁ。
いや、Buttonの方でもちゃんとリリース時にイベントを飛ばす設定はできるっぽいか。InteractionsにPressを追加して、Trigger BehaviourにPress And Releaseを設定する。
うん、これでできた。Testも本体もちゃんと想定通りの挙動。
といったあたりでそろそろ１７時か。ある程度は想定していたが結構時間がかかったな。でもまぁお陰で色々と学習ができた。特にReactivePropertyまわりは会社で初めて遭遇したら面倒なやつだったので、今のうちに経験できたのは良かったかな。やはり理解が浅いとまだまだハマる部分が多いか。
ともあれ今日のUnityはここまでとして、しばらく休憩したらフロー２の方に移ろう。
明日はどうするかな。今日は１キーでの移動だったからこれを本格的に２軸移動にして、できれば当たり判定まで組み込んでステージとその中の移動までできると良いが。同時押し抑制も早めにしておきたいかなぁ。

・予定。
明日はまぁ通販受け取りがあるんだけどバッグ探しはやるか。というか麦茶が日曜に届くことになってしまったので日曜にズラすのも微妙なんだよな。まぁ麦茶の方はヤマトで届くっぽいからたぶん後で時間帯の指定ができるとは思うんだけど。
足の方は今朝の買い出しでかすかに違和感はあったもののおそらく大丈夫だろう。でもまぁ散策で時間がかかるから徒歩川崎ではなく電車往復かな。
で、順番としてはメシの調達→カバン探しが荷物的に良さそうなんだけど、９時出発で往路が電車だとそもそも店も開いてないし、１１時くらいにならないと焼き鳥の品が揃わないんだよな。であれば近所の方の焼き鳥なら１０時の開店直後でも揃ってるはずだからそっちで買ってからかな。となると、１０時出発→焼き鳥確保→川崎側で残りのメシ調達→カバン探し、という流れになるか。

・低糖質。
クッキーを食い終わってしまったが補充するかどうか。もともとは「いざという時のため」という感じだったのに、存在すると食ってしまうってのが微妙なところ。それなら自作クッキーでも良いしなぁ。
ただ、おそらく夕飯の肉系はどうせタレが必要になり、タレまで毎回自作するのは面倒そうだから低糖質のタレを注文しておくのはアリなんだよなぁ。それに合わせてまたクッキーを注文するのもナシではない。しかしクッキーをちゃんと臨時の摂取にする方法を考えておかないと単純にコスパが悪い。
しかし現状何も思いつかないな。そもそも「何か食いたい」となってる状況自体が良くない。「どうしても摂取したい」という場合でも、「もっと欲しい」となるのはよろしくない。その意味では今回のクッキーは向いてないか。であれば試すとしても冷凍系かなぁ。そっちは低糖質のタレとは同梱できないので微妙ではあるんだけど、「すぐには食えない」という意味でワンチャンはありうる。

・テロ。
任天堂のイベントが中止とかになったのは脅迫があったからっぽいか。詳しくは知らんが。
で、自分はテロに屈する企業が嫌いだと以前に書いた気がするんだけど、何故か今回は「子どもたちも居るししょうがないか」という感覚になっていてさすがにダブスタを感じる。まぁ原因とかを特定するほどの興味もないが。どちらかといえば「イベントを中止に追い込んだんだから最低でもイベントで入るはずだった収益分は加害者への罰金になるよなぁ」とかの方が興味があるし、そちらも別に深追いするほどの興味ではない。