Git＋PyCharmで開発スタート。3本のブランチの先にあるZbプラグイン開発

今日からPyCharmでGit運用開始。色々分かってきた。またPythonでのGUI開発の課題も見えてきた。主にTkinterについてだ。

（約 3,800文字の記事です。）

Git必須。快適過ぎる。

とりあえずGitHubではなくて、ローカル環境限定のGitリポジトリの話。プッシュとかプルとかそういう話はまったく出てこない。

エンジニアからすれば当たり前のことしか書けない。

そもそもソースコードにバグがなければプログラムなんて絶対に動くのだ。ソース管理とかバージョン管理とかIDE環境とか、作業効率の問題でしかない。動くソースを書けるかどうかとは、本質的には無関係だ。

だが逆に効率を考えた場合、パズルの組み合わせのように、そして先人達の知恵の恩恵を如何に活用するかによって、効率はまったく変わってくる。本質的に「動くか動かないかというコード」とは無関係に、作業効率の話だ。

Gitを使うことでかなりの信頼性をもって1時間前や10分前のソースを「チラ見」できる。そして30分～1時間程度で、実装の小パック単位でコメント付きのcommitをGitに登録できる。Gitでは当たり前のことだが、PyCharmというIDE環境をガチで使ってみてようやく気が付いた。バグでjsonの中身が空っぽになってしまったが、少し前のcommitから数クリックで復活させられた。

餅は餅屋。プロにはプロの作法がある。Gitもその一つだろう。IDE環境もそうだろう。

なのでPythonについては誰しもが言っているようにPyCharmは堅い堅い選択肢の一つ。当然Gitともパーフェクトに相性がいい。むしろGUI環境付きGitの一部とすら言える。

作業単位をcommitで区切ってメモを残せる

これ、心理的にかなり楽になった。休憩を簡単に取れる。ちょっとした小さな作業でも一区切り付いたタイミングでコメント＋commitすれば、気分爽快に休憩できる。気兼ねなしに思考をコーディングから切り離せる。

だが使ってみてどんどん疑問も出てくる。プログラミングでは「1つ解決して3つ疑問が出てくる」パターンが多い。無限地獄かよw

Gitについてもバイナリファイルの扱いがどうなっているのかよく分かっていない。バックアップされてる？されていない？何だかされていないっぽい？明日検証予定。

そしてバックアップされないのであれば、分かっているファイル形式については除外指定した方が気分がいい。その方法とは？明日調べる。

Gitは基本的にCUIだが、PyCharm上から色々設定できる

Gitはテキスト通り、基本的にはターミナルでCUIで詳細な操作ができるような仕組みになっている。だが色々触ってみたらPyCharm上からボタンプチプチとGUI上でもGitに指示を出せることが分かってきた。

ではなぜ教科書では敢えてCUIから教えているのか？と思ってみたが、その理由も分かる。というのもGUIだと「ソフトごとに実装がまったく異なる」ため、1つのGitコマンドを実現させるためのGUIの位置や操作方法が異なる。PyCharmではこうだがVS Codeではこう、となる。だがどちらであってもCUIでコマンドを打ち込めば「全く同じ指示」になる。

なのでGitの基本はCUIで押さえておきつつ、より便利に使うために各自の環境でGUI対応ソフトがあればそれも使おう！というのが王道だろう。

PyCharmではブランチ名の変更だったりマージだったり、右クリックで色々眺めてみて「お、これもできるぞ」などと観察している。楽しい。

そりゃ、やっぱGUIで操作したいよ。CUIに特に愛着はない。LinuxやBSDよりも、Windowsが好きなのです。とにかく右クリックなのである。

Tkinterの学習の必要性を感じる

結局PythonでシンプルなGUIを作るなら、3周くらい回って結局鉄板のTkinterなのかな、と思い始めた。PySimpleGUIは有料化なのにバグありで信頼できないので使いたくない。となるとTkinterかPySide6くらいが鉄板候補。だがPySide6は学習曲線が急＝習得に時間がかかるができることは多い。ネックなのは前半に必要な学習時間とエネルギーが割と多めという点。学習曲線が急というのはおそらく二次関数的な伸びになるためだろう。

