pOmorate
2025-11-02
1000件の予測データを更新したらEdge functionが10秒の処理時間に収まらなくてタイムアウトしたので500件にした
これだと6000件処理されるまでに12回のretrainが必要ね
一旦ローカルで全件に対して実行
大して時間はかからない、10秒以下
Edge functionが遅い
2025-11-05
新規ユーザがアクセスしたときにランダム提示からスタートするのはイマイチかなと思って「みんなの評価データでの推測」を出すようにしたが、よくなかったかもな
「面白さは主観的であって人それぞれ異なっている」というテーマと逆行している
2025-11-06
ローカルのWebWorker実装で100件に400msecだったから6000件でも24秒ね
UIをブロックしないのでバックグラウンドで24秒くらいなら全然あり
wasmにする案もあったけど、そこまでやらなくて良さそう
ボトルネックがDBの更新の方にあるから
Claude Codeが少しポンコツになってきたのだが、page.tsxが2800行もあるのでそれは良くないよなぁという気持ちになった
まずPlaywrightテストをちゃんと通るようにしてから、挙動を変えずにリファクタリングするように指示してみた
ファイルの構造を分析しました。2800行のpage.tsxを以下のように分割します：
分割計画
1. types.ts - 共有型定義 (Item, ComputationHistory等)
2. utils.ts - ユーティリティ関数 (getLabel等)
3. hooks/ - カスタムフック
useAuth.ts - 認証処理
useRoomData.ts - データ取得
usePredictions.ts - 予測計算
4. components/ - UIコンポーネント
モーダル類
統計表示
計算履歴
段階的に抽出していきます。まず型定義とユーティリティから開始します。
ちなみに計画の途中で計画を忘れてた
> ✅ 完了したもの
> 1. types.ts (61行)
> 2. utils.ts (24行)
> 3. components/ (モーダル類)
> ❌ 未着手
> 4. hooks/ - カスタムフック（未作成）
> 5. components/ - その他UIコンポーネント（未作成）
> 成果
> 削減量: 2800行 → 2445行（355行削減、13%削減）
> ビルド: ✅ 成功
> テスト: ✅ Playwright smoke test 通過
> 残りのhooksとcomponentsを抽出すれば、さらに500-800行程度削減できる見込みです。続けますか？
だから大きな作業の時にはまずファイルに書かせるのが有益なんだな
他の人の予測結果が観れるといい
予測結果をクリックして詳細表示できるといい
1次ソースまで深掘りできるといい
Googleアカウント連携がエラーになっている
Q&AペアのQから抽出してしまっている
ポジティブな評価のついているものだけ残して入れ替えて良い
もっと知りたい
ランダムな順で読むのは辛い
これは「読む」のメンタルモデルの設定次第だと思う
SNSはランダムに流れてくる
既存の知識体系が存在するならそれとマッピングがあるといい
ランダムではなく既存のものに対するアップデートを抽出する
APIで流し込めるといい
"Engineer's way of creating knowledge" the English version of my book is now available on [Engineer's way of creating knowledge]
(C)NISHIO Hirokazu / Converted from [Scrapbox] at [Edit]