ジェフリー・スノヴァーとPowerShell開発の物語

 (corecursive.com)
1 ポイント 投稿者 GN⁺ 2024-07-05 | 1件のコメント | WhatsAppで共有

Jeffrey SnoverとPowerShellの誕生

  • 巨大な企業組織を切り開く

    • Jeffrey Snoverは、MicrosoftのPowerShellを生み出したアーキテクト。
    • PowerShellはWindowsシステム管理を革新的に変えたツール。
    • 当初は懐疑的な反応を受けたが、Snoverの粘り強い努力によって成功を収めた。

  • 問題

    • Microsoftはサーバー市場を理解できていなかった。
    • パーソナルコンピューターに慣れた経営陣は、企業環境についての経験が不足していた。
    • Snoverはこの問題を解決するために採用された。

  • Jeffreyの説得

    • SnoverはMicrosoftのサーバーチームに加わり、WindowsをUNIXと競争できるものにするために尽力した。
    • 目標は、同等の機能をより低いコストで提供することだった。

  • UNIXに勝つ

    • UNIXはファイル中心のオペレーティングシステムだったが、WindowsはAPI中心のオペレーティングシステムだった。
    • UNIXのツールはWindowsではうまく動作しなかった。
    • SnoverはWMI(Windows Management Instrumentation)を使って管理コマンドを開発することに決めた。

  • 文化的な挑戦

    • MicrosoftのチームはGUIを好み、Snoverのコマンドラインインターフェースというアイデアに懐疑的だった。
    • Snoverは、エンタープライズ環境ではGUIではなくコマンドラインインターフェースが必要だと主張した。

  • 企業シナリオ

    • Microsoftのチームは、それぞれの問題に対してユーザーインターフェースを提供する現代的な方法を好んでいた。
    • Snoverはツールボックス型のアプローチを主張した。

  • WindowsはUNIXではない

    • Windowsはファイル中心ではなく、API中心のオペレーティングシステムだった。
    • WMIを使って管理コマンドを開発することに決めた。

  • コーディングの期間

    • Snoverは、10週間コーディングしなければならないことを知った。
    • 10週間コードを書いたあと、数年にわたって動作させるというやり方だった。

  • .Netのくさび

    • Bill Gatesは.NETを強力に推進していた。
    • Snoverは、.NETを使えばより広いカバレッジを得られると判断した。

  • 再編成

    • Snoverの組織は再編によって混乱に陥った。
    • Snoverは自分の計画をそのまま推し進めることを決めた。

  • シェルチーム

    • 別のグループがシェルを開発していた。
    • Snoverは彼らにより良い方法を提案したが、彼らは理解しなかった。
    • 最終的にSnoverは独自のプロトタイプを開発した。

GN⁺の見解

  • PowerShellの重要性

    • PowerShellはWindowsシステム管理のパラダイムを変えた。
    • コマンドラインインターフェースによって大規模なサーバー管理を可能にした。

  • 技術的リーダーシップ

    • Snoverの粘り強い努力と明確なビジョンが成功の鍵だった。
    • 技術的リーダーシップとは、強い反対があっても重要な成果を達成すること。

  • 似た機能を持つ製品

    • LinuxのBashと似た機能を提供する。
    • PowerShellはWindows環境でBashのような役割を果たす。

  • 新しい技術を採用する際の考慮点

    • 新しい技術を採用する際には、既存システムとの互換性を考慮する必要がある。
    • PowerShellは既存のWindows APIとの互換性を維持しながら、新しい機能も提供した。

  • 長所と短所

    • 長所: 大規模サーバー管理の効率向上、自動化の可能性
    • 短所: 初期の学習曲線、既存のGUIユーザーからの抵抗

関連記事

1件のコメント

 
GN⁺ 2024-07-05
Hacker Newsの意見

  • PowerShellの生みの親である Jeffrey Snover は、Microsoft 社内で大きな反対に直面し、最終的に降格された

    • Jeffrey はもともと、Microsoft がデータセンター分野で競争できるよう支援するために採用された
    • Windows はファイルベースではないため、PowerShell が存在することになった
    • サーバー管理には、さまざまな API 呼び出しと構造化データが必要だった

  • PowerShell を書く際、配列の長さが 1 の場合に配列が取り除かれて中の型そのものになる理由が理解できなかった

    • これにより多くのバグが発生した

  • Bash 開発者として、PowerShell がリリースされたときは非常に期待したが、今でも Bash を使っている

    • 他の開発者たちの経験を知りたい
    • PowerShell が本当により効率的で現代的なシェルになったのか気になっている

  • 20 年物の SQL Server ストアドプロシージャのコードベースを管理する仕事を任されている

    • ソース管理されておらず、性能チューニングも適切に実施されていなかった
    • PowerShell Core は Windows との相互運用性が最も高かった
    • コードを書くのは不便だったが、実行は速く、ユーザーと対話するツールは良かった
    • 検索を頑張れば、やりたいことは実現できた

  • Windows サブシステムとやり取りするときを除いて、Python を使わない理由がわからない

    • PowerShell は冗長すぎて遅い
    • Microsoft がなぜ Python や Node をベースにしなかったのか気になっている

  • Microsoft が、Windows と重要なエンタープライズアプリケーションを構成するプログラム的な方法の価値を見ていなかったのは奇妙だ

    • リモートデスクトップ経由でマウスをクリックすることが代替案として提案されたのはばかげている

  • PowerShell は Microsoft の独善的な自信の産物だ

    • 他の言語との文法的なつながりがまったくなかった
    • 極端に冗長な文法はプレゼンテーションには良いかもしれないが、実際の使用には不便だった
    • ファイル名に角括弧が含まれている場合に問題が発生した

  • Windows 管理をするとき、PowerShell は使いやすかった

    • Linux は素晴らしいが、Bash を使うのはひどかった
    • Bash スクリプトは今後もなお多く使われそうだ

  • Windows ユーザーではなかったが、PowerShell は良かった

  • PowerShell は多くの点で優れていたが、より幅広いユーザー層を引きつけることはできなかった

    • PowerShell の cmdlet は自己説明的で、豊富な情報を提供していた
    • シミュレーションモードのような便利な機能があった
    • しかし Windows 以外では人気を得られず、Microsoft は Linux 開発者を引きつけるために PowerShell を軽視している