． ルールの類は、ある状況があり、そこに何らかの変化が欲しくて設けるものだろう。 入力があって出力がある関数みたいなもんだ。 入力が変われば出力が変わるので、ルールも変える必要がある。 また、欲しい出力が本当にルールによって得られているのか、 ということも確認できるならしたい。 治療でもルールでもなんでも構図は一緒だ。 症状が変われば治療は変わるし、目標とする状態が変わっても治療は変わる。 そして、その治療が効いているかどうかの確認も必要だ。 治療にはコストがかかり、副作用もあるから、しなくていいならしない方がいい。 しかし、効いているかの確認はコストがかかるし、 状況に応じて微調整するにはコストをかけるか経験を積むしかない。 コードレビューやコーディング規約みたいなものも同じ構図で、 同じ問題を抱えうるということか。 コーディング規約が実際に品質を上げているかとか、コストを下げているかとかの 測定はほとんどなされていないのではなかろうか。 二重盲検で無作為大規模試験をやらない限り白黒がついたとは言えないし、 仮にやっても、作っているものや人材の組成が違えば話が違ってくる。 医学においては「専門家の意見」はエビデンスとして質が悪いと言われるわけで、 同様に、えらいプログラマが「コーディング規約は大事」 とか言っていても信用して良いとは限らない。 自分の状況で考えるべきだし、効果を良く見た方がいい。
． しかし、それにもコストがかかるわけで、 「他がやってるならきっと効くんだろ」と考えて とりあえず導入、みたいなのにも合理性はある。 それがメジャーなやり方ならば、 それをやっている他に比べて不利になることもない。 皆が傷を消毒して乾かしているなら、それに比べて悪くなることはないから それでいい、という考え方だ。エビデンスがなくても。 動いているコードは問題があっても触らない、みたいなのも同じ構図か。
． 便利だな医学。商売や技術を考える上でも役に立つ。 大抵の場合、ある分野の知識は他の分野に応用できる。 たまたま学ぶことになってしまったものでも、ちゃんと学んで 応用する工夫をすれば無駄にならない。 unity固有の知識とか欲しくないわ、と思っていたし、 こうならなければ学ぶこともなかっただろうが、 学ぶことになってしまった以上は利用せねばならん。 医学も知らんで問題なければその方が良かったんだがな。
． 日記を滅多に書けなくなってしまった。 通勤時間のせいで労働時間の割に家にいないのと、 帰ってから日報を書いていて、それに時間を食われつつ、 日記の役割を果たしていることが大きい。 会社で目立つためには手を尽さねば。
． 単に目立ちたい、というだけではなく、 年が上の人があまりいない環境には弱みがある気がするので、 そこを補えないかという思いはある。 私が24の時には30あるいは35超えの人が多数いた。 だが今の会社は4年いればベテラン臭を帯びるくらいに若い。 それだけ成長が速いということで、 自分がのんびりしすぎてきたことを思い知る。 自分26とかの時はあんなにしっかりしてなかった絶対。 しかし、大きな責任を負う前に一見無駄な試行錯誤をする時間が 持てることもまた幸せなことだろう。 視野を大きくすることを強いられるのは、それはそれで辛い。 下手に道具が整っていてそういう無駄をやる余地がないのもあるんだろうな。 sinの関数近似を通してアセンブラの勉強する、なんて時間は取れんだろうから、 計算機の底の部分をかいま見るチャンスはその分減る。 あの当時はPS2でVUがあったことが大きいな。もし初ゲーム機が cubeやxboxだったらだいぶ違ったかもしれない。
． でもまあ、そんなこと考えるよりも腕が先。降りてきた仕様を形にする、 というところをクリアせんと発言力がつかない。 4ヶ月弱も経つと、unity素人とかいう言い訳はできない。
． 考えてみれば、もはやunityそのものが難しいとは感じないな。 難しいのはunityでもC#でもなく、今のプロジェクトのコードと、 作り方の思想や文化の方だ。 あまりにも違う。 それが妥当とされる背景はおおよそ理解したが、どうにも慣れん。
． コールバックは何を解決するための道具か？ それがはっきりすれば妥当な適用範囲がわかる。 過去コールバックなんて滅多に使わなかったので真面目に考えたことがなかった。
． 簡単な例ではソートがある。比較関数だけ差し換えたい、 という場合だ。テンプレだったり継承だったり関数ポインタだったり 関数オブジェクトだったりラムダだったりするが、 どれも「計算をデータのように差し換える」ということが言える。 ソート側で比較のことを知らずに済むようになり、分離がなされる。 もっと普通のコールバック、例えば非同期処理の完了コールバックも 構造は同じで、計算をデータのように差し換えてコードを再利用したり 共有したりすることを可能にするし、 非同期処理そのものが完了時処理のことを知らずに済むようになる。
． ゲームの各要素がonなんとかを実装して、コールバック呼び出し器的なものに それを登録する、という作りにも同じことが言えるだろうか。 言えるだろう。「タップされたら、何かする」をコールバックにする場合、 「タップされたら」の処理からは「何かする」は知らずに済む。 「タップされたら何かする」が一塊のものとして書かれていれば、 「何かする」だけを動的に取り換えることはできなくなる。 動的な差し換えと、情報の遮断がその目的のはずだ。
． ソートの場合、もしそのソートが一箇所でしか行われなければ、 比較を差し換えられることに利点はない。 再利用や共有の利点が消える。しかし、ソートはなにせややこしくて バグりやすいので、何度も書きたくない。だから差し換え可能な部分が 増えることは歓迎できる。 また、分離に関しては、ソートの処理と比較の処理が完全に無関係で なければ本当には分離できない。比較を書く人間は、それがソートに 使われることを知らなくても書けなくてはならないし、 ソートを書く人間は、比較とは何か、ということの形式上の定義だけあれば その実際は知らなくても良い必要がある。 ソートの場合は容易に成り立つ。ソートは「2個のどっちが小さいか」 だけわかれば書ける。そして、「どっちが小さいか」という処理は ソートだけに使うものではなく、しかも比較には普通副作用がない。 二度呼ぶとおかしくなるとか、呼ぶ順序によっておかしくなるとかいうことがない。
． 非同期処理の完了コールバックの場合はどうか。 再利用性、共有化の意味は大きい。なにせ非同期処理もややこしいからだ。 IOが絡むとエラー処理などが面倒くさくなるし、スレッドなんて使ってたら なおさら面倒くさくなる。ライブラリの中に押し込めたいわけで、 カスタマイズしたくなるだろう。終わったかグルグル回して監視することは 効率が悪いケースもあるし、そういう書き方をするとコードが長くなったりもする。 独立性はどうか。「読まれたファイルをどうにかする」 はファイルのロードに使われる前提なのは明らかで、 ソートの件ほど独立とは言えない。それにファイルを読むような処理には 文脈があるはずで、いついきなりその関数が呼ばれても正常に動く、 ということはおそらく保証し難い。 何か初期化して登録する、みたいな副作用が必ずあるはずだ。 だからファイルを読み始める処理の近くに、 読み終わったコールバックを置いておかないと、たぶんマズい。 だからこの手の関数はラムダにして文脈の中に置かれやすい。 この用途は独立性はないが、共有と再利用、そして 監視で書くことを避けるために使われる。
． タップされたら何かする、はどうだろう。 「タップされたら」はたぶんそんなに難しいコードではないので、 そんなに再利用したい動機はない。 タップされた時に何をやるかが しょっちゅう変わるのであれば再利用したくなるので、 時によって全然違うことが起こるならば意味がある。 多数のタップされるオブジェクトが「タップされたら」のコードを 共有していて、それぞれにコールバックを差す、 みたいなことだろう。ないとは言えない。 独立性についてはファイルと同じで、独立性は弱い。 タップされたらやることを、タップを念頭に置かずに書くことは たぶんあまり多くない。しかも確実に副作用がある。 タップされたらそのキャラを選択する、 みたいな処理は、状態を変化させてしまうので、 変な順序で呼んではいけないとか、二度呼んではいけないとか、 呼んではいけない時があるとか、そういう文脈依存の処理になる。 したがって、離れた場所に置いておくとそれが見えなくなってバグ源になる。 ラムダで書くべきで、関数を分けて置くことは避けたい。 そしてもう一つ、「タップしたら何が起こるのか？」 をコードから読み解くのが恐ろしく面倒くさいという問題もある。 コールバックの登録箇所を探さないといけないし、 見つかったものが問題の時点で呼ばれるかどうかはわからない。 動的であることが仇になる。 また、引数を増やしたいとか、戻り値を使いたいとかいう 仕様変更に弱くなる。関数の入出力仕様が固定されてしまうからだ。 無理矢理キャストしたり、別の場所に置いてやりとりするような羽目になる。
． なんとなくわかってきた気がするぞ。 流れが重要な処理を分割して離すのは良くないが、 ややこしかったりして二度書きたくない処理を共有化したかったり、 ライブラリの中に隠したい時に、 そこを妥協することはあり、そういう時にはラムダにして近い場所に 配置するのが便利だ。 昔C#でOnなんとかをたくさん書いてGUIアプリを作っていたが、 呼ばれる順序みたいなものがあるのにバラの関数で書かないといけなくて 辛かった覚えがある。「先にこれ呼ばれたらバグ」 みたいなAssertとチェック用変数を山ほどつっこみながら書いていた。 Javascriptでもonなんとかをバラバラ書くことが多いが、 ラムダのおかげでまだ楽に書けた。 今のC#ならラムダが使えるので似たようなものもマシに書けるだろう。 ただラムダで順序良く書けるとはいっても多段になると字下げが えらいことになって気持ち悪い。そんな時でもC#にはyieldで回す手がある。 unityのコルーチンだ。 しかし、yieldにも弱点があって、そこの処理に複数突入したり、 途中で止めないといけなかったり、 使っているメンバ変数を他から書き換えられたりすると、 結局ややこしくなってしまう。 コルーチンを起動するのがOnなんとかだったりすると問題はさらに複雑で、 そのOnなんとかが立て続けに飛んでくることはないのか？ 順序はどうなんだ？みたいなことに前提を置きにくくなり、 それだけややこしいコードを書くことを強いられる。 Onなんとかを呼ぶコードは遠くにありがちで、 遠くにあるものほど前提を弱めないといけないからだ。 下手をするとOnなんとかを呼ぶきっかけは外部のサーバからの通信 かもしれず、そうなると一切前提を置けない。仕様が変わればそれまでだ。 横にある関数なら「こいつ0から5を返す」という前提で使ってもいいが、 誰か他の人が書いた遠くのファイルにあるintを返す関数ならば、 マイナス10億が来たらどうするか？みたいなことまで気にして書く方が妥当になる、 というような話だ。
． あ、わかった。それだ。その感覚があるかどうかだ。 「実装見たら0から5を返すことは明らかじゃん」と言えてしまえば、 変なものが来た時の対処などしない。 「このOnなんとかはこの順序で呼ばれる」ということを「知って」いれば、 それ以外のことはないのだから、気にするに及ばない。 「そんなことが不安なのは実装を読んでないからだよ」 「それは仕様書に書いてあるよ」 という話になればそれまでだ。 そうか、「極力情報を知らないで書ける/読めるコードが良い」 という世界観は当たり前ではないのか。
． やはりたまに日記を書かんとイカンな。 こういうのは日記でも書きながら考えないと整理できない。 2ヶ月遅かった。 一応、slackで自分専用チャネルを作ってこういう思考の過程を メモってはいるのだが、仕事中はこんなにガッツリ考えることだけに 時間を使ってないからな。
． オトモ1歳。だいぶ子供になってきた。歩き回るし、 指さしたり、なんか言おうとしたりする。 うちの子は3人とも歩くのが結構早かったが、 布団しきっぱなしでコケるのが恐くないのが大きいのかもしれない。
． 日本デジタルゲーム産業史、という本を読んだ。 6歳でファミコンに出逢い、 PS2とPS3の時代に家庭用の開発をし、そしてスマホゲーに移った私にとっては、 この本に書かれていることは他人事ではない。 しかしそれだけに、読まねばいけない本というわけではないのだろう。 「そうだよね、そうだよね」的な感想で、心地良いし整理もできるが、 新しくはない。これを同僚に読ませたらどういう感想を持つのかな、 ということの方が気になる。私より15くらい若い人もいるからな。
． ひつじこに負担がかかっていて申しわけないが、 負担の問題よりもむしろ、私が思考と時間をどれだけひつじこのために使うかの 問題なのはわかっている。わかっているんだが、なかなか切り替えができない。
． ゲームは試行錯誤の回数が決定的に重要だと私は信じている。 ゲームの核が見える前に、 パワポで立派な仕様書を書いたり、絵を作り込んだりしたら負け、 くらいのことは言いたい。
． 通勤片道75分は論外だろう。 いわゆる定時プラス30分で会社を出て家に帰ってきたら子供が全員寝てる、 みたいなのはとても持続可能な状態とは言えない。 クラロワは心が折れたので瞑想するくらいしかやれることがないし。 単体でPCがネットにつながれば多少はやる気にもなるが、 座れる率は高くないし、会社で支給されたmac book proは重いしな。
． うちの干し柿は固い。こんな固いの市販してない。 ジューシーからは程遠いが、むしろ求めるべきはこれだろう。 それだけ固いにも関わらず、甘味はそれほど強くない。市販のもののように 白く粉を吹いたりはしていない。 市販の奴は一体何をやったんだ?
． 内出血と筋肉痛があったので、 日曜の夜に通導散加桃仁牡丹皮を1.5倍量で煮て、夜と次の朝で半分づつ飲んだ。 月曜の朝5時に下痢と腹痛。少し頭痛。尿は黄色。 漢方でも量増やせばそれなりに副作用来るなあ。 下剤の大黄と芒硝は標準量なので、 そんなにキツいわけはないのだが、大黄ごとミキサーで砕いて 30分以上煮ていたのが悪かったかもしれない。 マウスの実験でも大黄は末にして煮ると腹痛を催す成分が 強く出るとあった気がする。頭痛は当帰のせいかな。 なお、内出血と筋肉痛は一日でだいぶ軽くなった。 内出血は紫がだいたい消えて、皮膚のすぐ下の赤いのだけが残っている。 この速さで治るのがプラセボとは考えにくいがなあ。
． 次やる時は身体が冷えるので芒硝は削り、大黄は2gを後入れか。 紅花と蘇木は増やしてもいいか。
． 日曜、ひつじこ実家でひつじこに髪の毛を切ってもらった。 かっこよくなったらしい。ハゲが進んでからというもの中途半端に伸びると 悲惨な感じになるのだが、ひつじこ以外に切らせる気はないので どうしても間が空く。
． 半年ちょい前からフィナステリドのジェネリックを1mgづつ 飲んでいたのだが、どうも髪の毛が回復し始めたらしい。 なにせ自分では一ヶ月に一度も鏡を見ないのでよくわからないが、 髪を切るひつじこや、おしゃれに長けたひつじこの妹さんが言うのだから そうなのだろう。効くんだなあれ。
． 明日から正社員なのだが、明日は合宿の振替休暇。 合宿が休日にあったのだ。あれは楽しかった。
． 最近締切がキツい仕事がドカンと振ってきた。 全く知識がない状態で仕事を引き継いだので、 解読するところからだ。エグい。
． リフレクション怖い。 誰も呼んでないコードが呼ばれる。 呼んでないと思って削ったら、 実は呼ばれてて、でもコンパイルは普通に通る。 そして挙動が変わる。これ厄介すぎるだろう。 リフレクションが存在するおかげで、 呼んでないコードがないか調べる手段がなくなってしまう。 「~~で始まる関数名を持つ関数をリストにつっこんで順に実行」 とかされてしまうと、もうどこから飛んできたか全くわからない。 これを使うことがおいしい局面ってのは一体どういう時なんだろうか。
． お昼は同僚と食べに行ったのだが、御飯を一杯食べただけで 午後眠くなってヤバかった。白米ヤバいな。
． 明日弟が東京の病院に来るので電話した。だいぶ体調悪いらしい。 TS-1を確実120mg飲んでるらしく、もうほとんど何も食えないレベルに吐き気 があるという。せめてその吐き気はどうにかならんのか。
． 土曜、近所の焼き肉食べ放題に行った。じゅうじゅうカルビ。 今度は大人3000円なので、それなりなレベル。 結論から言えば、焼き肉というもの自体に限界があるなあという印象。 川崎で食べたよりずっとまともな肉だったが、 子供がいて何かと忙しい上に、 あの網で完全な焼き加減にするのはとても無理だ。 家でフライパンやオーブンを使う方がどう考えてもおいしくできる。 肉自体のグレードも、キロで買えばずっと良くなるわけだし。 でもまあ、ああいう焼き肉とかしゃぶしゃぶとかはイベントというか 遊びというかなわけで、美食の類ではないのだから、 そんなことを言っても仕方ない。
． 日曜はオタマの幼稚園のおゆうぎかい。 すごいな。幼稚園の劇てああなるんだ。 一つの役に数人いて台詞を分担する。なるほどああすれば 全員何かできるもんな。
． 土曜にちょっと普段やらない運動をしすぎたようで、 内股が筋肉痛。筋肉痛って漢方で軽減できんかな。 内出血なら通導散で治りそうなものだが、 細かい筋肉の損傷だから違いそうな気もする。 筋肉が縮んでいるようなら芍薬甘草湯とかでほぐれそうだが。
． 真田丸見てて、下手に戦術で勝つと戦略の不備が 見えにくくなって余計にひどいことになる、ということを思い出した。 戦術レベルの勝利で戦略の不備をひっくり返せるものではない。 しかし、例外というのはどこにでもあるし、 そもそも戦略がクソかどうかがわからん事もある。 とりあえずは目の前の問題をどうにかするしかないし、 どうにかしてみたら見えることもある。 もちろん、あからさまに戦略の不備が見えているのに そのまま進むのはダメなんだが。