- Jeffrey Snoverは、Windowsをコマンドラインで管理可能なサーバーOSにするためにPowerShellを推進し、GUI中心だったMicrosoftの文化と組織的な抵抗を乗り越えなければならなかった
- 初期のUNIXツール移植は、WindowsがファイルよりもRegistry、Active Directory、WMIのようなAPIに依存する構造だったため、サーバー管理の問題を解決できなかった
- WMICでWMIベースのコマンド70個を作った後、テストのボトルネックとコスト問題を減らすため、メタデータベースのコマンド生成エンジンへと方向転換した
- PowerShellの前身であるMonadは.NETとLonghornの流れに乗って始まったが、Longhornのリセット後にWindowsから押し出され、ExchangeチームとWindows Server組織の支援で復活した
- Snoverは職位と報酬の損失を覚悟してPowerShell 1〜4に集中し、このツールはWindows管理自動化とOfficeのクラウド移行の基盤となった
GUI中心のWindowsとデータセンター管理の問題
- PowerShellはWindowsのシステム管理を変えたコマンドツールだったが、Microsoft内部で最初から自然に受け入れられたプロジェクトではなかった
- 当時のMicrosoft文化はGUI中心で、Bill Gatesが
command.exeを見るのはこれが最後になるだろうと語った逸話が出るほど、コマンドラインインターフェイスは時代遅れのものとして扱われていた
- SnoverがMicrosoftに加わった出発点は、Windows NTベースのOSをデータセンターとエンタープライズ市場に合うよう変えなければならないという問題意識だった
- 目標はSun、IBM、HPのようなUNIXベンダーと競争することだった
- Intelとオープンなハードウェアエコシステムはコスト面で利点があったが、サーバー管理ソフトウェアは十分に良くなかった
システムインテグレーター依存を減らす管理者モデル
- Windowsサーバー管理では、多数のサーバーをクリックで設定する必要があり、企業ごとに必要な構成が異なるためシステムインテグレーターへの依存が大きくなり得た
- Snoverは、インテグレーター費用が大きくなればWindowsの価格優位が消えると見ていた
- 例として、ハードウェア10、ソフトウェア2、システムインテグレーター40というコスト構造を挙げた
- 顧客関係と価値がインテグレーター側へ移ることも問題だった
- 代替案はUNIX式のプログラマー管理者モデルだった
- 小さなツールを組み合わせて固有の問題を解決し、自動化する方法である
- Windowsにも「次へボタンを押すだけの管理者」ではなく、スクリプトと自動化を扱う専門的な管理者層が必要だった
UNIXツール移植が合わなかった理由
- 初期の解決策は、Windows Services for UnixによってWindows上にUNIXシェルとAWK/GREP/SEDのようなツールを載せることだった
- しかしWindowsの管理構造はUNIXとは異なっていた
- UNIXはファイル中心のOSなので、ファイルを操作してプロセスを再起動すれば多くの管理作業を処理できる
- WindowsはRegistry、Active Directory、WMIなど、APIの背後に機能がある構造だった
- AWKはRegistryに、SEDはActive Directoryに、GREPはWMIに直接は合わなかった
- WMIには管理作業のための可能性があったが広く使われておらず、SnoverのチームはWMIオブジェクトを扱うコマンドラインツールを作ろうとした
WMICとメタデータベースのエンジン
- Windows XPの時期には、コーディング期間が10週間しかないという制約の中で、WMIベースのコマンドラインインターフェイスを作らなければならなかった
- 契約エンジニアを活用して70個の作業を実装したが、Windowsサーバー全体の管理に必要な範囲にはまったく足りなかった
- Microsoft内部では、テスト組織が承認しなければ機能はリリースされない仕組みで、コマンドが増えるほどテストのボトルネックも大きくなった
- SnoverはHTMLとブラウザの関係のように、個別コマンドをコードではなくメタデータと見なし、共通エンジンだけをテストする方式を推し進めた
- エンジンがコマンドを生成し、各コマンドの設定はXMLのような形式のメタデータで表現するアプローチだった
- 彼はクリスマス休暇中にメタデータを書き、72個のコマンドを作った
- 既存の70個のコマンドには約400万ドルかかり、エンジンには約6万ドルかかったと回想している
- エンジンにフィルタリングやフォーマットといった機能を追加すると、すべてのコマンドが一緒に良くなり、これはPowerShellアーキテクチャの重要な前兆となった
Longhorn、.NET、Monad
- Bill Gatesは、Windows 98ユーザーがXPへうまく移行しない問題を見て、Longhornを新しいWindows 95のような転換点にしようとした
- Longhornには.NETベースの開発方式、WPF、WCF、新しいストレージモデルなどが含まれる予定だった
- Snoverは、.NETがWindows管理の範囲を広げる手段になり得ると判断した
- WMIプロバイダー作成は十分な勢いを得られなかったが、Bill Gatesは.NET採用を強く推進していた
- .NETの上に管理ユーティリティを載せれば、より広いカバレッジを得られると見ていた
- 別の組織がK-shellをポーティングしてシェルを作ろうとすると、Snoverはより良いアプローチを説明したが、説得には失敗した
- 彼は部屋にこもって約1万行のプロトタイプを作り、そこにはPowerShellの中核的なアーキテクチャ原則が入っていた
- デモの後、そのチームはアイデアを受け入れ、Snoverはこれが自分の最高のアイデアかもしれないと考えた
- このプロジェクトに参加するため、数百〜千人規模の製品・サービスのchief architectの役割を降り、事実上の降格を受け入れた
Monad Manifestoとチームの説得
- 新チームはプロジェクト名をMonadと決め、人員不足のため一部の作業をインドに外注した
- Snoverはプロジェクトのビジョンと成功への道筋をそろえるため、Monad Manifestoを書いた
- 問題、既存のアプローチ、新しいアプローチ、価値、差別化ポイントを整理した
- 管理者、プロバイダー、開発チームなど、利害関係者ごとにどのような価値を提供するのかを明確にした
- Microsoftの各チームにはやるべきことが多く、コマンドラインインターフェイスを作らなくても解雇されず、作っても昇進につながらない状況だった
- Monadの提案は、各製品チームが自分たちのオブジェクトを操作するコードだけを書き、残りはPowerShellが提供するというものだった
- フォーマット、ソート、フィルタリング、パーサー、リモート実行、権限昇格などはPowerShell側で提供する
- 各チームは自分のドメインオブジェクトをどう操作するかだけを知らせればよい
- Active Directoryチームは数週間を投資していくつかのcmdletを作り、ユーザーグループの反応が強かったため、さらに多くの作業を進めることになった
Longhornリセット後にWindowsへ戻る
- Longhornでは.NET導入が過度に推進され、問題が大きくなった
- 例として、Notepadの
Save Asダイアログが.NET/WCFベースの共通ダイアログのために1分30秒後に表示され、ワーキングセットが15KBから15MBに増える状況があった
- ナイトリービルドが約7カ月間動作しなかったという回想も出ている
- Windows組織はリセットを行い、.NETコードをWindowsから取り除き、PowerShellもWindowsの外へ押し出された
- その後PowerShellは、コマンドラインインターフェイスであり.NETベースでもあるという理由で、繰り返し中止の圧力を受けた
- Bill Gatesは価値を理解していたが、日常的な防衛には役立たなかった
- Windows Server責任者は重要な局面で支援した
- Exchangeチームは、PowerShellに依存する「数十億ドル規模の事業」を掲げて中止を防ぐ役割を果たした
- Windowsに.NETを入れるためのWinArch要件は非常に厳しかったが、PowerShellチームはすべての条件を満たすよう準備した
- Windows責任者が要求の取り下げを求めると、プログラムマネージャーは正式な拒否を要求し、その結果としてレビュー手続きが開かれた
- Windows Server組織がこの決定権を持っており、PowerShellが要件を満たしていると判断して、Windowsに再び入ることになった
PowerShell 1〜4と実際の影響
- PowerShell 1はWindows Vistaの一部としてリリースされた
- Snoverはリリース後、別の仕事をするよう助言され、キャリア上の不利益も警告されたが、PowerShell 2、3、4まで同じビジョンに集中した
- バージョン1は一部の目標に到達し、バージョン2と3で機能を埋め、バージョン4でビジョンがほぼ完成したと回想している
- PowerShellはWindows管理者たちがスクリプトを書き、複雑な作業を自動化するようにした
- ユーザーグループ、オンラインでの質疑応答、スクリプト共有、カンファレンス発表が生まれた
- 一部の管理者はPowerShell経験を通じてプロの講演者になった
- Snoverは約5年後にDistinguished Engineerとなり、その後Technical Fellowになった
- Office責任者は、PowerShellがなければOfficeのクラウド移行は難しく、Officeのクラウド移行がAzureのクラウド移行にも影響を与えたと語っている
- 以前はサーバープロビジョニングがクリック作業だったため、反復と修正が難しかった
- スクリプトのおかげでスケールでき、問題が起きればスクリプトを変更して対応できた
1件のコメント
Hacker News のコメント
司会者の立場から見ると、PowerShell は Microsoft 社内で猛烈な反対に遭い、作った本人である Jeffrey Snover はそれを押し通そうとして降格までされた
Jeffrey はもともと、Microsoft がデータセンターで競争する方法を学ぶのを助けるために採用されたが、当時の文化がパーソナルコンピューター中心の世界観にあまりにも縛られていたため、あらゆる段階で抵抗を受けた
もう一つ興味深いのは、Windows がファイルベースではなかったために PowerShell が生まれたという点。Jeffrey の目標はサーバー管理だったが、Windows では設定ファイルを編集するだけでは管理できず、複数の API を呼び出して構造化データをやり取りする必要があったため、リッチなオブジェクトモデルが事実上唯一の方法だった
文字起こしは、専門の文字起こし、Descript、GPT-4 による句読点整理、自分での確認という順で作ったが、期待したほど品質は高くないかもしれない
PowerShell が好きな理由は、シンプルな動的言語で、使いやすいコマンドをつなげられるからなので、簡単なユーザーインターフェイスやチャートを作る新しい cmdlet 群があるとよい
例えば
Create-Chart -Type "Bar" -XAxis $Cities -YAxis $GDP -OutputFile "C:/Documents/ProjectAnalysis/CitiesBarGraph.png"のような機能は、Microsoft が製品に組み込みやすそうだし、よく理解できないボイラープレートコード 1 ページ分をなくしてくれるはず基本的なプログラミングはできるが、Java や C# のようなツールが職務上合わないユーザーは何百万人もいるはず。Python はたいていよく合うが、Microsoft にはサーバー管理者や IT 担当者だけでなく、一般の業務ユーザーも使えるものをもっと作ってほしい
PowerShell がファイル解析のような作業で遅くならないようさらに投資し、上で述べた機能や統計・科学向け cmdlet まで追加すれば、一般的な ビジネスアナリスト が業務改善用ソフトウェアや開発チームに渡すプロトタイプをすばやく作れる、かなり強力なツールになり得る
Microsoft は選択肢を、C# を使う正式なソフトウェア開発者、PowerShell を使う IT 業務、ビジネスユーザー向けの Excel の 3 つと見ているようだ。Excel は多くの面で素晴らしいがかなり制限があり、VBA+Excel は触ってきたエコシステムの中でも最も制約の強い部類に入る。Python や R のようなサードパーティ言語が 4 つ目の選択肢ではあるが、Microsoft にはこの領域にもっと時間を割いてほしい
PowerShell の変な欠点も含めて好きだったが、今は離れてしまった
読んでいる間、機械生成だろうとは思ったが、具体的にどこがそうなのかは説明しにくく、もっと読みやすくするには少し編集が必要そうだ
それでも、文字起こしがまったくないよりはずっと良い
Bashを長く使ってきた開発者として、PowerShellが登場したときは本当に期待していた
ついにWindowsでも開発用として優れたシェルを使えるようになると思ったが、その後もPowerShellをきちんと身につけることはできず、Windowsでも慣れたBashを使い続けている
両方のシェルに熟達した開発者たちはどう比較しているのか気になる。PowerShellが、より効率的でモダンなシェルという約束を実際に果たしたのか、それとも標準で入っていてCMDよりましだから使われているのかを知りたい
おおむね50行を超えたらコードスメルだと見ており、誰かを説得する必要があるときに備えてこのページを保存している: http://mywiki.wooledge.org/BashPitfalls
最近PowerShellを使ってみると、コマンドがテキストではなくオブジェクトを返すため、テキストを無理に扱う必要がない点が、スクリプト言語としてもコマンドライン言語としてもずっと楽だった
引数パースを処理する公式の方法があるのも素晴らしい。すべてが統一されていて、コマンドラインウィンドウで事実上すべてのオプションを自動補完できるが、これはBashでは夢にも見られない水準で、生産性が非常に高くなる
ただし型変換が、Bashにはなかった新しいバグを生むこともある。今はPWSHのほうを好んでいるが、どちらもある程度は嫌いで、次の自然な進化を待っているところだ
オブジェクト指向はパイプラインを作るときにかなり有用だ
たとえばフォルダ内でファイルサイズごとに再帰的にグループ化して重複候補を探すなら、
Get-ChildItem -File -Recurse | Group-Object -Property Length | Where-Object { $_.Count -gt 1 } | Sort-Object -Property Countのように書ける難解な
fileのおまじないを覚える必要も、テキスト出力をパースする必要もない。プロパティを持つ実際のオブジェクトを受け取り、タブ補完でその構造を確認できるJSONをパースする必要があれば、
jqなしでGet-Content -Raw whatever.json | ConvertFrom-Jsonですぐ処理できる。XMLをCSVに変えるなら、ConvertFrom-XmlまたはSelect-Xmlの後に必要な処理を行い、ConvertTo-Csvを使えばよいGet-ChildItemが長すぎるならgci、dir、lsを使えばよく、Where-Objectが長ければwhereや?を使えばよい。基本的に大文字小文字も区別しない数年前、PowerShellで複雑かつ無人で動く堅牢なデータ転送システムを書かなければならなかったが、その体験がとても良かったので、macOSとLinuxのシェルをすべてPWSHに切り替えた
最も良かったのは、オブジェクトをパイプラインで渡す力だった。最初のフィルタでオブジェクトの一部のプロパティを抽出・操作しても、パイプライン後段のフィルタで他のプロパティや、最初のフィルタが作ったオブジェクトのプロパティに引き続きアクセスできた
コマンド、エラー処理、オブジェクトのプロパティの一貫性も非常に良かった
その後、仕事の性質が変わると昔の筋肉記憶がよみがえり、すべてのシェルをBashに戻した。その領域で多く作業し考えているときはPWSHがシェルとして自然だったが、そこを離れると、PWSHで考えることのほうがBashへ戻ることより難しかった
ときどき懐かしくなる。シェルの領域でこれほど近いものはなく、少なくとも切り替える労力を正当化できるほど近い代替はないと思う
第一に、.NET言語になろうとした点だ。1つのランタイムと複数の言語という.NETの約束が、Java側ではそうした約束がなくても花開いたのに、なぜ.NETではしぼんでしまったのか分からないが、.NETコードを書くならC#を使うほうがよいと思う
第二に、シェルの基本をきちんと押さえられていなかった。詳細はもう過去に埋もれて覚えていないが、リダイレクト処理が壊れていて、Bashでは些細なことがPowerShellではほとんど不可能なレベルだった。開発者たちが新しく強力なものを作ることに浮かれて、Bashなどが得意としていたことを無視したように感じた
第三に、すべての名前にVerb-Object形式を求めるようなこだわりがある。主観的な話で擁護者もいるだろうが、スクリプトを見苦しくし、タイピングもしづらく、発見しやすさや覚えやすさを実質的に改善しているとも思えない
タブの代わりに右矢印を使うことになるのも混乱するし、慣れたコマンドがない点や命名に強い規則がある点も不便だ
それでもよく知れば、PowerShellはBashより能力が高そうに見える。より良い型システムがあり、引数を扱いやすい一方で、Bashの値は形のない文字列に近いからだ
https://github.com/bionicles/tree_plus/blob/main/tests/more_...はWindowsマシンでテスト環境を構成するときに使っている少し古いバージョンで、何が可能かをある程度示している
PowerShellを自分で使っていてひどいとは思わなかったが、なぜ長さ1の配列が配列から剥がされて内部の型に変わるのかは理解できなかった
そのせいで、配列にいくつ入ってくる可能性があるのかを毎回気にしなければならず、一般的に処理する代わりに修正のたびに確認する必要があって、とんでもないバグを生んだ。なぜこうしたのか知っている人がいるのか気になる
WriteObjectという関数1つが、与えられた値をcmdletの出力として書き出し、1回呼ぶとそれが出力になる。複数回呼ぶと、シェルはそれらの値をすべて集めた配列を出力にするしかないしたがって、あるcmdletの実行では
WriteObjectを1回だけ呼び、別の実行では2回呼ぶ場合、最初の場合にシェルはその単一の出力も配列で包むべきだったという知識を持てない。かといって常にcmdletの出力を配列で包むと、Get-Dateのように意味的には結果が1つだけのcmdletには邪魔になる何らかの理由で、cmdlet自身が実際の
WriteObject呼び出し回数に関係なく、意味的に単一出力なのか複数出力なのかを表現できるようにAPIを複雑にしたくなかったようだ。このようなAPIは、パラメータによって出力が大きく変わり得るためcmdletの静的プロパティにはできず、空配列にも対応しなければならないので、(Object, bool iMightWriteMoreValues)のようなWriteObjectオーバーロードも厄介である。おそらく別のIWillWriteMultipleValues()関数が必要だったのだろうここにも説明がある: https://news.ycombinator.com/item?id=40874873
$Ary = @(, "value")配列を作るとき、特に大きな配列では
+=より性能がよいので、配列にforループを代入する機能もかなり良い。配列を埋める方法として直感的ではなかったが、確かに便利である$Ary = foreach ($Obj in $Objs) { @{ foo = $Obj.foo } }ソフトウェア開発者は、自分のソフトウェアを賢くしすぎたいという誘惑に常に警戒すべきである
欠けている残り半分は、受け取り側が配列を期待しているときに単一の値を長さ1の配列へ自動変換する機能だったのだろう
Luaのようなものがすでにあるのに、そのまま使うか少しだけ修正して、単純で小さく優雅で一貫した言語を得る代わりに、人々は車輪を再発明し、それでも丸く作れないというシーシュポスの悲劇のようだ
Windowsのサブシステムとやり取りする必要があり、そのために特定のPowerShellコマンドが必要な場合でなければ、「なぜPythonを使っていないのだろう？」と思ってしまう
Bashでやることの90%には冗長すぎて遅く、別の人生ならPerlでやっていたようなことにも同じである
MicrosoftがなぜPythonやNodeのようなものの上に作らなかったのか、よく不思議に思う。PowerShellが最初にいつ出たのか覚えていないので、当時何が理想的だったのかは確かではない
また、PowerShellが得意とするコンソール作業向けに設計されていない。ファイル内容を受け取って別のコマンドに渡せばよいだけのことを、ファイルハンドル管理のような形で自分でやらなければならないからだ
PowerShellが良い理由は、補完のある優れたREPL、奇妙な空白の挙動がないこと、readline[0]、必要なら.NETでできることは何でもできるスイスアーミーナイフだからである
さらにオブジェクト指向なので、古いユーティリティのテキストベースの出力を別の古いユーティリティで解析する方法を探る代わりに、本当にやるべき作業に集中できる
0: https://learn.microsoft.com/en-us/powershell/module/psreadli...
Bruce Payetteの『Powershell in Action』初版には、PowerShellが
@記号、既定変数$_、関数呼び出し演算子&を使うためPerlのように見える、という余談がある。実際に一時期Perlをルート言語として使っており、これらの要素はその時期に由来するという。後に構文はC#により合うよう変更されたが、これらの要素はうまく機能していたため維持され、Perlの用語で言えば言語の「whipupitude quotient」に大きく寄与した、と説明しているまた、PowerShellの中核言語はKorn shellのPOSIX 1003.2文法をベースとしており、当初はハッシュテーブルのような高度な概念にはPerlのイディオムを取り入れていたが、プロジェクトが進むにつれてPowerShellの構文をC#に合わせる方がより適切だということが明らかになったという
何か別のものをベースにしなかったのは、Microsoftが.NETをコントロールしていたからである可能性が高い
遅い理由が.NETのせいだとは思わず、設計上の問題か性能への投資不足のせいではないかと思う
ただし、どのバージョンのPSを使うかによる。記憶では、最新バージョンはかなり速い
職場では、20年以上前からある SQL Server のストアドプロシージャのコードベースを扱うという恩恵にあずかった
約30万行の、モンキーテストを経たビジネス中核コードだったが、ソース管理はなく、性能チューニングもまともに行われたことがなく、SSMS で SQL を編集・実行して環境へデプロイしており、当然ながら自動テストもなかった
会社は Windows 中心で、開発は Mac で行い、GitHub Actions では Linux を使っている
PowerShell Core、sqlcmd、Windows SQL Server インスタンスを実行するための docker、既存のレガシーサーバーからスキーマとコードを抽出するための RedGate SQL Compare、単体テスト用の tSQLt、コード準拠用の TSqlLint、スタイル準拠用の SQLFluff、デプロイ用の Flyway といったツールを選んだ
Windows がプラットフォームの一つでなければならない場合、PowerShell Core が最も相互運用性の高いクロスプラットフォームのスクリプティングシェルだとすぐに分かった
コーディングが楽しかったわけではない。正規表現エンジンは .NET 由来だが致命的なバックトラッキング問題があり、配列の挙動もおかしかった。実行ファイルを望む方法で起動し、出力ストリームを捕まえるのも一貫せず、プロセスを実行して出力を一時ファイルへリダイレクトし、子プロセスが終了したらそのファイルを読む必要がしばしばあった。子プロセスの標準出力を文字列変数にパイプすることも、必要以上に面倒だった
それでも PowerShell Core は実行が速い。Microsoft が一つ得意なことがあるとすれば、マイクロ最適化だ。ASCII アートのリスト選択器や簡単な入力プロンプト生成器のような、ユーザーと対話するツールも良い。ロックされたファイルがあるフォルダを避ければ、Windows ファイルシステムの奇妙な特性もほとんど隠してくれる
根気よく検索すれば、やりたいことはたいてい実現できる。おすすめできる
キャリアが Windows 管理に近づくたびに、その経験が本当に嫌だったという他の感想には同意する
しかし Windows の他のあらゆるものが極端に不格好なのとは違って、PowerShell 自体は実際かなり優れていて、常に慎重に設計されている感じがあった
Linux は素晴らしいし、今後も仕事用の日常環境として使うつもりだが、Bash を使うのは本当にひどい体験だ。それでもどこにでも常にあるので、みんながまず最初に手を出すし、おそらく2100年になっても、あらゆる欠点を抱えた Bash スクリプトを扱い続けているだろう
PowerShell は本当に Microsoft の独占的な自信から生まれた製品のように見える
他の言語から移ってこられる構文上の足がかりがほとんどない言語を作るのは大胆なことだ。コマンド、パラメータ、フラグを推測したり見当をつけたりできなかった。Microsoft の野心を考えても、管理者とプログラマーの大群が少なくとも数十年は PowerShell と Bash スクリプトを併せて学び、保守しなければならないことは分かっていたはずだ
極端に冗長な構文は委員会での発表では良く見えるかもしれないが、実際に頻繁に扱うと、人間の脳についてよく研究されている限界と衝突する。情報量や遅延が一定水準を超えると没入の流れが途切れ、集中と明示的な暗記、再確認が必要になる。練習しても、思考を現実に変えるよくあるシェルの呪文を素早く実行するのは難しく、補完が出るのを待って、複数部分からなるコマンドの次の単語を受け入れるか決めるだけでも構文と格闘しなければならない
スタートメニューで
pow..を検索すると、PowerShell、PowerShell ISE、それぞれの通常版と x86 版という素晴らしい4つの選択肢が出てくる。どちらにしても読み込みが入り、流れが途切れる。ISE は小さなスプラッシュ画面を出して別の位置へジャンプする。さらに別のダイアログは、前回のセッションを名前のないスクリプトファイルを保存せずに閉じたと知らせてくるが、結局は期待どおり再び開いてくれる。ならなぜ叱るのか分からないテキストを入力したりコピーしたりしてどんなマルウェアでも実行できるのに、ファイルとして保存してから
.psスクリプトとして実行しようとすると、ばかげた実行ポリシー手順が始まる。初期の Internet Explorer と Windows の悪いセキュリティ評判から来たトラウマだったのかもしれないそれでも好きになろうとしたが、ある日スクリプトが角括弧を含むファイル名に出会い、PowerShell はその
[1]、[2]を暗黙のうちにイテレータのようなものとして解釈した: https://stackoverflow.com/questions/21008180/copy-file-with-...スクリプト言語の中核的な仕事の一つはファイルを扱うことだが、ファイル名はスクリプト作者が制御できるものではなく、Windows で有効なファイル名空間は把握しているべきだ。この件で、その言語に対して長く残る信頼の問題が生じた
Azure チームは Microsoft 内で十分な力を持っていたのか、
az find vm、az account showのような正気で読みやすい構文を別に作ったもう一方で求めていたのは一貫性だった。*NIX の知識は、実質的には力ずくで暗記して得るものだ。
-vはたいてい verbose で、-hはたいてい help ではあるが、実際には何も信じて依存することはできない今振り返ると、Microsoft が Windows や Active Directory、Exchange のような重要なエンタープライズアプリケーションのすべての設定を、簡単に組み合わせられ、プログラム可能な形で構成する価値をなぜ見いだせなかったのか不思議だ
Remote Desktop で接続してマウスでクリックして回ることを代替案として提示したという考えは、とんでもない。そうした作業を自動化するのは、少なくとも AutoHotkey と Window Spy を使った経験からすると、ひどく難しく面倒だ
Remote Desktop で接続してマウスでクリックする方式は、多くの請求時間を生み出す
そうしたことがひどく難しく面倒である点こそが、代替 OS が存在する主な理由である可能性が高いというのは皮肉だ
以前、フェアに言えば10年ほど前だが、ある設定を自動化する最善の方法は Selenium だという、技術サポート担当者からの真面目な提案を受けたことがある
1982年からコンピューターを使ってきたが、Windowsユーザーだったことは本当に一度もない
1990年代初頭にWintelが台頭したころはLinuxと386BSDの成長を追い、1990年代後半にWin95とNTがビジネスデスクトップを支配したころは、SPARCStation、Linux、販売終了したNeXTハードウェアに逃げ込んでいた。世紀が変わってからは、新たにPOSIX準拠となったMac OSを受け入れた
ほぼ半世紀にわたり、Microsoft製品を避けることがコンピューティング方針の核であり、目立つ例外はApplesoft BASICくらいだった
それでもPowerShellは良い
ただ、最初の段落が作った期待を2つ目の段落が意図的に外しているので、なぜPowerShellが「良い」と考えるのか説明してほしい
適切なプログラミング言語であるC/C++のようなもので直接コマンドラインツールを書かなければならない場合、従来のシェル向けに作る場合とPowerShell向けに作る場合の生産性の差は過小評価されている
一般に、有用なCLIツールを数千行以下の雑多なコードなしに作れたことがない。たいていはパイプライン入力、オプションのパラメーター、値を持つパラメーター、デフォルト値と上書き、dry runモード、さまざまな出力形式の要件などを処理する必要があり、90%は余計な部分で、実際の動作は10%だけになる
PowerShellでは、C#モジュールは基本的に20行程度のオーバーヘッドだけで、残りはすべて実際の動作になる。生産性は驚くほど高い
パラメーター検証、パラメーター名のタブ補完、パイプライン入出力、書式設定、強い型付け、グロビングなどがすべて無料で手に入る
保守や管理作業では、CLIツールよりもコンパイル言語やインタープリター言語へますます移行している