セマンティックギャップ
2つの世界があります。
1.私たちが代表する世界。
2.世界、それをどのように管理できるか。
2つの世界の違いは、 セマンティックブレークと呼ばれるものです。
私たちの業界は何十年もセマンティックギャップと格闘しています。 セマンティックブレークの優れた例は、ブログエントリ「TechProsaic：VMWare Perl Toolkit vs Powershell V1 ToolKit」で、1つのGet-VMコマンドレットで同じことを行う20行のPerlコードをリストしています。
誰かが「PowerShellは強力で、Perlはたわごと」という言葉でさらに読むのをやめるでしょう。この感嘆符は真実であり、真実ではありません。 真実は、PowerShellは強力ですが、Perlはたわごとではないということです。 （スーパースターのラリー・ウォールと彼のPerl、彼らのような私たちの業界に（プラス:-)のレベルの影響を与えた非常に少数の人々と技術へのあなたの帽子を脱ぎなさい）。 そして、彼のようなナイスガイが生まれたので、この世界は良い場所です！）。 2つの例の本当の違いは、セマンティックギャップです。 PowerShellの例には、考えていることと問題を解決するために必要なこととの間に非常に小さなギャップがあります。 Perlの例には非常に大きなギャップがあります。
最終的に、セマンティックギャップは、ツールを開発する人々によって「制御」されます。 VMWareは、PowerShellにPerlの例と同じ数の行を含むスクリプトを簡単に提供するか、Get-VMコマンドレットのセマンティクスを1つのコマンドで提供するPerlにライブラリを送信できます。
それでは、なぜツールのサプライヤはセマンティックギャップを閉じたのか、閉じなかったのか？ ああ-これはまさに質問です！
私はこれについて間違っているかもしれませんが、これはアブラハム・マスロウのニーズのヒエラルキーの一例に過ぎないと思います。 人々が以前何をすべきかを単純にするために使用していた技術は、作るのが非常に難しく、誰にでもそれを使用する機会を与えることは簡単です。 非常に便利なコードを書いた場合、最初の反応は、正しい診断エラーメッセージを含むセクションをこのコードに追加せず、バーに行って友達に自慢することです。 この典型的な例は、Unixオペレーティングシステムのテキストエディタ「ed」であり、エラーに対するメッセージ「？」が1つあります。 （それはばかげているように見えるかもしれませんが、ローカリゼーションの点で当時高度でした:)）。 すべてが機能していることを確認したら、適切なエラーメッセージなどを心配することができます。 後で高階関数と使いやすさを心配するかもしれません。 PowerShellは、巨人の肩の上に立つことができます。 これらの巨人の中には、Bash、C＃、Perl、Tcl、VMS / DCL、AS400 CLなどのコンセプトの先駆者です。 しかし、彼を本当に不思議に思ったのは、PowerShellが.NET、XML、WMI、ADSI、ADOなどのコードに依存していることです。 彼らのおかげで、Maslowのニーズの階層を登り、セマンティックギャップを埋めることに注力する機会を得ました。 明らかに、私たちの目標は、顧客が私たちの仕事に依存し、ツールの形で提供したものと、日々のタスクを解決するときに直面するビジネス上の問題とのセマンティックギャップを埋めることです。
私たち（およびサプライヤ）がビジネス上の問題を解決するために送るCDにとって、これは形而上学的に不可能だと思います。 各ビジネスには、独自の環境、哲学、政治、歴史、人格などがあります。 各ビジネスは、開発者が提供したものを取得し、（アクション、操作、またはシナリオを通じて）ニーズに合わせて（ 独自のセマンティックギャップを埋めるために）適用する必要があります。 私の成功のビジョンは、PowerShellが、開発者が提供するものを顧客が独自のニーズに合わせて適応させるための最も簡単で、最速で、安価で、最も信頼性の高いメカニズムを提供することです。 これらのニーズは時間とともに変化するため、PowerShellは、簡単で安価で安全で、理解しやすく、サポートしやすいソリューションを提供する必要があります。
しかし、セマンティックギャップを埋めるために開発者が提供するツールに戻ると、PowerShell自体は非常に限られたツールを提供します。 ただし、このプロセスでは大きな役割を果たします。 宣伝とデザインを行います。 PowerShellは、ユーザーが独自の高レベルの抽象化を簡単に記述できるカスタマーエクスペリエンスに適応するためのルールを明確に理解しています。 ツールキットプロバイダーに対するこのビジョンを強調し、動詞、パラメーター、名詞などの命名にどの単語を使用するかについての多くのガイダンスを提供します。 PowerShellコンストラクトは、ツールキット開発者に次のことを促します。
- 共通の命名スキーム（コマンドのセット、コマンドの名詞にプレフィックスを自動的に追加するためのルール）を使用する
- チーム（バインダー）に均一な解析プロセスを使用する
- 一般的なセマンティクスのサポート-WhatIf、-Confirm、-Verbose、-Debug
- ソート、フィルタリング、操作、フォーマット、インポート/エクスポートなどの一般的なユーティリティの使用
- ISAおよびHASA構成モデルの両方をサポート
- エラーおよびいくつかのパラメーターの検証の統一ルール。 完全なエラー報告システムを提供する
経済学は人々が何をするかしないかを決定すると強く信じているので、PowerShellは管理とサポートのコストを削減する拡張可能な高レベルのタスク指向の抽象になるようにゼロから設計されています。 言い換えれば、PowerShellと.NETは低レベルの問題とAbraham Maslow階層のささいな問題を処理し、ツールキット開発者がより高いレベルの問題に集中する時間を解放します。 もちろん、これは、PowerShellコマンドレットを作成するチームの経験によって確認されています。 フィードバック中に絶えず聞く：
1.わあ！...コマンドレットの作成は非常に簡単です。
2.ほとんどの時間は、顧客による使用の設計を通して考えることに費やされます。
実際、セマンティックブレークに関するこの短い記事で省略されたものの多くは、すべてをまとめるとPowerShellが好きになるでしょう。 たとえば、適応型システムを使用します（必要なデータについて考えることができ、どこでどのタイプを使用したいかを考えることはできません。さらに、ISAとHASAの両方の構成モデルをサポートし、 「うまくいく。」
伝えられることはたくさんありますが、日曜日の朝にはそれで十分だと思います。 コーヒーを飲みに行きます
ジェフリー・スノーバー[MSFT]
Windows管理パートナーアーキテクト