La historia de Jeffrey Snover desarrollando PowerShell

• Jeffrey Snover impulsó PowerShell para convertir a Windows en un sistema operativo de servidor administrable desde la línea de comandos, y tuvo que superar la cultura de Microsoft centrada en la GUI y la resistencia organizacional
• La migración inicial de herramientas UNIX no resolvió los problemas de administración de servidores porque Windows dependía de una estructura basada en APIs como Registry, Active Directory y WMI, más que en archivos
• Después de crear 70 comandos basados en WMI en WMIC, cambió de rumbo hacia un motor de generación de comandos basado en metadatos para reducir cuellos de botella en pruebas y costos
• Monad, el antecesor de PowerShell, arrancó aprovechando el impulso de .NET y Longhorn, pero quedó fuera de Windows tras el reinicio de Longhorn, y revivió gracias al apoyo del equipo de Exchange y la organización de Windows Server
• Snover se concentró en PowerShell 1~4 aun aceptando pérdida de rango y compensación, y esta herramienta se convirtió en la base de la automatización de administración de Windows y de la transición de Office a la nube

---

Windows centrado en la GUI y el problema de administrar datacenters

• PowerShell fue una herramienta de línea de comandos que cambió la administración de sistemas Windows, pero dentro de Microsoft no fue un proyecto aceptado de forma natural desde el principio
• En ese momento, la cultura de Microsoft estaba centrada en la GUI, y la interfaz de línea de comandos se consideraba algo anticuado, al punto de que circulaba la anécdota de que Bill Gates dijo que command.exe sería lo último que vería
• El punto de partida de Snover al unirse a Microsoft fue la convicción de que había que adaptar un sistema operativo basado en Windows NT al mercado de datacenters y empresas
  • El objetivo era competir con proveedores UNIX como Sun, IBM y HP
  • Intel y el ecosistema de hardware abierto tenían ventajas en costos, pero el software de administración de servidores no era lo suficientemente bueno

Un modelo de administradores que redujera la dependencia de integradores de sistemas

• La administración de servidores Windows requería configurar muchos servidores a base de clics, y como cada empresa necesitaba una configuración distinta, podía crecer la dependencia de integradores de sistemas
• Snover pensaba que, si el costo de los integradores subía demasiado, desaparecía la ventaja de precio de Windows
  • Como ejemplo, mencionó una estructura de costos de 10 en hardware, 2 en software y 40 en integradores de sistemas
  • También era un problema que la relación con el cliente y el valor terminaran trasladándose al integrador
• La alternativa era un modelo tipo UNIX de administrador programador
  • Un enfoque donde se combinan herramientas pequeñas para resolver problemas particulares y automatizarlos
  • En Windows también hacía falta una capa de administradores especializados que trabajaran con scripts y automatización, no solo “administradores que dan clic en Siguiente”

Por qué no encajaba migrar herramientas UNIX

• La solución inicial fue usar Windows Services for Unix para llevar a Windows un shell UNIX y herramientas como AWK/GREP/SED
• Pero la estructura de administración de Windows era distinta a la de UNIX
  • UNIX es un sistema operativo centrado en archivos, así que muchas tareas de administración pueden resolverse manipulando archivos y reiniciando procesos
  • Windows tenía una estructura donde la funcionalidad estaba detrás de APIs como Registry, Active Directory y WMI
  • AWK no encajaba directamente con Registry, SED no encajaba con Active Directory y GREP no encajaba con WMI
• WMI sí ofrecía potencial para tareas de administración, aunque no se usaba mucho, y el equipo de Snover quiso crear una herramienta de línea de comandos para trabajar con objetos WMI

WMIC y el motor basado en metadatos

• En la época de Windows XP había que crear una interfaz de línea de comandos basada en WMI con la restricción de tener solo 10 semanas de ventana de desarrollo
• Se implementaron 70 tareas con ayuda de ingenieros contratistas, pero eso estaba muy lejos del alcance necesario para administrar todo Windows Server
• Dentro de Microsoft, la estructura era tal que ninguna función podía lanzarse sin la aprobación del equipo de pruebas, y mientras más comandos hubiera, mayor sería también el cuello de botella de testing
• Snover impulsó un enfoque similar a la relación entre HTML y el navegador: tratar los comandos individuales no como código, sino como metadatos, y probar solo un motor común
  • El motor generaría los comandos, y la configuración de cada comando se expresaría como metadatos en un formato como XML
  • Recordó que durante las vacaciones de Navidad escribió los metadatos y creó 72 comandos
  • Según contó, los 70 comandos existentes habían costado unos 4 millones de dólares, mientras que el motor costó unos 60 mil dólares
