0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

第3回 Pythonしか使ってこなかった人が、AIを相棒に在庫管理システムをJavaで作り直す

0
Posted at

Ghostty×Sidecarで挑む要塞化とJava排他制御【Java×AIリプレイス奮闘記】

前回、4ペインのターミナル環境を整え、Java + Supabase の接続まで漕ぎ着けました。

「基礎工事は終わった。ここから実装だ」となったわけですが……

人間、欲が出るものです。
画面を見つめながら思ってしまいました。

「……画面、増やそうか?」

Javaサーバーを立ち上げっぱなしにしつつ、DBログを常時監視し、フロントエンドも動かし、負荷テストを叩き込み、Gitも操作したい。
ペインを切り替えたり、タブを行き来したりしている時間がもったいない。

そこで気づいたらやっていました。

8画面化(8ペイン)です。


1. 未経験が8ペインなんて普通するか?

普通はしないでしょう。画面を切り替えれば済む話です。

未経験エンジニアが「8ペインで開発します!」なんて言ったら、「形から入りすぎ」「絶対混乱するだろ」とツッコミを受けるのがオチです。

でも、男のロマンには抗えませんでした。

正直な話、一度やってみて今後の材料にしようと思います

【Mac本体:操作画面】                      【iPad (Sidecar):監視画面】
┌───────────────────┬───────────────────┐ ┌───────────────────┬───────────────────┐
│ 1. Spring Boot    │ 2. フロントエンド  │ │ 5. Supabase ログ  │ 6. 負荷テスト       │
│ (バックエンド起動)  │ (React / UI操作)  │ │ (DBアクセス監視)  │ (並行リクエスト)    │
├───────────────────┼───────────────────┤ ├───────────────────┼───────────────────┤
│ 3. Antigravity CLI│ 4. Git / 操作用    │ │ 7. Playwright    │ 8. API直叩き      │
│ (AI司令塔)         │ (コマンド実行)      │ │ (E2E自動テスト)    │ (cURLレスポンス)   │
└───────────────────┴───────────────────┘ └───────────────────┴───────────────────┘

Mac(メイン画面)のGhosttyで4分割、さらにiPadをSidecarで横に並べてサブモニターにし、そこでもGhosttyを4分割。

Ghosttyを使ってみたところ、
8つの画面で大量の文字がスクロールしても、
自分の環境ではかなりスムーズに動作しました。

目の前に広がったのは、開発環境というより「秘密基地の管制室」でした。

2. 8ペインで挑む本丸:複数拠点の「在庫排他制御」

もちろん、単なるロマンだけではありません。

今回この環境を作った目的の一つが、

在庫引き当ての排他制御

の検証です。

単一拠点のブラウザで動いていた頃とは違います。

複数拠点から同時にアクセスされた場合、

「残り1個の在庫を、東京と大阪が同時に取りに行く」

という状況が発生します。

ここでSpring Boot側に悲観的ロック

PESSIMISTIC_WRITE

を使った処理を入れ、並行アクセス時にどう動くのかを確認します。

今回の8ペインでは、

ペイン1:Java / Spring Boot
ペイン5:Supabase / PostgreSQLログ
ペイン6:負荷テスト
ペイン7:Playwright
ペイン8:API確認

という形で、それぞれ別の役割を持たせました。

例えば負荷テストから複数の購入リクエストを同時に送り、

Java側のトランザクション処理、

DB側のロック、

APIのレスポンス、

最終的な在庫数

を同時に確認します。

今までは画面を切り替えながら追っていた情報を、横を見れば確認できます。

これはかなり楽でした。

3. やってみて分かった「8ペインのリアル」

ロマン全開で組んだ8ペインですが、実際にやってみて強烈なメリットと同時に、課題も見えてきました。

良かったこと(光)
コンテキストスイッチが減る

「サーバーを止めてGitを叩く」
「ログを見るために別タブを探す」

といった作業の分断がかなり減りました。

Sidecarとの相性が抜群:

iPad側を「監視専用(触らない画面)」に割り切ったことで、Sidecar特有のわずかな入力遅延に悩まされることもありませんでした。

大変だったこと(影)
認知負荷がエグい:

8つのペインで一斉にログが流れると、まあしんどいですね

ミスタッチ:

止めてはいけない常駐サーバーのペインで誤って別のコマンドを叩きそうになるなど、画面の掌握には慣れが必要です。

実際、操作ミスを何回かしました。

費用の面:
倍率どん、さらに倍!!
(「ヒントでピント」で分かる人にはわかるでしょう)
という状態ですからね・・・・
トークン消費どうなる・・・・・??
コスト爆増間違いなしじゃない??

今回の気づき:道具に使われないために
今回、8ペインという極端な環境で作業してみて改めて実感したのは、「環境が高度になればなるほど、人間の冷静な判断が問われる」ということです。

AIに指示を出せば、8つの画面を埋め尽くすコマンドは一瞬で揃います。

ですが、並行アクセスでロックがどう動いているのか、なぜ在庫が狂わないのかを理解していなければ、8画面はただの「派手なイルミネーション」で終わってしまいます。

AIを操るペイン

コードを動かすペイン

結果を監視するペイン

それぞれが今何をしているのか、自分の頭の中に地図を持った上で、最後に「整合性が取れているか」を判断するのはやっぱり人間でした。

また先程書きましたが、慌ててやった結果、操作ミスもありました

結論:4ペインのほうが落ち着いてできます。

おわりに

最近多忙のため、記事の投稿がすすんでいません
なんとかこのシリーズだけでも終わらせたいと思いますので、読者の方は気長におまちください

ストックしておいてよかった・・・

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?