はじめに
今回、以前作った在庫管理システムをJavaで作り直すことにしました。
……と書くと、簡単そうに見えます。
しかし、たぶん今回の連載は、これまで以上に時間がかかります。
なぜなら、
私はこれまでPythonを中心に開発してきて、Javaはほぼ未経験だからです。
しかも、単純にプログラムをJavaへ書き換えるだけではありません。
今回やろうとしているのは、
ブラウザだけで動いていた在庫管理システムを、Java＋Supabaseを使った複数拠点対応のシステムへ作り変える
というものです。
正直、
「これ、結構大変なこと始めたな……」
と思っています。
そもそも、なぜ作り直すのか？
以前、在庫管理システムを作りました。
こちらです。
Browser-Based Inventory Management System（GitHub）
このシステムは、ブラウザだけで動作することを目標にして作ったものです。
SQLiteのWebAssembly版であるsql.jsを利用し、ブラウザ内部でデータベースを動かします。
さらにIndexedDBも利用して、ブラウザ側でデータを保持します。
そのため、
- サーバー不要
- データベースサーバー不要
- 比較的低コスト
- ブラウザがあれば動かせる
という構成になっています。
GitHubのリポジトリには、プログラムだけではなく、要件定義書、技術選定基準、アーキテクチャ、データベース設計、画面仕様書、セットアップガイド、開発・検証ログなどもまとめています。
これはこれで、自分としてはかなり勉強になりました。
ただ、作っているうちに、
「これを実際に複数の拠点で使うとしたらどうなるんだろう？」
と思うようになりました。
例えば、
本社
↓
現場A
↓
現場B
↓
倉庫
というように複数の場所から同じ在庫を参照・更新する場合です。
ブラウザの中にデータを持っている現在の構成では、当然ながら限界があります。
今回は「Java」に挑戦する
そして、もう一つ今回の目的があります。
Javaを使ってみたい。
これまで私はPythonを中心に開発してきました。
FlaskやFastAPIなどを使って、いろいろなアプリを作ってきました。
一方で、Javaについては本格的に開発した経験がありません。
普通なら、
「経験のあるPythonで作ればいいのでは？」
となります。
私もそう思います。
ただ、今回はあえてJavaを選びました。
ゲームばかり作っていていいのか？
これまで、いろいろなものを作ってきました。
特に最近は、
- 大富豪
- 五目並べ
- AI関連のアプリ
- その他の小規模アプリ
など、ゲーム系の開発が多くなっていました。
ゲーム開発は面白いです。
状態管理やルール処理、AI、テストなど、勉強になることもたくさんあります。
ただ、ある時ふと思いました。
「ゲームばっかり作っていて、これでいいのかな？」
そこで今回は、以前作った業務システム寄りの在庫管理システムを題材にすることにしました。
せっかくなら、単なる作り直しではなく、
これまで使ってこなかったJavaを使ってみよう。
そう考えました。
バイブコーディングなら言語を変えられる？
そして、もう一つ今回試してみたいことがあります。
最近の私の開発では、AIをかなり使っています。
いわゆるバイブコーディングです。
もちろん、
「AIに全部作ってもらえばいい」
という意味ではありません。
設計を考えたり、仕様を決めたり、生成されたコードを確認したり、テストしたり、問題が起きたときに修正したり。
そこには人間の判断が必要です。
ただ、AIを開発の相棒として使うことで、
「自分が最初から全部書ける言語だけで開発する」
という制約を、ある程度外せるのではないか。
そんなことを試してみたいと思いました。
今までPythonで作っていたシステムを、今回はJavaで作る。
これも今回の実験の一つです。
ただし、今回はかなり時間がかかると思います
ここは最初に書いておきます。
私はJava未経験です。
そして現在、仕事などでかなり忙しい状況です。
そのため、今回の連載はこれまでのように、
作る
↓
完成
↓
記事を書く
という短期間の開発にはならないと思います。
かなり長い連載になる可能性があります。
場合によっては、
「今日はここまでしか進まなかった」
という回も出てくるかもしれません。
もしかすると、技術記事というより開発日記になってしまうかもしれません。
それでも、今回はそれでいいかなと思っています。
今回はさらに構成を変える
元のシステムは、
ブラウザ
↓
JavaScript
↓
SQLite WASM
↓
IndexedDB
という、ブラウザ完結型のシステムです。
これは「サーバーを持たない」という意味では非常に面白い構成です。
しかし、複数拠点で共有することを考えると、
本社
↓
現場A
↓
現場B
↓
倉庫
から同じデータを参照できるようにする必要があります。
そこで今回は、
各拠点のブラウザ
↓
REST API
↓
Java / Spring Boot
↓
PostgreSQL
↓
Supabase
という構成を目指します。
そしてSupabaseを使う
今回のデータベースにはSupabaseを使うことにしました。
理由は単純です。
PostgreSQLを利用できることに加えて、今回必要になりそうな認証などの機能も利用できるからです。
元のシステムでは、基本的にブラウザ単体で動いていました。
しかし、複数拠点からアクセスするとなると、
「誰がログインしているのか？」
という問題が出てきます。
そこで今回は、
Eメールによるログイン
も導入する予定です。
つまり今回、
Java
＋
Spring Boot
＋
PostgreSQL
＋
Supabase
＋
認証
＋
複数拠点
という構成に挑戦します。
……こうやって書くと、改めて結構大変そうです。
ところが、初日から問題発生
ということで、
「よし、まずはSupabaseの設定から始めよう」
となりました。
Supabaseを開きます。
設定します。
そして……
「あれ？」
ここで問題が発生しました。
パスワードが分からない。
以前もSupabaseを使っています。
使ったことがあります。
たぶん、アカウントもあります。
しかし、
「パスワードの管理どうだったかなぁ……」
となりました。
前に使っているはずなのに。
なぜか分からない。
Javaのコードを書く以前に、
Supabaseの設定で止まりました。
……。
いきなりこれです。
まずはここから
ということで、今回のJava開発は、
Javaの勉強
↓
Spring Boot
↓
PostgreSQL
から始まると思っていたのですが、
実際には、
Supabase
↓
ログイン
↓
パスワードを思い出す
から始まりました。
こういうところも含めて、今回は記録していこうと思います。
今回の目標
今回の最終的な目標は、
以前作ったブラウザ完結型の在庫管理システムを、Java＋Supabaseを利用した複数拠点対応システムとして再構築すること
です。
最終的には、
各拠点
↓
ブラウザ
↓
Java / Spring Boot
↓
REST API
↓
Supabase / PostgreSQL
↓
共有在庫データ
という構成を目指します。
さらに、
- Eメールログイン
- 拠点管理
- 在庫管理
- 在庫移動
- トランザクション
- 同時更新への対応
- 排他制御
- テスト
なども実装していく予定です。
ただ、完成するかは分かりません
ここまで書いておいてなんですが、
本当に完成するのかは、まだ分かりません。
Javaはほぼ未経験。
現在かなり多忙。
そして、元のシステムをそのまま移植するわけでもありません。
アーキテクチャも変えます。
データベースも変えます。
認証も追加します。
複数拠点対応も行います。
かなり大きな作業になります。
そのため、今回の連載はかなり長くなると思います。
途中で、
「今日はここまで」
となる日もあるでしょう。
エラーに悩まされることもあるでしょう。
AIにコードを書かせたものの、
「なんでこうなった？」
となることも、おそらくあるでしょう。
それも含めて記録していきます。
開発環境はいつものもの
そして今回も、開発環境そのものは大きく変わりません。
開発を進める相棒も、例によって例の如くAIです。
これまでPythonでやってきた開発を、
今回はJavaでどこまで進められるのか。
そして、
AIを相棒にすれば、未経験に近い言語でも、どこまで実用的なシステムを作れるのか。
これも今回のテーマの一つです。
おわりに
今回は、ほとんど何も作っていません。
Supabaseを使おうとして、
パスワードで止まりました。
それでも、ここから始めます。
元になったシステムはすでにあります。
だから今回はゼロから作るのではなく、
一度作ったシステムを、別の技術構成で作り直す
という挑戦です。
これまでPython中心だった開発をJavaへ。
ブラウザ完結型からサーバー型へ。
単一端末から複数拠点へ。
そして、認証やトランザクション、排他制御まで含めたシステムへ。
かなり長い連載になると思います。
途中で何度も止まるかもしれません。
それでも、
「何とか完成させたいですね。」
ということで、今回はここからスタートします。
次回は……
まずSupabaseの設定を終わらせます。
Javaは、そのあとです。