• Cuando se agregaron al motor funciones como filtrado y formateo, todos los comandos mejoraron al mismo tiempo, y eso fue un anticipo importante de la arquitectura de PowerShell

Longhorn, .NET y Monad

• Bill Gates vio que los usuarios de Windows 98 no estaban migrando bien a XP, y quiso convertir a Longhorn en un nuevo punto de inflexión como Windows 95
  • Longhorn iba a incluir un modelo de desarrollo basado en .NET, WPF, WCF y un nuevo modelo de almacenamiento
• Snover concluyó que .NET podía ser una forma de ampliar el alcance de la administración de Windows
  • Escribir proveedores WMI no estaba generando suficiente impulso, pero Bill Gates estaba empujando con fuerza la adopción de .NET
  • Pensó que, si las utilidades de administración se montaban sobre .NET, se podría lograr una cobertura mucho más amplia
• Cuando otra organización intentó portar K-shell para crear un shell, Snover explicó un enfoque mejor, pero no logró convencerlos
• Entonces se encerró en un cuarto y creó un prototipo de unas 10 mil líneas, que ya contenía los principios centrales de la arquitectura de PowerShell
  • Después de la demostración, ese equipo aceptó la idea, y Snover pensó que quizá era la mejor idea de su carrera
  • Para participar en ese proyecto dejó un puesto de chief architect de productos y servicios de cientos a mil personas, aceptando en la práctica una degradación

El Monad Manifesto y cómo convencer a los equipos

• El nuevo equipo decidió llamar Monad al proyecto y, por falta de personal, externalizó parte del trabajo a India
• Snover escribió el Monad Manifesto para alinear la visión del proyecto y el camino hacia el éxito
  • Organizó el problema, los enfoques existentes, el nuevo enfoque, el valor y los diferenciadores
  • También dejó claro qué valor ofrecía a cada tipo de parte interesada, como administradores, proveedores y equipos de desarrollo
• Cada equipo dentro de Microsoft ya tenía demasiado trabajo, y no iban a ser despedidos por no crear una interfaz de línea de comandos, ni iban a ascender por crearla
• La propuesta de Monad era que cada equipo de producto solo escribiera el código para manipular sus propios objetos, y que PowerShell proporcionara el resto
  • Formateo, ordenamiento, filtrado, parser, ejecución remota, elevación de privilegios y demás serían provistos por PowerShell
  • Cada equipo solo tenía que indicar cómo manipular los objetos de su propio dominio
• El equipo de Active Directory invirtió unas semanas en crear algunos cmdlets, y cuando la reacción de los grupos de usuarios fue fuerte, avanzaron con más trabajo

Regresar a Windows después del reinicio de Longhorn

• En Longhorn, la adopción de .NET se impulsó de forma excesiva y eso amplificó los problemas
  • Por ejemplo, se describió una situación donde el cuadro de diálogo Save As de Notepad aparecía después de 1 minuto y 30 segundos por usar un cuadro común basado en .NET/WCF, y el working set pasaba de 15 KB a 15 MB
  • También se recordó que los builds nocturnos no funcionaron durante unos 7 meses
• La organización de Windows hizo un reinicio y sacó de Windows el código .NET, y PowerShell también quedó fuera de Windows
• Después, PowerShell enfrentó presión repetida para ser cancelado por ser una interfaz de línea de comandos y además estar basado en .NET
  • Bill Gates entendía el valor, pero eso no ayudaba en la defensa cotidiana
  • El responsable de Windows Server lo apoyó en momentos clave
  • El equipo de Exchange ayudó a evitar la cancelación argumentando que dependía de PowerShell para un “negocio de miles de millones de dólares”
