気温トークですが、現在は主幹になる一つの関数から季節、気温ごとに分岐して、適当なトークが呼び出されるようになっています。
これを、１トークずつ再生条件を割り振り、独立させようかと考察中。
メリット
・気温取得関数の一般性が向上・トークのメンテナンス性、拡張性が向上
・全体のトーク数が正確にカウントされる
（気温トークは正確には20以上のトーク群で出来ているが、現在は全部引っくるめて1トークとカウントされている）
デメリット
・一定時間毎にWebからデータ取得するため、エラー発生率が上昇
（ただし誤差範囲に近い）
・時間制御系（OnXxChange）がもっさりする
・せっかく完成した関数群を組み直すのが面倒
……メリットのほうが大きいよね。
とくにメンテナンス性が上がるのは大事。
毎日行う作業というものは、作業自体を極力単純化しなければならない、というのが信条だ。
だからこそ、SHIORIに里々を選んだのである。
……改造しますか。
あうあう。
= = =
あうあう。
といえば、ひぐらし二順目が進みません。
まだ綿流し編です。
夏祭りが終わり、詩音が暴走して魅音と村長を拘束したあたり。
なんだかなあ。
真相を知ってから見直すと、ただの鬱ゲーと化しますな、このあたりは。
早く終わらせて、祟殺し編はとばして暇潰し編に入ろう……。
= = =
写真は部屋の中で海鮮バター焼きをしてみましたの図。
