同じこと言いに来た。

"--i-meant-that"をコミットしたことがあるよ（リモートマシンを壊すコマンド用で、通常はメッセージを表示して10秒間^Cを押すかどうか考える時間を与えるんだ）。特にせっかちな同僚のためにね。結局、不適切に使われることはなかったからラッキーだったけど（でも、どれだけ運が良かったかは数えなかったよ）。

デザインパターンが役立つ場面だね、みんながそれに対して目を roll するけど。

もしできるなら、アプリケーションが取るアクションを明示的にモデル化して、それを実際に処理する中央のものに渡すのがいい方法だよ。そうすれば、ドライランかどうかを理解する必要があるのはコードの一箇所だけになる。理想的には、コアロジックからそれを返すだけで済む、"機能的コア、命令的シェル"スタイルがいいね。

「--wet-run」って音があんまり好きじゃないけど、何度か「dry-run」がデフォルトで、実際に変更を加えるには「--no-dry-run」が必要なツール（たまにサービスも）を作ったことがある。サービスに関しては、どこで動いてるかを自動で検知してほしいな。つまり、開発環境で動いてるなら、デフォルトで開発用のDBを使うって感じ。

毎回「rm --wet-run tempfile.tmp」とか「mkdir -p --yes-really-do-it /usr/local/bin」って打ちたくないんだよね。プログラムは、頼んだことをちゃんとやるのがデフォルトであるべきだと思う。一方で、すべてのツールに「--undo」引数があって、最後にやったことを元に戻せるといいな。

1つの場所（もしくは一般的にそれを制限すること）がその処理をすることで、dry_runチェックがコード全体を汚染するのを防げる。自動化パイプラインでヘッドレスVMが動かすCLIツールをたくさん管理してるけど、ほぼすべてのツールでこれをやってるよ。

コンソールツールにRESTやHTTPにこだわるの、なんでなの？！RESTの肥大化はマジでヤバい。最近の子供たちは、すべてをIP/TCP/httpsで動かしたがるんだよね。なんで？！まずはローカルツールを書くことを学ぼうよ。

この考え方には、ここ8年くらいずっと偏ってる。誰かが「--commit」を通さなきゃいけないときに間違って何かを変更したってことはまだないけど、「--dry-run」を忘れて何度も間違えて変更しちゃった人は何人も見てきた。

俺は「--wet-run」や「-w」のファンなんだけど、逆のやつがどれだけ深刻か、うざいかによるかな。

アプローチをランダムに混ぜたりしない方がいいよ、そうすると大変なことになるから。

以前使ってたツールの中には、実際に動かすってことを認識するために単語やフレーズを入力しなきゃいけないものがあった。メリットとデメリットはあるけど、間違ってパラメータを使うのが難しくなるから、あれは好きだったな。

パラレルディレクトリの重複排除ツールを使ってて、ハードリンクを利用したこのパターンをそのまま採用してるんだ。デフォルトでは、2つのパラレルディレクトリ構造の間で同じファイルがどれか教えてくれるだけなんだよ。実際にハードリンクでファイルを置き換えたい場合は、--executeフラグを使わないといけない。

ここで学んだことなんだけど、最近作ったスクリプトがあって、ダウンロードしたSharepointの内容を（ローカルだけで）全部削除して、関連するMS365アカウントもコンピュータから削除するんだ。デフォルトでは読み取り専用モードで動くようになってる。変更を許可するには、明示的なフラグを付けて実行しないといけない。さらに、アカウントを実際に削除する前に、DELETE-ACCOUNTと入力して、これが本当に自分の意図だって確認する必要があるんだ。今のところ、誰もクライアントの現場での熱い状況でもミスを犯してないよ。

さらに良いのは、-WhatIfと-Confirmの両方を有効にして、ユーザーの影響閾値の好みと相互作用するShouldProcess関数を提供することだね。めっちゃクールだよ。

これってドライランと統合テストを混同してない？私の知る限り、ドライランの目的は何が起こるかを理解することであって、何が起こるかをテストすることじゃないよね。後者はテストがあるし。

そのアイデア、いいね！TerraformやAnsibleみたいなアプリケーションには理想的だと思う。でも、この記事のようなものにはプランモードはオーバーキルだと思う。プランモードは、何らかのドメイン特化型言語やデータ構造を作る必要があるから、実行モードがそれを解釈して実行することになるんだよね。データが1日1回しか収集されないレポートツールには、かなりの複雑さが追加されると思う。

そうそう！今、いくつかの敏感なファイルを修正するスクリプトを作ってるんだけど、重要なデータをうっかり失わないようにこのアプローチを取ってるんだ。プロセスを3つのパートに分けたよ：1. ファイルシステムを歩いて、ファイルの現在の状態をキャプチャして、プランをディスクに書き出す。2. ステップ1のファイルの状態が変わってないことを確認してから、プランを実行する。新しいファイルの状態をキャプチャする。その上で、すべての操作をジャーナルにディスクに記録する。3. ステップ1と2でキャプチャしたファイルの状態を使って、データが失われたり予期せず変更されていないかを検証する。操作ログを手動で見たり（またはLLMにダンプしたり）して、何もおかしいところがないか確認する。これらの3つのステップは、3つの別々のスクリプトにすることも、同じスクリプトに3つのフラグを付けることもできるよ。

そんな感じで、コンパイラ（仕様から計画へ）と仮想マシン（計画からアクションへ）を実装している自分に気づくよね！

だから、Terraformの「plan」モードのアプローチが好きなんだ。何をするかだけじゃなくて、後でプログラム的に実行できる計画の形で教えてくれる。計画中に立てた仮定が変わったら、中止してロールバックできるんだ。で、「rm」コマンドでそれをどうやってやると思う？

こういう障害は、ユーザーが繰り返し行うアクションには効果がないんだ。ポップアップで「本当に削除していいですか？」って聞いてくるダイアログ -> ユーザーは自動的に「はい」をクリックしちゃう。だって、過去10回もそうしたし、仕事を続けたいだけだから。サーバー「alpha」にログインしたのに「delta」だと思ってた。ツールがサーバー名を入力するように聞いてくる。自分がalphaにいるって知ってるから「alpha」って入力する。間違ったサーバーを再起動しちゃう。Githubは、削除する前にリポジトリ名を入力して確認するように求めてくる。ユーザーはリポジトリ名を見て、考えずに入力する。あるいは、怠け者の僕みたいに、表示された名前を選択してドラッグしてフィールドに入れるから、入力すらしない。要するに、ユーザーはアクションを始めた時点で既にそれを決めてるんだ。彼らを一貫して立ち止まらせて再評価させるのはほぼ不可能で、すごく手間がかかって面倒なんだよね。彼らはその摩擦をできるだけ効率的に回避する方法をすぐに学ぶ（つまり、考えずに）。より良い解決策は、ただやっちゃうことだけど、間違ってたらユーザーが元に戻せるようにすること（もちろん、いつも可能とは限らないけど）。