• Los requisitos de WinArch para meter .NET dentro de Windows eran muy estrictos, pero el equipo de PowerShell se preparó para cumplirlos todos
• Cuando el responsable de Windows pidió retirar la solicitud, el program manager exigió una negativa formal, y eso abrió un proceso de revisión
  • La organización de Windows Server tenía esa autoridad de decisión, y determinó que PowerShell sí cumplía los requisitos, así que volvió a entrar en Windows

PowerShell 1~4 y su impacto real

• PowerShell 1 se lanzó como parte de Windows Vista
• Después del lanzamiento, a Snover le aconsejaron pasar a otra cosa y le advirtieron de posibles perjuicios de carrera, pero él siguió concentrado en la misma visión hasta PowerShell 2, 3 y 4
  • Recordó que la versión 1 alcanzó parte de los objetivos, que las versiones 2 y 3 completaron capacidades, y que en la versión 4 la visión estaba casi terminada
• PowerShell hizo que los administradores de Windows escribieran scripts y automatizaran tareas complejas
  • Surgieron grupos de usuarios, preguntas y respuestas en línea, intercambio de scripts y presentaciones en conferencias
  • Algunos administradores llegaron a convertirse en ponentes profesionales gracias a su experiencia con PowerShell
• Snover se convirtió en Distinguished Engineer unos 5 años después, y más tarde en Technical Fellow
• El responsable de Office dijo que, sin PowerShell, la transición de Office a la nube habría sido difícil, y que esa transición también influyó en la de Azure
  • Antes, el aprovisionamiento de servidores era una tarea de clics, difícil de repetir y corregir
  • Gracias a los scripts se pudo escalar, y cuando surgían problemas, se podía responder modificando el script

[GN⁺]

Opiniones de Hacker News

• Desde el punto de vista del presentador, PowerShell enfrentó una oposición extrema dentro de Microsoft, y su creador, Jeffrey Snover, incluso fue degradado por impulsarlo
  Jeffrey originalmente fue contratado para ayudar a Microsoft a aprender a competir en los centros de datos, pero la cultura de ese momento estaba demasiado atada a una visión del mundo centrada en la computadora personal, por lo que encontró resistencia en cada paso
  Otro punto interesante es que PowerShell surgió porque Windows no estaba basado en archivos. El objetivo de Jeffrey era la administración de servidores, pero en Windows no se podía administrar todo simplemente editando archivos de configuración; había que llamar a varias API e intercambiar datos estructurados, así que un modelo de objetos rico era prácticamente la única forma
  La transcripción se hizo en el orden de transcripción profesional, Descript, limpieza de puntuación con GPT-4 y revisión manual, así que puede que la calidad no sea tan alta como se esperaba

  • Si el equipo de MS-PWSH ve esto, me gustaría que agregaran funciones GUI básicas que no requieran escribir mucho código .NET directamente
    Me gusta PowerShell porque es un lenguaje dinámico sencillo y permite encadenar comandos fáciles de usar, así que estaría bien tener un nuevo conjunto de cmdlets para crear interfaces de usuario simples y gráficos
    Por ejemplo, una función como Create-Chart -Type "Bar" -XAxis $Cities -YAxis $GDP -OutputFile "C:/Documents/ProjectAnalysis/CitiesBarGraph.png" parece algo fácil de incorporar para Microsoft en el producto, y podría eliminar una página de código repetitivo que uno no entiende bien
    Debe haber millones de usuarios que saben programación básica, pero para quienes herramientas como Java o C# no encajan con su trabajo. Python suele encajar bien, pero me gustaría que Microsoft creara algo más que pudieran usar no solo administradores de servidores o personal de TI, sino también usuarios de negocio comunes
    Si Microsoft invirtiera más para que PowerShell no sea lento en tareas como el parseo de archivos, y además agregara las funciones mencionadas arriba o cmdlets para estadística y ciencia, podría convertirse en una herramienta bastante impresionante para que un analista de negocio común cree rápidamente software para mejorar su trabajo o prototipos que pueda pasar al equipo de desarrollo
    Microsoft parece ver las opciones como tres: desarrolladores de software formales que usan C#, tareas de TI con PowerShell y Excel para usuarios de negocio. Excel es excelente en muchos sentidos, pero bastante limitado, y VBA+Excel está entre los ecosistemas más limitados con los que he trabajado. Lenguajes de terceros como Python y R son una cuarta opción, pero me gustaría que Microsoft dedicara más tiempo a esta área
  • Al ver en GitHub a MVPs quejarse de que la inversión adicional prometida por Microsoft no se concretó, que los cambios no se incorporaron y que buenas funciones están abandonadas, parece que ya no es una prioridad de MSFT
    Me gustaba PowerShell, incluso con sus rarezas, pero ya lo dejé
  • Me pregunto por qué lo crearon desde cero en lugar de usar Python o alguna herramienta existente similar
  • Intenté leer la transcripción, pero no pude llegar al final; me pareció un poco difícil de leer
    Mientras la leía supuse que había sido generada por máquina, aunque me cuesta decir exactamente por qué, y parece que necesita algo de edición para que sea más legible
    Aun así, es mucho mejor que no tener transcripción en absoluto

