社員マスターはシステム入れたほうがいい。スプレッドシートでやってるところも多いけど早晩崩壊する。IDがかぶったりとかバリデーションが効いてないマスターを管理し続けるの無理になるので。vlookupされまくってるとかならまだいいが、たいていコピペされてるだけでマスターがずれて行って…….

タレマネシステムを人材管理DBとして使うなら人材管理を優先して見た目のための特殊対応を絶対しないみたいなルールを入れておかないときつい。この人の役職は人材管理ルール的には本当はこれなんだけど、タレマネ的にはこの役職扱いしたいみたいなのが絶対あるのよね.

タレントマネジメントと人材管理DBって似通ったチームが担当するからタレマネのシステム使って人材管理始められがちだけど、人材管理DBはタレマネから独立させてちゃんと管理してた方がいいと思う。本来はこうだけど見た目的にこういう構造にしておきたいみたいな運用がされることがかなり多い.

人間がやるべきはAIのためのガイドラインを引く仕事になるので、直近はみんなテックリードの役割ができないといけなくなるんだろうなぁ。そこを超えるのもすぐくるのかもしれないが.

AIにこのファイルを元にこれとこれをリファクタリングしてって言っても最初のファイルだけやって他のファイルがおざなりになってる事が多々ある.

空配列+didInit処理を入れたuseEffectがそのまま表示すると2回動くが、developper toolをひらくと1回しか動かないという謎現象に悩まされてる.

頭こんがらがってきた.

毎回droptableしてinsert tableしなおせばいいんだけど、初期データ投入って結構重いのでできるだけ正しい制御をしたい.

duckdbの初期化とtableの初期化とNext.jsの初期renderと画面遷移とで正しくデータを投入しながら正しくselectするの難しすぎる。下手にuseEffect使っちゃうと画面遷移で多重データ登録が発生するし、server componentとclient componentの境界でうまいこと初期化済みか判断しないといけない.

依存がtscだけという利点はあるのでbuildがtsconfigのreferencesで発火してくれるとかの利点はあるが、チーム開発という観点でみるとそこまでTypeSpecに対して優位性があるわけじゃない.

この辺のパーツをexpressとかhonoとか色々組み替えたいからtRPCを使わない実装をずっと試してる。そのパーツの1つとしてAPIの定義用ライブラリとかも作ったんだけど、今はTypeSpecあるのでそっちでいい.

これでいいじゃんになった。honoでもexpressでも使いまわせる超軽量tRPC的な感じの実装をしたかった

そうか、express v5でasync functionを受け付けるようになったからtry-catchをwrapする必要は別にないのか。包括的エラーハンドリングの方に任せればいいんだもんな.

copilotに考えさせてみてるけどあきらめて全然違う実装をはじめだした。あきらめんな.

いやでも `res.status(200).json(data)` みたいなのを毎回書かないようにしたいところなんだよな。うーん…….

createHandlerを経由させずに全部expressのerror handlerに任せてそれぞれのhandlerから返ってきたobjectがAPIの型をsatisfiesしてるかどうかのチェックのほうがきれいかなぁ.

createHandlerのgenericsでPromise<U>のところに型を明示的に渡してしまえばいいんだけど、そうするとTが推論で入らなくなってしまうというジレンマ。Tはなにも入れないでfnの値をinferさせたい.

await handler(req, res, next) のところで返り値の値が自分の定義したresponseの型と一致してるかどうかを書きたいんだが、できるだけ推論させたいっていう思考とぶつかりあってる。どうやったらうまく推論させられるか.

express v5に対応したwrap functionはこんな感じかなってのを試してる。もうちょっと型安全になるように書きたい

honoにもかなり流用してる書き方があるので6章以降を参照してもらえると嬉しい #PR.