人生のイベント発生機能の改修(β版)

最近までは、 イベント発生が外部依存となりがちであったが、 2024年11月から12月にかけて、自己完結的なイベント発生循環システムが生まれたように思える。

これは適応の結果なのだと思う。

発生動機の類推

外部介在したイベント発生を期待してしまうと、 どうしてもパフォーマンスの下振れ上振れが激しくなる。

下振れが続いたときに生理的システムエラーが発生しやすい。

また上ぶれがほとんどないと言うこともわかり始めたため、安定性の高いアルゴリズムに変更するのが良さそう。

新旧比較と技術ポイント

旧版の処理

1. 外部の全イベントをfetchし、パラメーターをcountableに変換し、Eventテーブルに保存する。
2. Motivationテーブルから属性が同じもの・関連度の高いものを全てfetchする。
3. 対象のEventインスタンスのthresholdを、紐づくMotivationが超えているかチェックする。
4. 足りなければMotivation.create!する。
5. EventMotivation.countその後日付ごとにreadしていく。

1と4の処理がかなり重たいため、改善する必要があったのだと思う。

Motiovationをcreateしてしまうと、 もともと別動線から生成されるMotivationと違う 性質のものになるため、

新版の処理

若干複雑度上がる気がするので概略のみ示す。

1. イベントの解釈を変更する。
2. 期間指定でイベントをストックし、最もモチベーションや必要性や優先度が高いものを選択する。
3. 選択中のイベント以外は、一定サイクルで破棄する。
4. それ以外に人的ファイアウォールを設けることでそもそもイベントが発生しないようにする。
5. あらかじめ固定イベントを作ることで、その他のイベントへのリソース分配の回数を減らす。

0番目の工程がすべて

顧客からクレームが来そうだけど、一旦それでビジネス的には利益が出るといういかれた上層部の判断らしい。

場合によっては邪悪なので注意が必要。

今回は家事や雑務や趣味の作業もイベントに含むように設計した。

感想

2025年1月〜から本格運用をする。

やっぱきちんと要件を聞いて設計・実装しないとだめで、その場の運用でカバーでは、まかり通らないなと思った。

そんで、機能のリプレースには数日〜数週間単位で時間がかかることも、肝に銘じておこう。

「ウェットウェア」は、回路を鍛えるプロセスが必要です。