• Como desarrollador que ha usado Bash durante mucho tiempo, cuando salió PowerShell tenía muchísimas expectativas.
  Pensé que por fin también en Windows podría usar una shell genial para desarrollo, pero después nunca llegué a dominar bien PowerShell y en Windows seguí usando el Bash al que ya estaba acostumbrado.
  Me da curiosidad cómo lo comparan los desarrolladores que dominan ambas shells. Quiero saber si PowerShell realmente cumplió la promesa de ser una shell más eficiente y moderna, o si la gente la usa porque viene instalada por defecto y es mejor que CMD.

  • He usado mucho Bash y también leí algunos libros, pero creo firmemente que no se deben escribir scripts de Bash complejos.
    Si pasan aproximadamente las 50 líneas, lo veo como un olor a código, y guardé esta página por si alguna vez tengo que convencer a alguien: http://mywiki.wooledge.org/BashPitfalls
    Al probar PowerShell recientemente, el hecho de que los comandos devuelvan objetos en lugar de texto, evitando tener que manipular texto a la fuerza, me resultó mucho más fácil tanto como lenguaje de scripting como de línea de comandos.
    También es excelente que haya una forma oficial de manejar el parsing de argumentos. Todo está unificado y en la ventana de línea de comandos se puede autocompletar prácticamente cualquier opción; es algo con lo que Bash ni podría soñar, así que aumenta muchísimo la productividad.
    Eso sí, la conversión de tipos también introduce bugs nuevos que en Bash no existían. Hoy prefiero más PWSH, pero ambos me desagradan en cierta medida, y sigo esperando la siguiente evolución natural.
  • PowerShell es más verboso que Bash y tiene rarezas como convertir automáticamente en escalar, en momentos inesperados, arreglos de 0 o 1 elementos, pero es más productivo y legible.
    La orientación a objetos es bastante útil al armar pipelines.
    Por ejemplo, si quieres agrupar recursivamente los archivos de una carpeta por tamaño para encontrar posibles duplicados, puedes escribir algo como Get-ChildItem -File -Recurse | Group-Object -Property Length | Where-Object { $_.Count -gt 1 } | Sort-Object -Property Count.
    No hace falta recordar conjuros crípticos de file ni parsear salida de texto. Recibes objetos reales con propiedades, y el autocompletado con tabulador puede mostrar esa estructura.
    Si necesitas parsear JSON, puedes hacerlo directamente con Get-Content -Raw whatever.json | ConvertFrom-Json, sin jq. Para convertir XML a CSV, puedes usar ConvertFrom-Xml o Select-Xml, hacer lo necesario después y luego usar ConvertTo-Csv.
    Si Get-ChildItem es demasiado largo, puedes usar gci, dir o ls; si Where-Object es largo, puedes usar where o ?. Por defecto, tampoco distingue entre mayúsculas y minúsculas.
  • Empecé mi carrera en una terminal X de una pizza box con SunOS, escribí miles de scripts y muchos de ellos tenían miles de líneas.
    Hace unos años tuve que escribir en PowerShell un sistema de transferencia de datos robusto, complejo y desatendido, y la experiencia fue tan buena que cambié todas mis shells de macOS y Linux a PWSH.
    Lo que más me gustó fue el poder de pasar objetos por el pipeline. En el primer filtro podía extraer y manipular algunas propiedades de un objeto y, aun así, en filtros posteriores del pipeline seguir accediendo a otras propiedades y a las propiedades del objeto creadas por el primer filtro.
    La consistencia de los comandos, el manejo de errores y las propiedades de los objetos también era muy buena.
    Después cambió la naturaleza de mi trabajo, reapareció la memoria muscular antigua y volví a poner todas mis shells en Bash. Cuando trabajaba y pensaba mucho en ese espacio, PWSH se sentía natural como shell, pero una vez que salí de ahí, pensar en PWSH resultó más difícil que volver a Bash.
    A veces lo extraño. En el terreno de las shells no hay nada que se le acerque tanto y, al menos, no veo una alternativa lo suficientemente cercana como para justificar el esfuerzo de cambiar.
  • No soy experto en ninguno de los dos, pero los he usado bastante, y siento que PowerShell terminó siendo horrible de usar por varias trampas.
    Primero, el intento de convertirse en un lenguaje .NET. No sé por qué la promesa de .NET de un único runtime y múltiples lenguajes se marchitó ahí, mientras que del lado de Java floreció incluso sin esa promesa, pero si voy a escribir código .NET, me parece mejor usar C#.
    Segundo, no resolvió bien los fundamentos de una shell. Ya enterré los detalles en el pasado y no los recuerdo, pero el manejo de redirecciones estaba roto, y cosas triviales en Bash eran casi imposibles en PowerShell. Sentí que los desarrolladores estaban tan entusiasmados con crear algo nuevo y potente que ignoraron lo que Bash y otras shells ya hacían bien.
    Tercero, hay una obsesión con exigir el formato Verb-Object en todos los nombres. Es subjetivo y habrá quienes lo defiendan, pero creo que vuelve feos los scripts, hace incómodo escribirlos y tampoco mejora de forma real la capacidad de descubrir o recordar comandos.
  • No me gusta PowerShell porque tiene innumerables puntos que sorprenden de formas demasiado distintas a Bash.
    También me confunde tener que usar la flecha derecha en vez del tabulador, y me resulta incómodo que no estén los comandos familiares y que haya reglas fuertes para nombrar cosas.
    Aun así, si lo conoces bien, PowerShell parece más capaz que Bash. Tiene un sistema de tipos mejor y es más fácil manejar argumentos, mientras que los valores de Bash se parecen más a cadenas sin forma.
    https://github.com/bionicles/tree_plus/blob/main/tests/more_... es una versión algo antigua que uso para configurar el entorno de pruebas en máquinas Windows, y muestra en cierta medida lo que es posible.

