⇧ 何と言うか、「デジタル庁」、何ヶ年計画を想定しているのか分からないけど、
- 最終的なゴール
- ロードマップ
を整理した方が良い気がするんだが...
一応、
⇧ 総務省が「自治体情報システム標準化・共通化」なるページを公開してはいるものの、資料が整理されておらず、以下は、上記のページには見当たらない資料なのですが、
■青写真
■■https://www.soumu.go.jp/main_content/000817081.pdf
■■https://www.soumu.go.jp/main_content/000928801.pdf
■ロードマップ
■■https://www.soumu.go.jp/main_content/000817081.pdf
■■https://www.soumu.go.jp/main_content/000928801.pdf
⇧ といった感じで、どの資料を正しいとすれば良いのかがサッパリ分からない...
とりあえず、「デジタル庁」は、関連するシステム全体の「改修コスト」が少ない方針を検討する責任がある気がするんだけど、直近の自分たちのことしか考えていないように見えて仕方ないんだが...
そもそも、「デジタル庁」のタスクとなっている『標準準拠システムへの移行支援（全国の約34000システムが対象）』とあるのだけど、優先順位とかどうするつもりなんかね？
「制度所管府省」なる組織の想定が謎ですが、「制度所管府省」と「デジタル庁」が協業するとして、3年で捌き切れるんだろうか...
今、2024年8月で、締め切りが仮に2025年12月末とした場合、残り1年4ヵ月ほどしか無いのだけど...
まぁ、スケジュール組んでるんだから、期限内にタスクを完遂できる見積もりなんだろうけど...
単純計算で、1ヵ月で944台のシステムに対応する必要があり、仮に、1ヵ月の稼働を20日とした場合、
1日あたり、47台のシステムの移行を完遂させる必要がある計算になるのだけど、47人アサインすれば、まぁ、1日1台のシステム移行を完了させれば良いとなるかもしれんけど、1日の工数ですんなり問題なく移行できるもんなのかな？
移行に伴って発生するであろう改修作業の工数とかは考慮されて無さそうですし...
また、「デジタル庁」の想定している「移行支援」が具体的に、どこまで面倒を見てくれるのかもサッパリですしな...
仮に、34000システムが全量だとしても、現状、どの程度のシステム移行が完了しているのか、進捗率も謎ですしな...
「移行支援」は、移行の完了に責任を持たない、って考えでいるんだとしたら、
⇧ 上記は虚偽になってしまうので、改めた方が良い気はしますね。
「デジタル庁」が掲げている「ミッション・ビジョン・バリュー」のどれ1つも実現できていないのが哀しいところですが...
大規模システムなんだから、「全体最適」で考えて欲しいところですが、「デジタル庁」の人材で方針検討が難しいんであれば、外部から有識者を招聘したり試行錯誤して、失敗成功の如何に拘わらず「事例」として公開すれば、後進にナレッジを残すことに繋がる気がするんだが...
人間に対しても、システムに対しても育成していくって考え方が欠如してるんよね...
せめて、最低限、資料の整備だけでも時系列に漏れなくするようにして、公開しているページ内で参照できるようにしておいて欲しいところですかね...
PythonでDB接続情報はINI、YAML、JSON、.envのどのファイルに定義すれば良いのか
Pythonに限らず、プログラミング言語からデータベースに接続する際のDB（DataBase）接続情報をハードコーディングするわけにはいかないと思うので、何かしらの外部ファイルに定義することになると思うのだけど、
⇧ 上記サイト様によりますと、
の選択肢がありますと。
ただ、ネットの情報を見た感じでは、「コメントアウト」とか利用することができない「JSONファイル」は避けるという情報が多いように見受けられました。
まぁ、「VS Code（Visual Studio Code）」とかは設定周りで思いっきり、「JSONファイル」使っているのですが...
「VS Code（Visual Studio Code）」特有の設定ファイルにおける「JSONファイル」は「JSONC（JSON with Comments）」という仕組みを実現するライブラリを導入しているから、「コメントアウト」が利用できるようになっているからであって、通常の「JSONファイル」は、「JSONC（JSON with Comments）」のような仕組みを実現する何かしらのライブラリを導入していない限り「コメントアウト」利用できないので要注意ですかね。
開発環境、テスト環境、ステージング環境、本番環境などで設定が変わるからして、切り替えをどうするか...
おそらく、ソフトウェア開発を進める上で、
- development（開発環境）
- test（テスト環境）
- staging（ステージング環境）
- production（本番環境）
⇧ のような環境毎に、設定が変わることが一般的だと思います。
Wikipediaによりますと、
In software deployment, an environment or tier is a computer system or set of systems in which a computer program or software component is deployed and executed.
In simple cases, such as developing and immediately executing a program on the same machine, there may be a single environment, but in industrial use, the development environment (where changes are originally made) and production environment (what end users use) are separated, often with several stages in between.
This structured release management process allows phased deployment (rollout), testing, and rollback in case of problems.
Architectures
Deployment architectures vary significantly, but, broadly, the tiers are bookended by starting at development (DEV) and ending at production (PROD). A common 4-tier architecture is development, testing, model, production (DEV, TEST, MODL, PROD), with software being deployed to each in order.
Environments
The table below describes a finely-divided list of tiers.
⇧ とあり、大きく4つに環境を分けるのがスタンダードなんですかね？
で、環境毎に読み込む設定ファイルを変える必要があるのですが、
⇧ 上記サイト様にありますように、どの環境の設定ファイルを読み込むようにするかの条件を考える必要がありますと。
環境毎の切り替えをするには環境を判定できる情報が必要
で、環境毎の切り替えをするには、どの環境を利用するのかを指定する必要があり、ネットの情報を調査した感じでは、
- 環境変数「ENV」（環境毎に異なる値）を有効にしておく
- 実行時に環境を判定できる引数（環境毎に異なる値）を渡す
のどちらかのアプローチになるのかなと。
う～む、Gitのようなバージョン管理ツールで管理されない情報になってくると思われるので、デプロイ手順書のようなもので情報を明示しておかないと、確実に事故が起こりそうね...
JavaのSpring Frameworkとかだと、
⇧ 上記サイト様にありますように、環境毎の設定ファイル名を変えていますと。
Pythonの場合も、
- 開発環境
application-dev.yml - テスト環境
application-test.yml - ステージング環境
application-staging.yml - 本番環境
application-prod.yml
⇧ のような感じで環境毎に設定ファイル名を変えていく感じになるんですかね？
設定ファイルと設定値ファイルを分けるアプローチ
ちなみに、
⇧ 上記サイト様によりますと、
- 設定ファイル
- 設定値ファイル
を分けることで、環境毎の設定値の部分だけ可変にする方法もあるようです。
前提として、
- development（開発環境）
- test（テスト環境）
- staging（ステージング環境）
- production（本番環境）
のどの環境の設定ファイルについても定義する設定の項目数が同じである必要がありますと。
PythonにおけるDB接続情報はYAMLファイルに定義するで良さそう
話がいろいろ脱線しましたが、Pythonにおける「DB接続情報」を定義する外部ファイルとしては、「YAMLファイル」を利用する感じで良いような気がしますと。
後は、Python側で「YAMLファイル」から取得した情報を保持するクラス「.py」を定義して、DB接続処理用のクラスから読み込めるようにしたりすることが必要ですかね。
つまり、DB接続処理用のクラスを「依存性注入（DI：Dependency Injection）」する処理とかも必要と...
う～む、Pythonの標準的なWebアプリケーション開発のお作法が分からないので、実現したい機能に必要なライブラリが分からないのが辛い...
とりあえず、Spring Web MVCとかでの実装を見せて、こういうことしたいんだけど、って聞けたら楽なんですけどね...
いつかは、Pythonの学習のモチベーションが上がる日が来るんだろうか？
せめて、
- 技術が好き
- プログラミングが好き
- 何か作りたいものがある
のようなものが1つでもあれば、プログラミング学習のモチベーションが維持できるとは思うんですが、自分はいずれについても皆無だからなぁ...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
