1(ORIGINAL) Este no es un documento técnico de Windows PowerShell ni es una descripción precisa de cómo funciona V1.0. Esta es una versión del original Manifiesto de Monad que articuló la visión a largo plazo y comenzó el esfuerzo de desarrollo que se convirtió en PowerShell. Muchos de los elementos descritos en este documento han sido liberados y otros han proporcionado una buena hoja de ruta para el futuro. El documento se ha actualizado para su publicación. La información confidencial ha sido eliminada y los ejemplos se actualizan para reflejar la sintaxis actual.↩

2(ORIGINAL) Monad es el término de Leibniz’s utilizado para describir una unidad fundamental a la que luego se agregan componentes para implementar un propósito. En esta filosofía, todo es una composición de Monads. Esto captura lo que queremos lograr con una gestión compuesta. Más información sobre Monad se puede encontrar en: http://www.wise.virginia.edu/philosophy/phil206/Leibniz.html↩

3La versión 1 de PowerShell se liberó en 2006 y proporcionó la implementación de cmdlets. Los cmdlets de hoy se escriben en lenguajes .NET y consisten en una sola clase por cada cmdlet. PowerShell proporciona una clase base que hace mucho del trabajo pesado. Los desarrolladores definen las propiedades de la clase que se convierten en parámetros y reemplazan métodos específicos para participar en el ciclo de vida de la canalización en el pipeline. Los cmdlets, junto con el entorno general, fueron el primero de los cuatro puntos de visión principales que se proponen en el Manifiesto.↩

4Remoting fue introducido en PowerShell versión 2, que se liberó con Windows Vista y Windows Server 2008. Remoting es el segundo de los cuatro puntos de visión principales propuestos en el Manifiesto.↩

5Aunque nunca se expuso como una MMC per se, el motor de PowerShell se implementó como una clase .NET. Cualquier aplicación .NET puede instanciar el motor, ejecutar comandos y traducir la salida a una pantalla GUI. Exchange Server 2007 fue el primer producto que lo hizo y sigue siendo uno de los mejores ejemplos del “enfoque completo de PowerShell” para la administración.↩

6De hecho, las API son el diferenciador principal entre los sistemas Windows y Linux/UNIX. En Linux/UNIX, todo se parece esencialmente a una carpeta o un archivo, y casi todos los bits de configuración se encuentran en un archivo de texto de estructura libre. La automatización de la administración en ese entorno es fácil, ya que sólo tiene una API: archivos de texto. Windows es más difícil porque para hacer algo, tiene que aprender alguna API - y todas las API son diferentes. Saber cómo agregar un usuario a Active Directory no le ayuda a crear un sitio en SharePoint: todas son API diferentes.↩

7En otras palabras, no se alcanza el objetivo, porque VBScript es básicamente una forma simplificada de tratar con las API que estaban destinadas a los desarrolladores. VBScript también asume que los equipos de producto han creado API dedicadas, compatibles con VBScript, lo que la mayoría no hizo. Conseguir algo con VBScript era a menudo complicado, y siempre a punta de prueba-error.↩

8(ORIGINAL) El scripting administrativo es a menudo la progresión de scripts ad hoc a operaciones automatizadas. Los administradores advierten que escriben los mismos comandos una y otra vez así que mejor construyen una secuencia de comandos. Ellos se percatan que sus secuencias de comandos siempre contienen muchas de las mismas cosas por lo que producen subrutinas parametrizadas y avanzan desde allí.↩

9Tradicional en el mundo Linux/Unix, pero no en Windows. Este es, de hecho, el cambio que Snover proponía: hacer que la administración administrativa funcione más como en Unix, ya que Unix es un modelo probado de éxito desde hace décadas. Probablemente ayudo que Snover proviniera de Digital Computer, una compañía con bastante familiaridad en variantes de Unix y sistemas operativos similares.↩

10Estos ejemplos enfatizan la influencia que el mainframe y UNIX tenían en las opciones de diseño de Snover.↩

11Las personas que ven PowerShell como “linux-ification” de Windows deben tener en cuenta que Snover no estaba enamorado del modelo de línea de comandos Unix. Él sentía que era inconsistente y que le faltaba una mejor semántica. De muchas maneras, PowerShell fue el primer “segundo vencedor” en el modelo de línea de comandos de Unix, tomando sus puntos fuertes, pero reconsiderando lo que se había convertido en debilidades algo obvias.↩

12El resultado práctico de esto es que las herramientas - cmdlets, en el mundo de PowerShell - deben hacer una cosa, y sólo una cosa. Obtener objetos, procesar objetos o formatear objetos desde texto. Elija sólo una cosa y haga sólo eso. Si hace más de una cosa, comienza a crear una herramienta monolítica que es menos fácil de reutilizar. Este concepto de una sola cosa se ha convertido en el fundamento de las mejores prácticas en la comunidad de PowerShell, especialmente en torno a la creación de herramientas.↩