• Cuando usaba PowerShell directamente, no era horrible, pero nunca entendí por qué un arreglo de longitud 1 se desempaquetaba y se convertía en el tipo interno.
  Por eso había que estar pendiente cada vez de cuántos elementos podía traer un arreglo y, en lugar de tratarlo de forma general, revisarlo en cada modificación, lo que generaba una cantidad enorme de bugs. Me pregunto si alguien sabe por qué lo hicieron así.

  • La razón por la que todo alrededor de los arreglos es laxo es que la API de salida de los cmdlets también es laxa con los arreglos.
    Una sola función llamada WriteObject escribe el valor dado como salida del cmdlet, y si se llama una vez, eso se convierte en la salida. Si se llama varias veces, el shell no tiene más opción que reunir todos esos valores en un arreglo y producirlo como salida.
    Por lo tanto, si en una ejecución de un cmdlet se llama a WriteObject una sola vez y en otra ejecución se llama dos veces, en el primer caso el shell no puede saber que también debería haber envuelto esa salida única en un arreglo. Pero, si siempre envolviera la salida de los cmdlets en arreglos, estorbaría en cmdlets como Get-Date, cuyo resultado semánticamente es uno solo.
    Por alguna razón, parece que no querían complicar la API para que el propio cmdlet expresara si semánticamente producía una salida única o múltiple, independientemente del número real de llamadas a WriteObject. Una API así no podría ser una propiedad estática del cmdlet, porque la salida puede variar mucho según los parámetros, y un overload de WriteObject como (Object, bool iMightWriteMoreValues) también sería problemático porque tendría que funcionar con arreglos vacíos. Probablemente habría hecho falta una función separada IWillWriteMultipleValues().
    También se explica aquí: https://news.ycombinator.com/item?id=40874873
  • Esto es realmente molesto. Empecé a usar el comma hack, poniendo una coma al inicio para forzar un arreglo.
    $Ary = @(, "value")
    Al crear arreglos, sobre todo grandes, también es bastante buena la posibilidad de asignar un bucle for a un arreglo, porque tiene mejor rendimiento que +=. No era intuitivo como forma de llenar un arreglo, pero sin duda es útil.
    $Ary = foreach ($Obj in $Objs) { @{ foo = $Obj.foo } }
  • Esto suena como un caso típico de software que falla por intentar ser demasiado inteligente.
    Los desarrolladores de software siempre deben estar atentos a la tentación de hacer que su software sea demasiado inteligente.
  • Se siente como una función a medio cocinar.
    La otra mitad que faltó habría sido convertir automáticamente un valor único en un arreglo de longitud 1 cuando el receptor esperara un arreglo.
  • Parece que los lenguajes de nicho siempre terminan teniendo estas peculiaridades disparatadas.
    Es como una tragedia de Sísifo: aunque ya existen cosas como Lua, en vez de usarlas tal cual o modificarlas apenas un poco para obtener un lenguaje simple, pequeño, elegante y coherente, la gente reinventa la rueda y ni siquiera logra hacerla redonda.

