Scribble at 2025-01-29 16:56:17 Last modified: unmodified

ツールの運用について、幾つか方針を変えた。

まず、色に依存した UI に慣れると、いざ着色されていない表示になると意味不明になってしまうことがあって、その典型は systemctl で status オプションをつけてデーモンの状態を表示したときなんかが相当する。セットアップされた状況でのカラースキームがサーバ会社ごとに違うし Linux などの OS ディストリビューションによっても異なるので、最初からなんにもしなくてもターミナルに着色されている場合もあれば、最初から全くモノクロという場合もある。そして、systemctl コマンドは着色されていることが多いので、これで status を確認したときの状況に慣れてしまうと、モノクロの状況では、デーモンが生きてるのか死んでるのか直感的にわからない。もちろん、英語のステータス・メッセージを「読めば」いいわけだが、読みたくないか読む必要がないくらい直感的に使えるからこそ使ってるわけで、やはり色に依存した使い方は致命的なところでなにか馬鹿げたことに依存してしまうことになる。改めてコマンドのレスポンスを正確に把握するようにして、敢えて言えば systemctl に最初から色をつけないような環境設定にすらしたほうが安全だと思った。何が緑マークが安全だ。

そして次に、GitHub Desktop の運用をやめた。そもそも単独で開発に従事していて、GitHub そのものは単なるバックアップ目的でしか使っていない。誰かにコードを見せたり公開するわけでもないし、そんな必要は将来もない。なので、ただのバックアップであれば、ローカルのディレクトリそのものが既に Dropbox に同期しているフォルダの配下にあるのだから、GitHub を使う必要がない。そして、GitHub を使うと夥しい量のセッション・ファイルがゴミのように作られて、これが結局は Dropbox クライアントがメモリを食い荒らす原因にもなる。正直、この /.git 配下にある膨大なファイルが作られる限り、Git そのものだって使う気にはなれない。ファイルベースのデータベースにもそれなりの効用はあるけれど、こんな数はいくらなんでも酷い。なんで SQLite とかで実装しないのか。そして、GitHub Desktop を使っていて昔から困るのは、ターゲットのフォルダにクローンすると、そのフォルダにリポジトリ名でフォルダを先に作ろうとするという、非常に筋の悪い挙動がディフォールトになっていることだ。こんなことを期待したり想像してファイルやディレクトリを「コピー（ダウンロード）」するような感覚で使う人はいない。これは、ふつうじゃないと思った。たぶんバカが設計してるアプリケーションなんだろうなと。