13Hay un punto enorme aquí que a menudo se pierde. Cuando se escribe una herramienta que produce texto, las herramientas descendentes tienen que saber cómo procesar ese texto en el formato exacto que se produjo. Sus datos no están estructurados. Si cambia la salida de su herramienta, todo lo que se utiliza para trabajar con ella tendrá que cambiar. La orientación de objetos, es decir, presentar los datos en una estructura estandarizada que podría ser consumida por cualquier cosa que entienda “objetos”, fue una de las mayores diferencias entre PowerShell y lo que había antes. Gran parte del tiempo de un administrador de Linux se gasta en el ciclo grep/sed/awk, ya que tienen que analizar el texto para que la próxima herramienta tenga datos con los que trabajar. PowerShell casi que elimina ese trabajo por completo.↩

14De manera realista, COM podría haber proporcionado las mismas capacidades ya que estaba orientada a objetos. Sin embargo, en el momento en que se escribió el manifiesto, COM fue “acabado” y Microsoft se había trasladado a .NET↩

15Lo que significa que la mayoría de los desarrolladores no implementarán interfaces que los administradores puedan usar para administrar la aplicación. En el mejor de los casos, un desarrollador “perezoso” podría simplemente poner toda su información de configuración en un archivo de texto y llamarla “manejable”. Irónicamente, eso es esencialmente como Unix se construyó desde cero, y es manejable, porque no es tan fácil como modificar un archivo de texto, especialmente si está estructurado (como en JSON o XML).↩

16ORIGINAL: VMS DCL y AS400’s CL son las excepciones a esto. Proporcionan un analizador de comandos común para que los comandos que se usan tengan un alto grado de consistencia sintáctica.↩

17Es por eso que los desarrolladores odian hacerlos y los administradores odian usarlos.↩

18ORIGINAL: Existe una maravillosa sinergia entre el deseo del programador de minimizar la cantidad de código que escribe para la administración y los clientes que desean tener una experiencia de administración consistente.↩

19Este es el modelo adoptado por PowerShell. Los cmdlets son instancias de una clase, que heredan de una única base. Esa clase proporciona una tonelada de funcionalidad común, de modo que el código real en un cmdlet está alrededor del 99% centrado en lo que sea que el cmdlet esté haciendo. El desarrollador del cmdlet no se centra en analizar los argumentos de la línea de comandos, validar los elementos obligatorios, etc.↩

20El análisis basado en la oración es cuando analiza el texto y luego ora para que lo entienda correctamente. p.ej. Cortar las primeras 3 (¿o eran 4?) Líneas, recortar la columna 30-40 (suponiendo que esos espacios no son Tabs), convertir a un entero (hmm. - ¿Alguien utiliza 64 bits? … bueno espero que sea de 32 bits).↩

21Un “objeto” en este sentido es poco más que un conjunto de datos estructurados, a diferencia de una tabla de base de datos o una hoja de cálculo. Cada objeto representa algún componente de gestión, y sus propiedades representan bits de información sobre ese objeto. Los comandos no tienen que analizar estos objetos para encontrar datos, ya que .NET entiende la estructura del objeto y puede simplemente recuperar los bits de información haciendo referencia a los nombres de propiedades.↩

22Una de las primeras referencias directas a lo que se convirtió en PowerShell Remoting, que de hecho es un servicio web basado en WS-MAN (Web Services for Management).↩

23PowerShell nunca tuvo clases bases específicas para estos escenarios, pero este fue el origen de la lista estandarizada de verbos de PowerShell que se utilizaron en los nombres de cmdlet. Este concepto también impulsó la creación de las abstracciones PSProvider y PSDrive, en el que cualquier almacén de datos podría ser expuesto como una “unidad de disco”, lo que permite un conjunto estandarizado de comandos para manipular cualquier almacén de datos expuestos.↩

24Brevemente, durante el desarrollo, los “cmdlets de script” de PowerShell (ahora, “funciones avanzadas”) tenían una sintaxis similar a ésta. En C #, el código fuente del cmdlet todavía se parece mucho a esto.↩

25ORIGINAL: “Get-EventLog Application” es proporcionado por el código de ejemplo anterior y el resto proviene de los comandos de base de Monad. “ Group source” cuenta el número de objetos que tienen el mismo valor para una propiedad en particular (es decir, cuántas veces apareció una fuente en particular). “Select -First 5” trunca el conjunto de objetos para que sólo tengan los primeros 5. “Format-Table” formatea los objetos y sus propiedades una tabla.↩

26Tenga en cuenta que incluso en este documento, Snover no era coherente acerca de “CmdLet” versus “Cmdlet”. Hoy en día, “Cmdlet” es el estándar. Su idea original era enfatizar que un “Cmdlet” no era un “comando completo” con todo el análisis sintáctico, pero no era un comando tradicional implementado. En su lugar, era parte de un comando, con gran parte de la sobrecarga proporcionada por las clases base del motor de automatización.↩

27Significado, un desarrollador .NET puede indicar al runtime .NET que realice ciertas tareas estandarizadas. Esto se ve mucho en PowerShell: por ejemplo, una función puede declarar un parámetro como obligatorio y el shell aplicará ese atributo en lugar de que el desarrollador de funciones tenga que escribir la lógica para hacerlo.↩

28ORIGINAL: MSH podrá invocar de forma transparente los comandos heredados y los shells heredados podrán invocar sin problemas MSH CmdLets. (MSH proporcionará un mecanismo para exportar CmdLets para el acceso desde los shells heredados) [De hecho, PowerShell nunca implementó una forma fácil de invocar cmdlets para comandos heredados].↩