• Si no necesitas un comando específico de PowerShell porque tienes que interactuar con subsistemas de Windows, uno piensa: “¿por qué no estoy usando Python?”.
  Es demasiado verboso y lento para el 90% de lo que haría con Bash, y lo mismo para lo que en otra vida habría hecho con Perl.
  A menudo me pregunto por qué Microsoft no lo construyó sobre algo como Python o Node. No recuerdo cuándo apareció PowerShell por primera vez, así que no estoy seguro de qué habría sido lo ideal en esa época.

  • El REPL básico de Python es realmente pésimo.
    Además, no está diseñado para las tareas de consola que PowerShell hace bien. Cosas que deberían ser tan simples como tomar el contenido de un archivo y pasarlo a otro comando terminan requiriendo que manejes tú mismo handles de archivo y cosas así.
    PowerShell es bueno porque es una navaja suiza: tiene un excelente REPL con autocompletado, no tiene comportamientos raros con espacios en blanco, tiene readline[0] y, si hace falta, permite hacer todo lo que se puede hacer con .NET.
    Además, al estar orientado a objetos, puedes concentrarte en la tarea real que tienes que hacer en vez de averiguar cómo parsear la salida basada en texto de una utilidad vieja con otra utilidad vieja.
    0: https://learn.microsoft.com/en-us/powershell/module/psreadli...
  • Originalmente se basaba de forma laxa en Perl y Korn shell.
    En la primera edición de “Powershell in Action”, de Bruce Payette, hay una explicación secundaria de que PowerShell se parece a Perl porque usa el símbolo @, la variable predeterminada $_ y el operador de llamada de función &. Dice que, de hecho, en algún momento Perl se usó como lenguaje raíz y que estos elementos vienen de esa etapa. Más tarde, la sintaxis cambió para alinearse más con C#, pero esos elementos se conservaron porque funcionaban bien y, en términos de Perl, contribuían mucho al “whipupitude quotient” del lenguaje.
    También dice que el lenguaje central de PowerShell se basa en la gramática POSIX 1003.2 de Korn shell, y que originalmente tomó modismos de Perl para conceptos avanzados como las tablas hash, pero que, a medida que avanzó el proyecto, quedó claro que tenía más sentido alinear la sintaxis de PowerShell con C#.
  • PowerShell salió 3 años antes que Node.
    Es muy probable que no se haya basado en otra cosa porque Microsoft controlaba .NET.
    No creo que sea lento por culpa de .NET; me parece más bien un problema de diseño o de falta de inversión en rendimiento.
    Aunque depende de qué versión de PS uses. Por lo que recuerdo, las versiones recientes son bastante rápidas.

