1. Top
  2. yamori
  3. Commits
yamori

有給休暇計算を主目的とした簡易勤怠管理システム

Commits at 0b23f623226fbd6237a0298db1a9d73d29a4dfa1

  1. 0b23f623 backend: テキストログと JSONL ログを選べるようにした JSONL は便利だがテスト時などは見にくい。 Shota FUJI authored at Shota FUJI comitted at
  2. e95f3a9c backend: デバッグログを見れるようにする 見れなきゃ出しても意味ないので。 Shota FUJI authored at Shota FUJI comitted at
  3. 4440b52c backend: 管理者作成パスワードの初期指定 自動テストが書けないので。 Shota FUJI authored at Shota FUJI comitted at
  4. 6b71ff4f proto: ユーザの権限モデル定義 Shota FUJI authored at Shota FUJI comitted at
  5. f1497f78 backend: ログイン RPC Shota FUJI authored at Shota FUJI comitted at
  6. 05bda859 backend: イベント生成のヘルパ関数 自動生成されるコードがあまりにも酷くノイズでしかないため。 Shota FUJI authored at Shota FUJI comitted at
  7. a20b0398 backend: 管理者ユーザ作成時に PW を設定する 単純な抜け。 Shota FUJI authored at Shota FUJI comitted at
  8. e3344e20 backend: 初期管理者作成フロー テストは一パターンしかないが、初期パスワードを明示的に指定する機能が ないとテストができないので (ログをキャプチャするとかは勘弁) とりあえず サンプル的に書いてあるだけ。ちゃんと書くならある程度ヘルパ関数に出して いく必要がありそう。 スナップショットやプロジェクションあたりは PoC をベースにシンプルで クリーンな感じを目指して書いたが、もう少し詰めてきれいにできそうな 気がする。 Go 特有のボイラープレートは全然問題ではなかったが、 Protobuf/Go の吐く コードがやばすぎてやばさがやばい。現状、 * WASM 出力ができる * 2023 edition の Protobuf に対応している * ランタイムオーバヘッドが大きくない 言語が Go しかなくスイッチはできないので、ヘルパなり何なりで早めに対策 をする必要がありそう。特に `oneof` のコード生成がオワコンすぎる。 Protobuf 2024 edition が出たら生成コードが Opaque になって Builder 系の ヘルパが生成されるのでそれまで待つのもあり？ 2025 Q3 あたりでようやく 仕様が固まる見通しっぽいからあまりにも酷ければ移行を見越したヘルパなり Builder と似た機構を用意したほうがいいかも。 色々と中途半端なところや TODO コメントがあるが、これ以上完璧を目指すと diff を読むのが地獄なのでここで一区切り。 Shota FUJI authored at Shota FUJI comitted at
  9. 9aef8519 Zig 関連の設定を削除 利用しなくなったため。 Shota FUJI authored at Shota FUJI comitted at
  10. dd213fe7 vendor/go-sqlite3-js: WASM で DB が開けないのを修正 そもそもこのコードが動いていたのか甚だ疑問。 Shota FUJI authored at Shota FUJI comitted at
  11. 516cab77 backend: SQLite3 の導入 WASM でも動かすために色々追加している。 ただ、これ以上環境依存のツールを導入しなければ後は共通の コードを書くだけになるはず。 Shota FUJI authored at Shota FUJI comitted at
  12. 115fc47f backend: すべて Go で書く WASM の出力がおかしいのはどうやら v1.24.1 限定のバグだった模様。 v1.23.8 と v1.24.2 では再現しなかった。リリースノートにはないので バレないようにしれっと直したのだろう。 pwa パッケージにサンプル的なコードが入っているが、これは動作確認用。 後で消す予定だが、どのみち pwa パッケージは使わなくなるのでそのまま になる可能性も。 Shota FUJI authored at Shota FUJI comitted at
  13. 82244747 backend: SQLite3 での Event Sourcing スキーマ SQL 文の正常性確認は実際に行いそうなクエリや INSERT を書いたものを `001_test.sql` と保存した上で、 ``` $ cat migrations/*.sql | sqlite3 -table ``` を実行した。 本来であればマイグレーションの実行までを一纏めにしたかったが、 ここに来て Zig の protobuf である Gremlin のコード生成が全然ダメ なことが発覚。特に `oneof` を普通のメッセージと同様に出力するため 利用側でどのフィールドが判別できない ("_" でプリフィクスされてる フィールドが `null` かどうかを見ればわかるが、非公開だしハック) ので実用に耐えないことが分かった。他の Protobuf コード生成ツールは Protobuf3 しか対応しておらず、 edition 向けのちゃんとしたツールを 書くしかない。しかし工数的に、というかペース的にそんな余裕がないので Go (WASM 出力できれば) か Rust (Go がウンコだったら) での書き換えを する予定。そうなると更に低レベルな内容のコミットとなるため、別の コミットにすることとした。 要約すると、大量の環境整備が入るけどこの SQL 捨てるの勿体ないから コミットしたよ。 Shota FUJI authored at Shota FUJI comitted at
  14. 7db4a3ee backend: server.zig を削除 サーバも WASM を使うことにしたため。 Shota FUJI authored at Shota FUJI comitted at
  15. f6062794 proto: ユーザ作成 RPC Shota FUJI authored at Shota FUJI comitted at
  16. 35f896e8 proto: 単一ワークスペース前提の workspace/v2 モジュール SingletonWorkspaceService を作ったが、既存のモデル定義を拡張していくと どうしてもノイズが多くなったり注釈が増えたりしてくる。 根本的なアーキテクチャ変更なのでバージョン変更は妥当と判断し、最小限の モジュールを作成した。 根本的な変更の理由はユーザ管理・ログインを実際に実装しようとして既存の サービス設計では実現が難しい、できてもハック盛りだくさんになってしまう ため。労働者管理とユーザ管理を分離しようとして設計した v1 だったが、 結果的にそれのせいでユーザ管理が追加できない事態となってしまった。 Shota FUJI authored at Shota FUJI comitted at
  17. 8edcdcf5 proto: ユーザモデルをワークスペース配下に移動 シングルトンワークスペースがメインになる以上、ユーザはワークスペースに 属するデータとなる。 Shota FUJI authored at Shota FUJI comitted at
  18. eb9ece9c proto: 内容がおかしいコメントの修正 多分コピペ。 Shota FUJI authored at Shota FUJI comitted at
  19. 3abc4595 proto: カスタムフィールド 社員 ID などを設定して CSV などでエクスポート、外部システムで 紐づけなどのユースケースがあるため必須要件となる。 Shota FUJI authored at Shota FUJI comitted at
  20. 87be8e69 proto: ログアウト RPC Shota FUJI authored at Shota FUJI comitted at
  21. c433adc6 proto: ログイン RPC Event Sourcing をするにしろ通常の CRUD SQL にするにしろ、 まずこれが必要になる。このあとのユーザ周りの設計にも必要 になってくる。 Shota FUJI authored at Shota FUJI comitted at
  22. b24ca3f0 backend: connectrpc を使ったサーバ リクエストを受けると Go -> Zig (WASM) -> Go という順番で処理を 行う。 connectrpc のデザイン制約上 binary -> Go struct -> binary -> Zig struct -> binary -> Go struct -> binary と非常に非効率な シリアライズ・デシリアライズをしてしまっている。ただ、現状 Zig で まともな gRPC ライブラリがないこと、自前の HTTP2/3 をベースにした 実装だとプロファイルやテストで実装コストが膨らむことから当面は この非効率実装を妥協点とする。 長期的には独自の protobuf 用 RPC + rate limit 付きの (非効率な) 現状と同じ connectrpc 経由の外部向け gRPC というのが無難そうか。 Shota FUJI authored at Shota FUJI comitted at
  23. 75d721c8 backend: Wazero を使った Go からのコア呼び出し gRPC やらサーバ周りは Go が充実しているため。 また、サンドボックスで実行されることにより I/O を限定でき、 安全にコアを実行できる。 Shota FUJI authored at Shota FUJI comitted at
  24. f5eafc11 backend: WASM バックエンド DB とかはない。そもそもどんな DB アクセスにするのかとか 設計とか考えてないし。 Shota FUJI authored at Shota FUJI comitted at
  25. 62a6766e backend_core: Zig から protobuf を利用する 使っている Gremlin というコード生成ライブラリと Zig という言語の 仕様上、 proto でライブラリを出力、というのはハックになってしまう。 そのため、多少効率は悪くなるが利用側で都度出力する形にした。 Protobuf は .proto 毎にソースファイルを生成、という形だが Zig は 配布形態に合わせたパッケージングとなる。つまり、静的・動的な ライブラリや実行ファイルがモジュールの単位となる。そのため「複数 ファイル群をモジュールとして公開」ということはできない。 このコミットでは protobuf の wkt (well-known types) の追加も 含まれている。これは Gremlin が protoc に対応しておらず wkt が 含まれていないため。このベンダリングに伴うライセンス周りの変更も 入っているため少し変更ファイル数が多くなっている。 Shota FUJI authored at Shota FUJI comitted at
  26. e551c6fc proto: 単一ワークスペース向け構成 RPC 現実的な運用としてマルチワークスペースはなさそうということが判明。 自分の組織だけのデプロイなのにワークスペース選択やらがあるのは不便なので 単一ワークスペース向けのフローを考えそれに必要な RPC を実装した。 Shota FUJI authored at Shota FUJI comitted at
  27. 90396a7f proto: 疎通確認RPC 実装初期やテスト、ステータス確認などいろいろ便利なため。 Shota FUJI authored at Shota FUJI comitted at
  28. 25753283 test_go_consumer: サンプルパッケージの削除 Shota FUJI authored at Shota FUJI comitted at
  29. 1fcfa4b3 proto: Go バインディングの出力 サンプル用にテストのパッケージも追加している。 Shota FUJI authored at Shota FUJI comitted at
  30. 24c1c392 docs: アーキテクチャ図を更新 "ship fast" を優先するため使いやすい技術スタックにした。 また、 web ホスティングが優先要件となったためそこも含めた。 Shota FUJI authored at Shota FUJI comitted at