シンプルなGUIかつPythonで動くGUIを！となれば、最初からわかりきっているTkinter一択だったのかもしれない。回り回って避けてみても、戻ってくるところはここなのかも知れない。

ChatGPTに詳細に指示をすればTkinterで指示通りのGUIを作ってくれる。バグもない。問題なのは私がその中身を読めないこと。なのでちょっとした拡張もできない。ソースコードを見ればなるほど納得、うん、分かりにくい構造だ。PySimpleGUIが誕生した理由も分かる。コードを見ただけではGUI構成が分からん。実行してみて初めて「おぉそうだったのか」となる。

だがそれを許容する場合、つまりはソースコードから即GUIを想起する必要がないほどじっくりとプログラマが仕様を理解した上でコードを実装するならば、ソースコードの並びとGUIの配置が一致していなくても問題ない。

むしろ、このボタンを押した時にどういう挙動や関数が発動するのか、これに尽きる。そこが分かりさえすれば何とでもなる。GUIは結局は押したり入力したりした後の動作が問題になるだけなのだ。（シンプルな場合）

今の知識ではそこが分からん。Tkinter特有の「縛り、記法」があるっぽいのはよく分かった。その中身が理解できないので自力では改良できない。ChatGPT頼みになっている。これはよくない。

なのでTkinterでGUIの基礎学習の必要性を強く感じた。速習で構わない。じっくりではなくて簡単な物をサクッと作るための知識が必要。かき集めるか、教材を買うか。何にしても時間効率を最優先したい。YouTube動画を集めまくる時間があったら時間を金で買う感覚で優良教材を買いたい。

イベントドリブン型と関数ドリブン型が混在中

これも結構まずい。一応仕様通りに動いているが、気分は悪い。Tkinterで実装中の「常時表示型ウィンドウ＋複数ボタン」はイベントドリブンだが、ZscriptでZbrushのボタンを押して動くものは関数ドリブン型。脳みそが混乱する。そしてZscriptでの開発が長かったので関数ドリブン型に思考が引っ張られる。だがPythonでのGUI実装は基本的にイベントドリブン型になる。というかGUIアプリの場合はほとんどがイベントドリブンではなかろうか？

なのでここら辺の経験不足・知識不足も補う必要がある。

だがまず大切なことは「作りたいツールを作り上げること」だ。動けばいいのだ、バグがなければいいのだ.内部動作の仕様に興味があるのはエンジニアだけ。一般ユーザーにとって最も大切なのは「ユーザー体験、堅牢なアプリ」これだけだ。なので今はリリース版Ver.1を目指して、問題ないところは先送り。フューチャーリクエスト的に先送り。

ブランチは3本柱で

とりあえずプロダクト用のリリースブランチ、開発用のディベロップメントブランチ、その間でベータテスト用のステージングブランチ。この3つで運用することにした。多分、ごく普通の運用だと思う。細かい単語の使い方はおいといて。開発、ベータテスト、実装してリリースの3ステップ。

今日からのGitはしばらく開発のDEVブランチで1本道になりそう。GUI関連のテストと実装の繰り返しなのでDevelopmentのゾーンだ。あとpyを呼び出すZbrush側のボタンUIも少し実装が必要。もう少しDEVブランチでの作業。

リリース時期はもう決めているが、当初の予定を変更して「フル機能でも期間限定で無料公開」にしようと思っている。というのも、ベータテスター様の予定が合わず、十分検証できないままリリースすることになりそうなので、その間は無料だけど無保証な、というお約束でリリースするかも知れない。まだ迷っている。

だがPyarmorはexe化してもタイマーで「利用可能時期」を区切れるので、その機能を使って1ヶ月限定くらいで有料版も無料リリースしようかと思っている。その間の変更なども多分3つのブランチを行ったり来たりするだろうから、初めての経験で右往左往するのも込みで、色々不足が出そうだからこその無料公開という考え。1ヶ月も四苦八苦すれば安定するだろうから、その頃から正式版を有料化仕様と思っている。

何にしても、今回のZbrushプラグインは、開発手法から管理手法まで、徹底定期に「手順と開発スタイル」にこだわっている。本気度が今までとは違うことが分かってもらえるだろう😊

今日はこれまで～。

今回の創作活動は約1時間（累積 約3,876時間）
（1,124回目のnote更新）