miyado.dev

メインのクレジットカードを何枚か乗り換えてきている。
基本的に年会費無料で還元率が良さそうなやつ、という観点で選んできた。
だが、還元率が良いと、そのうちナーフされてしまう。
その度に替えるのも面倒なので、還元率そこそこでいいからずっと使えるやつにしたいと思うようになってきた。
そこまで真剣に探してもいないが、ぴたっとくるものが見つからない。
しばらくは今使っているのでお茶を濁すかー

プログラマのくせに最近覚えた英単語。
意味は脆弱性。

GitHub のセキュリティアラートが度々飛んでくるので覚えた。
しかし、依存ライブラリの依存ライブラリに脆弱性が入っていたりするとどうしようもないんだよなあ。
OSSなんだからどうにかしようはあるだろうと言われればそうですね、になってしまうのだけれども。

昨日の不具合の原因はイマイチだけど、もっとマシだと思えるコードに変えたら成功率が上がった。
いったんこれで様子を見てみる。

あと、バックエンド側の一部の汎用コードをライブラリに切り出す作業を始めた。
第一弾として、モジュールに切り出してみた。
月末に休みを入れてるから、そのタイミングで作業すれば終わらそうかな？

ログイン状態の確認を、ページを開いた瞬間からログインフォームを表示した瞬間に移動した。
現状ログインするのは自分だけなので、ページを表示したときに無駄なリクエストを飛ばさないようにするためだ。
その実装自体は簡単だったけど、その過程でコンポーネントの中にuseEffectが移動したので、storybookでちょっと面倒な不具合が起こった。
useEffect自体も中のAPI呼び出しをmswでモックするのも面倒のうちのひとつではあるけど、やればできるレベルでたいしたものではない。
最も厄介だったのがどう考えてもクラスコンストラクタのデフォルト引数がundefinedになっているとしか思えない問題だった。
これは調査も面倒だったし原因もよくわかってはいないが、storybook以外では発生していないことからビルドの問題とあたりをつけて最新のものを使うようにしたらなんとか直った。
これで一安心と思ったら、今度はsnapshot testが確率的に落ちるようになってしまった。
これはたぶん同じだけどエンドポイントを重複してmswでモックしているから。
直したいけど、そこをどう直すかのあたりがまだついていない。
大変だ。

冬休みの課題図書の続きとして読み終わった。
(上) の時点でノイズの性質や対策の主な概念はすでに書かれていた。
(下) はノイズ対策の適用事例やノイズ対策をするにあたっての障害といったより具体的な記述が中心だった。
(上) 単品でエッセンスを理解できるし、 (下) 単品でもやることやノイズ問題の全容を最後のまとめから掴める。
そういう意味でどちらかだけ読んでも問題なさそうだが、全編通して読むと一通りの議論を頭に入れられる。

私個人の身近な事例としては (下) で紹介されている人事評価や採用、あとは紹介外の事例だがエンジニアリングで言えば見積もりや技術選定も含まれるだろうが、こういっ判断には厳密な正解がない。
にも関わらず、独断と偏見でも決めることも不可能ではない。
それだけで進めるにはかなりセンシティブな業務なので、「内なるシグナル」（判断を下す際に当人の心のなかで納得をもたらす合図）以上の根拠をもって判断しなければならないという課題感をもっていた。
本書で紹介されている技法とバリエーションは客観性と再現性（=ノイズ耐性）をもたらす。
実際、構造化面接（の部分的な手法）を取り入れるなど先立って取り組んでいた。
本書を通じて、それをさらに推し進める根拠と自信、方向性を得られた。

プライベートの面では、そろそろ自宅の購入も検討したいので、この大きな判断の際にも本書の考え方を活かすつもりだ。
公私ともに数多くある判断の機会に対して、本書はひとつの基準を与える。