• En el trabajo tuve la bendición de lidiar con una base de código de procedimientos almacenados de SQL Server de más de 20 años
  Eran unas 300 mil líneas de código crítico de negocio probado con monkey testing, pero no había control de versiones, nunca se le había hecho un ajuste de rendimiento en serio, se editaba y ejecutaba SQL en SSMS para desplegar en los entornos y, por supuesto, no había pruebas automatizadas
  La empresa está centrada en Windows, el desarrollo se hace en Mac y en GitHub Actions usamos Linux
  Elegimos herramientas como PowerShell Core, sqlcmd, docker para ejecutar una instancia de Windows SQL Server, RedGate SQL Compare para extraer el esquema y el código de servidores legados existentes, tSQLt para pruebas unitarias, TSqlLint para cumplimiento de código, SQLFluff para cumplimiento de estilo y Flyway para despliegues
  Rápidamente descubrimos que cuando Windows tiene que ser una de las plataformas, PowerShell Core es el shell de scripting multiplataforma con mejor interoperabilidad
  Programar en él no fue agradable. El motor de expresiones regulares viene de .NET y tiene problemas fatales de backtracking, y el comportamiento de los arrays también era raro. Lanzar ejecutables de la forma deseada y capturar los streams de salida era irregular; a menudo había que ejecutar un proceso, redirigir la salida a un archivo temporal y luego leer ese archivo cuando terminaba el proceso hijo. Incluso pasar la salida estándar de un proceso hijo por pipe a una variable string era más engorroso de lo necesario
  Pero PowerShell Core se ejecuta rápido. Si hay algo que Microsoft hace bien, es la microoptimización. También son buenas las herramientas para interactuar con el usuario, como un selector de listas con arte ASCII o un generador sencillo de prompts de entrada. Si evitas carpetas con archivos bloqueados, también se ocultan la mayoría de las rarezas extrañas del sistema de archivos de Windows
  Si buscas con empeño, por lo general puedes lograr lo que quieres. Lo recomendaría

• Coincido con otras impresiones de que, cada vez que mi carrera se acercó a la administración de Windows, realmente odié esa experiencia
  Pero a diferencia de todo lo demás en Windows, que es extremadamente tosco, PowerShell en sí era en realidad bastante bueno y siempre daba la sensación de haber sido diseñado con cuidado
  Linux es excelente y lo seguiré usando como entorno diario de trabajo, pero usar Bash es realmente espantoso. Aun así, como siempre está en todas partes, todos lo toman primero, y probablemente en 2100 seguiremos lidiando con scripts de Bash con toda clase de defectos

• PowerShell realmente parece un producto surgido de la confianza monopólica de Microsoft
  Crear un lenguaje con muy pocos puentes sintácticos para quienes vienen de otros lenguajes es algo audaz. No se podían adivinar ni inferir comandos, parámetros ni flags. Incluso considerando la ambición de Microsoft, debieron saber que legiones de administradores y programadores tendrían que aprender y mantener juntos scripts de PowerShell y Bash durante al menos décadas
  Una sintaxis extremadamente verbosa puede verse bien en una presentación de comité, pero cuando la tratas con frecuencia choca con límites bien estudiados del cerebro humano. Cuando el tamaño de la información o la latencia superan cierto nivel, se rompe el flujo de concentración y hacen falta enfoque, memorización explícita y verificación. Incluso con práctica, es difícil ejecutar rápidamente los conjuros comunes de shell que convierten una idea en realidad, y con solo esperar a que aparezca el autocompletado y decidir si aceptar la siguiente palabra de un comando compuesto por varias partes ya estás peleándote con la sintaxis
  Si buscas pow.. en el menú Inicio, aparecen cuatro fantásticas opciones: PowerShell, PowerShell ISE y las versiones normal y x86 de cada una. Cualquiera que elijas tarda en cargar y rompe el flujo. ISE muestra una pequeña pantalla de inicio y salta a otra ubicación. Otro cuadro de diálogo te informa que cerraste la sesión anterior sin guardar archivos de script sin nombre, pero de todos modos los vuelve a abrir como se esperaba. Entonces no sé por qué me regaña
  Puedes escribir o copiar texto y ejecutar cualquier código malicioso, pero si lo guardas como archivo y luego intentas ejecutarlo como script .ps, empieza el ridículo procedimiento de política de ejecución. Quizá era un trauma heredado de la mala reputación de seguridad del Internet Explorer temprano y de Windows
  Aun así intenté quererlo, pero un día un script se encontró con un nombre de archivo que contenía corchetes, y PowerShell interpretó implícitamente esos [1], [2] como algo parecido a iteradores: https://stackoverflow.com/questions/21008180/copy-file-with-...
  Una de las tareas centrales de un lenguaje de scripting es manejar archivos, y los nombres de archivo no están bajo el control de quien escribe el script; además, debería conocer el espacio de nombres de archivo válido en Windows. Ese episodio me dejó un problema de confianza duradero con el lenguaje
  El equipo de Azure, quizá porque tenía suficiente poder dentro de Microsoft, creó aparte una sintaxis sensata y legible como az find vm, az account show

  • No es así. PowerShell se inspiró en shells, Perl y varios otros lenguajes, y esas huellas se ven en su diseño
    Por otro lado, lo que buscaban era consistencia. El conocimiento de *NIX en la práctica se obtiene memorizando a lo bruto. -v suele ser verbose y -h suele ser help, pero en realidad no puedes confiar ni depender de nada

