bouzuya.hatenablog.com

ぼうずやのにっき

調子が悪い

なんだか調子が悪い。

『競技プログラミングの鉄則』 5.9 Grundy 数。昨日の 5.8 ニムと合わせていかにも知識問題という感じがしてあまり好きになれない。

twiq 実装メモ (30)

時間による制約。

  • docs/2022-09-08-user-v2.md
  • 実装できているか確認する
    • UserFetchRequested ユーザーごとで 1 日に 1 回まで
  • domain::aggregate::user::Error::AlreadyRequested が返される
    • UserRequestStarted 全体で 1 時間に x 回まで
      • インフラ側で起きないように制御する
      • rate limit error も失敗として UserRequestFinished に記録する
  • インフラ側制御なので未実装
  • Twitter API からのエラーレスポンスは未対応
    • UserUpdated は更新日時の古くなってしまうものは発行しない
  • 一応エラーにはなる

    // TODO: error handling return Err(Error::Unknown("".to_owned()));

  • 良さそう

worker の web からの分離。

  • worker を POST /_workers/{name} としている
  • これを分離したい
  • そのためには InMemory... をやめて外部に永続化しないと共有できない

InMemory → Firestore への切り替え。

  • 残課題の洗い出し
  • どこまで進んでいたんだっけ……
  • firestore は begin_transaction で transaction を得て
  • transaction をつけた読み込みで排他ロックを得て
  • transaction をつけた commit で書き込みとロックの解放をする
  • unique key の問題が残っていたはず
  • unique key は document の id にする方法が分かりやすそう
  • InMemory... でも unique key には同様の方法を取っているので単純移植に近くなるはず
  • EventStore に unique key 機能を組み込んだほうが良いかもしれない
  • InMemoryUserRepository が unique key (twitter_id, user_id の一意性) を扱えていなさそう
  • TODO コメントを追加
  • commit に Write をまとめる問題が残っていたはず

document の列挙。

  • EventStore ... events, event_streams
  • UserRepository ... users (user_id -> event_stream_id), twitter_users (twitter_user_id -> user_id)
  • UserRequestRepository ... user_requests (user_request_id -> event_stream_id)
  • WorkerRepository ... workers

明日は InMemory → Firestore への切り替えの続きから。

今日のコミット。