教えちゃお
コンビニでおにぎりを買おうとしたら、レジで「申し訳ないがこれは賞味期限が切れているので売れない」と言われた。珍しい体験だった。大昔スーパーマーケットでバイトしていたときに賞味期限切れの食品を捨てる仕事をしていたのを思い出した。僕が働き始める直前にバイトによる廃棄食品の持ち帰りが発覚し数人が辞めさせられたらしい。
これは興味深い問題だと思う。一般的なMOTTAINAIの精神に基づけば廃棄食品を持ち帰って食べるのは良いことだ。しかしそれが許されなかったのは「商品を商品として見られなくなる」からと聞いた。つまり「これが売れずに廃棄になれば自分のものになる」と思ってしまうと、その商品が売れないように隠したりしかねないということだ。なるほど、筋が通っている。店員としての行動を徹底させるために正しくインセンティブを設計している。
スクラムでベロシティを安定化するにはどうしたらよいかで紹介されていたので8割方読んだ。8割方というのは、途中生産管理の話から思考法っぽい話に移ったところで興味を失って止まっているからだ。
この本では問題を抱えた工場の工場長が、学生時代の恩師（作者がモデルのようだ）から断片的なヒントを得ながら、それまでとは全く違う思想の生産管理を取り入れて成功するというストーリーが物語仕立てで描かれる（無職やめ太郎氏のようなものだ）。端的に言えば全員を休みなく働かせるのが最高効率というわけではなく、むしろボトルネックに着目しろという話だったように思う。「ように思う」というのは、教科書ではなく物語だから論理的な筋立てはあまりよくわかっていないからだ。
興味深い読み物ではあったが、単純にソフトウェアエンジニアリングに応用できるかは疑問だ。ソフトウェアエンジニアリングには固定化した生産ラインはないし、在庫コストもないからだ。しかしフロー効率とリソース効率とか、従属事象・統計的変動の概念はなんとなく掴めたので、もうちょっとかっちりした制約理論の教科書を読んでみたいと思った。
言わずと知れた有名人uhyo氏の著作。3割くらい読んだ。
僕は既にプロなので9割くらいはもう知ってる知識だ。しかし端々に挟まれる詳細な仕様の知識とか歴史的経緯、さらにuhyo氏の思想などが勉強になる。知っていると思い込んでいるものをもう一度学び直すという意味で価値のある読書だなと思う。思うのだが、やっぱり大体は知ってる話なので退屈になってしまってなかなか読み進められない。
仕様が広大ゆえに使いこなすのは難しいHTMLの本。全然読めてない。
連結リストやスタック、木、ハッシュなどから始まり、ソートやグラフや文字列検索なども扱うらしい。これも3割くらい。
C++で実装しながら読み進めている。2-3木は辛かった。コアになるアルゴリズムはシンプルなのだが場合分けがドエラい数になる。平均計算量に関してはある程度計算で求める必要があるが、理解できないほどではなかった（自分で発想しろと言われても無理だが…）。
あまり多くは語れないが、ここ半年くらいはずっと悩んでいる。4年目にもなるとこれまで通りの仕事をしていても学びがなくなってくる。だから更にスコープを広げて何かチャレンジしたいなと思っているけど、なかなかうまくできない。仕事に学びを求めるのが間違いなのかもしれない。
だからまあ、最近本をたくさん買ってみたり個人開発頑張ってみたりというのは、何か突破口が見つからないかなあということですね。
最近はもっぱら https://anime.chao.tokyo の開発を進めている。Animetickからしょぼいカレンダー（手入力のアニメ放送予定API）への依存を切って、大量視聴を管理するための可視化などを足してみたいなという狙い。
使用技術はRemix+PrismaでEC2に雑に（DBもEC2で動いてるｗ）立てている。バックエンドの処理をパイプラインに見立ててfp-tsで書いているのが自分的こだわり。
飽きたら次にやってみたいのはweb componentsとかかなあ。Reactを捨てて生のHTMLと最低限のJSで何ができるのかというところを勉強してみたい。あるいはなんかOSSとかも。GoやRustも触っておきたい。学ぶべきことはいくらでもある。その気になればTypeScript一本でなんでも書けてしまうので、意図的にコンフォートゾーンの外に出るようにはしたい。
以前から美味しいものを食べるなら外食で、自炊は楽で身体に悪くないものというポリシーでやっている。最近は以下のセットで固まっている。
サラダチキンを切らしたときは適当に惣菜買ってきたり。ここから50年くらいずっと同じものを食べ続ける可能性すらあるので、自炊は変に偏らないようには気をつけたい（何食っても塩分過多で怒るのであすけんは嫌いです）。
3月末に右足首を捻挫して結構長く歩行で痛んだり疲れやすかったりした。ようやく治りつつある。
まあ、そこそこ見てます。
ちょっとやる気なくなってます。4月頃は調子よくて3880まで上がったけどしばらくやらなくなって今3430。
自分の持ちキャラのメタ変動の話をすると、Dazzleの7.31の変化が気に入らない。タイミングの概念を捨てて単にCD上がるたびにスキル撃つのを推奨するようなメカニクスになっていて、こんなの人間がプレイする必要ないじゃんと思ってしまう。
ということでプロの間で大流行していたPugnaばかり使っていた。癖はあるもののスキルセットが強力。サポートでも積極的にタワーを折れる1番、SavingにもDisableにもなる2番、設置するだけで大きなダメージを叩き出せるNether Ward、そしてダメージにも大回復にもなるUlt。Shardは弱いと思うけど…（相手にPLかNagaがいたら買うかも）。
ただPugnaも7.31dでかなりお仕置きを受けてしまったのでやめる。またDazzleに戻ることも検討しているが、単に数字上のbuffがあったというだけでメカニクスは改善していないので悩ましい。あるいはEnchantressもいいかもしれない。これもプロで猛威を奮っていたので7.31cでEnchantにレベルキャップがついてしまったが（なかったほうがおかしいだろ！）、それでもタンクやラットができるサポートというのは貴重だ。
Stunがないサポートは嫌がられるのでHoodwinkを使っていた時期もあったが肌に合わず全然勝てなかったのでやめてしまった。
二分探索木の形は、要素の数が同じでも、入れる順番によって変わる。
探索に必要な比較の回数も、木の形によって変化する。
要素n個に対して作れる木の形がxパターンあるとする。
それぞれの木の形T1~Txに対して平均比較回数が求まる。
それらの平均比較回数の平均をT(n)とする。
T(n)をnの関数として表すことはまだできない。
なぜなら木の形から平均比較回数を算出する方法が曖昧だから。
nからxを求める方法がわからないし、木の形（どうやって数学的に表現する！？）から平均比較回数を算出する一般的な方法もまだない。
では木の形から平均比較回数を計算する方法を考える。
上でやったように、ひとつひとつの要素に対して何回の比較で到達できるかを求め、その平均を出せばよい。
ここで、木の形を抽象化する。
あらゆる二分探索木は、親と左部分木と右部分木に抽象化できる。
木の形も抽象化する。
つまり、n個の要素からなる二分探索木を、左部分木の要素数（0~n-1）によってn通りに分類する。
部分木の中の形はわからないんだけど、今はわからなくていい。
左の部分木の要素数をiとする。
i=1のとき、この部分木は、親要素があり、左部分木には1つだけ要素があり、右部分木には形はわからないけどn-2個の要素が入っている。そういう木の形をしている。
実はそれだけわかれば、この木の平均比較回数はT(n)を用いて表せる。
繰り返すが、T(n)がどういう関数なのかはまだわかってない。でもT(n)を用いて表す方法はあるということだ。
それはこうなる
（略）
n個の要素を適当な順番で木に挿入したとき、木がどんな形になるかはわからない。
つまりiがどんな値になるかはわからない。
でもここでiは0からn-1まで同じ確率で現れると考える（本当？？？）と、平均値は求められる。
この平均値というのは、つまりn個の要素からなる二分探索木の平均比較回数だ。つまりT(n)だ。
T(n)をT(n)で表す式ができた。