• Viéndolo ahora, resulta extraño que Microsoft no viera el valor de configurar todos los ajustes de Windows y de aplicaciones empresariales importantes como Active Directory y Exchange de una manera fácilmente componible y programable
  La idea de que propusieran como alternativa conectarse por Remote Desktop e ir haciendo clic con el mouse es absurda. Automatizar ese tipo de tareas, al menos según mi experiencia con AutoHotkey y Window Spy, es terriblemente difícil y molesto

  • Existe toda una industria de consultores y proveedores de software que no quiere el resultado de hacer que la configuración de Windows sea fácilmente componible y programable
    Conectarse por Remote Desktop y hacer clic con el mouse genera muchas horas facturables
    Es irónico que el hecho de que eso sea terriblemente difícil y molesto probablemente sea una de las principales razones por las que existen sistemas operativos alternativos
  • Lo más extraño es que esa mentalidad de “andar haciendo clic” también llegó a Azure
    Antes, para ser justos hace unos 10 años, recibí una sugerencia seria de una persona de soporte técnico de que la mejor manera de automatizar cierta configuración era Selenium

• Uso computadoras desde 1982, pero nunca, ni una sola vez, fui usuario de Windows.
  A principios de los 90, cuando Wintel iba en ascenso, seguí el crecimiento de Linux y 386BSD; a fines de los 90, cuando Win95 y NT dominaban los escritorios empresariales, me refugié en SPARCStation, Linux y hardware NeXT descontinuado. Después del cambio de siglo, adopté el recién compatible con POSIX Mac OS.
  Durante casi medio siglo, evitar los productos de Microsoft fue una parte central de mi política informática, con la notable excepción de Applesoft BASIC.
  Pero PowerShell es bueno.

  • Parece tener mucha experiencia en computación, especialmente en corrientes de innovación que cambiaron paradigmas.
    Sin embargo, el segundo párrafo evita deliberadamente las expectativas que creó el primero; me gustaría que explicara por qué considera que PowerShell es “bueno”.
  • Me da curiosidad qué hace que PowerShell sea mejor que Bash.

• Cuando hay que escribir directamente herramientas de línea de comandos en un lenguaje de programación adecuado, como C/C++, la diferencia de productividad entre hacerlas para shells tradicionales y hacerlas para PowerShell está subestimada.
  Por lo general, nunca he creado una herramienta CLI útil sin miles de líneas o menos de código desordenado. Normalmente hay que manejar entrada por pipeline, parámetros opcionales, parámetros con valores, valores predeterminados y sobrescrituras, modo dry run, requisitos de distintos formatos de salida, etc.; el 90% termina siendo ruido y solo el 10% es el comportamiento real.
  En PowerShell, un módulo de C# básicamente solo tiene unas 20 líneas de sobrecarga y todo lo demás es comportamiento real. La productividad es sorprendente.
  Obtienes gratis validación de parámetros, autocompletado con Tab de nombres de parámetros, entrada y salida por pipeline, formateo, tipado fuerte, globbing, etc.

  • Nunca usé C#, pero estoy de acuerdo.
    En tareas de mantenimiento y administración, cada vez más me estoy pasando de herramientas CLI a lenguajes compilados o interpretados.