A história de Jeffrey Snover no desenvolvimento do PowerShell

 (corecursive.com)
1 pontos por GN⁺ 2024-07-05 | 1 comentários | Compartilhar no WhatsApp
  • Jeffrey Snover impulsionou o PowerShell para transformar o Windows em um sistema operacional de servidor administrável por linha de comando, e precisou superar a cultura da Microsoft centrada em GUI e a resistência organizacional
  • No início, portar ferramentas UNIX não resolvia o problema de administração de servidores, porque a arquitetura do Windows dependia de APIs como Registry, Active Directory e WMI, e não de arquivos
  • Depois de criar 70 comandos baseados em WMI no WMIC, ele mudou de direção para um motor de geração de comandos baseado em metadados para reduzir gargalos e custos de testes
  • O antecessor do PowerShell, o Monad, nasceu na onda do .NET e do Longhorn, mas foi empurrado para fora do Windows após o reset do Longhorn e sobreviveu com o apoio da equipe do Exchange e da organização do Windows Server
  • Snover aceitou perda de cargo e de remuneração para se concentrar no PowerShell 1~4, e a ferramenta se tornou a base da automação da administração do Windows e da migração do Office para a nuvem

Windows centrado em GUI e o problema da gestão de datacenters

  • O PowerShell foi uma ferramenta de linha de comando que mudou a administração de sistemas Windows, mas não foi um projeto naturalmente aceito dentro da Microsoft desde o início
  • Na época, a cultura da Microsoft era centrada em GUI, e a interface de linha de comando era tratada como algo ultrapassado, a ponto de existir a anedota de Bill Gates dizer que command.exe seria a última vez que ele veria aquilo
  • O ponto de partida de Snover ao entrar na Microsoft foi a percepção de que era preciso adaptar um sistema operacional baseado em Windows NT para o mercado de datacenters e empresas
    • O objetivo era competir com fornecedores UNIX como Sun, IBM e HP
    • Intel e o ecossistema de hardware aberto tinham vantagens de custo, mas o software de administração de servidores ainda não era bom o bastante

Um modelo de administradores que reduz a dependência de integradores de sistemas

  • A administração de servidores Windows exigia configurar muitos servidores por cliques, e como cada empresa precisava de uma configuração diferente, isso podia aumentar a dependência de integradores de sistemas
  • Snover via que, se o custo dos integradores crescesse, a vantagem de preço do Windows desapareceria
    • Como exemplo, ele citava uma estrutura de custos com hardware 10, software 2 e integrador de sistemas 40
    • Também era problemático que o relacionamento com o cliente e o valor agregado migrassem para o integrador
  • A alternativa era o modelo UNIX de administrador programador
    • Uma forma de combinar pequenas ferramentas para resolver problemas específicos e automatizar tarefas
    • O Windows também precisava de uma camada de administradores especializados que lidassem com scripts e automação, e não apenas de “administradores que só clicam em Next”

Por que portar ferramentas UNIX não funcionava

  • A solução inicial foi usar o Windows Services for Unix para levar ao Windows um shell UNIX e ferramentas como AWK/GREP/SED
  • Mas a estrutura de administração do Windows era diferente da do UNIX
    • O UNIX é um sistema operacional centrado em arquivos, então muitas tarefas de administração podem ser resolvidas manipulando arquivos e reiniciando processos
    • O Windows tinha uma estrutura em que os recursos ficavam atrás de APIs, como Registry, Active Directory e WMI
    • AWK não se encaixava diretamente no Registry, SED não se encaixava no Active Directory, e GREP não se encaixava no WMI
  • O WMI tinha potencial para tarefas administrativas, mas não era amplamente usado, então a equipe de Snover tentou criar uma ferramenta de linha de comando para lidar com objetos WMI

WMIC e o motor baseado em metadados

  • Na era do Windows XP, havia a restrição de apenas 10 semanas de janela de codificação para criar uma interface de linha de comando baseada em WMI
  • Engenheiros contratados implementaram 70 tarefas, mas isso estava muito longe da cobertura necessária para administrar todo o Windows Server
  • Dentro da Microsoft, nada era lançado sem aprovação da organização de testes, e o gargalo de testes crescia à medida que o número de comandos aumentava
  • Snover insistiu em uma abordagem parecida com a relação entre HTML e navegador: tratar comandos individuais não como código, mas como metadados, testando apenas um motor comum
    • O motor geraria os comandos, e a configuração de cada comando seria expressa em metadados em um formato como XML
    • Durante as férias de Natal, ele escreveu os metadados e criou 72 comandos
    • Ele relembra que os 70 comandos anteriores custaram cerca de US$ 4 milhões, enquanto o motor custou cerca de US$ 60 mil
  • Quando recursos como filtragem e formatação foram adicionados ao motor, todos os comandos melhoraram junto, algo que se tornou um importante prenúncio da arquitetura do PowerShell

Longhorn, .NET e Monad

  • Bill Gates viu que usuários do Windows 98 não estavam migrando bem para o XP e quis fazer do Longhorn um novo ponto de virada como o Windows 95
    • O Longhorn incluiria um modelo de desenvolvimento baseado em .NET, WPF, WCF e um novo modelo de armazenamento
  • Snover concluiu que o .NET poderia ser um meio de ampliar o alcance da administração do Windows
    • Escrever providers de WMI não ganhava tração suficiente, mas Bill Gates pressionava fortemente pela adoção do .NET
    • Ele acreditava que, ao colocar utilitários de administração sobre .NET, seria possível cobrir um escopo maior
  • Quando outra organização tentou portar o K-shell para criar um shell, Snover explicou que havia uma abordagem melhor, mas não conseguiu convencer o grupo
  • Então ele se trancou em uma sala e criou um protótipo de cerca de 10 mil linhas, que já continha os princípios centrais da arquitetura do PowerShell
    • Depois da demonstração, a equipe adotou a ideia, e Snover pensou que talvez aquela fosse sua melhor ideia
    • Para participar do projeto, ele abriu mão do papel de chief architect de produtos e serviços com centenas a mil pessoas, aceitando na prática um rebaixamento

O Monad Manifesto e a persuasão das equipes

  • A nova equipe definiu o nome do projeto como Monad e, por falta de pessoal, terceirizou parte do trabalho para a Índia
  • Snover escreveu o Monad Manifesto para alinhar a visão do projeto e o caminho para o sucesso
    • Ele organizou o problema, as abordagens existentes, a nova abordagem, o valor gerado e os diferenciais
    • Também deixou claro que valor seria entregue para cada grupo interessado, como administradores, provedores e equipes de desenvolvimento
  • Cada equipe da Microsoft já tinha trabalho demais, e ninguém seria demitido por não criar uma interface de linha de comando, nem promovido por criá-la
  • A proposta do Monad era que cada equipe de produto escrevesse apenas o código para manipular seus próprios objetos, enquanto o restante seria fornecido pelo PowerShell
    • Formatação, ordenação, filtragem, parser, execução remota e elevação de privilégios seriam fornecidos pelo lado do PowerShell
    • Cada equipe só precisaria informar como manipular seus objetos de domínio
  • A equipe do Active Directory investiu algumas semanas para criar alguns cmdlets e, quando a reação dos grupos de usuários foi forte, acabou avançando em mais trabalho

Volta ao Windows após o reset do Longhorn

  • No Longhorn, a adoção do .NET foi levada longe demais e os problemas cresceram
    • Um exemplo citado é o da caixa de diálogo Save As do Notepad aparecer só depois de 1 minuto e 30 segundos por causa de uma caixa de diálogo comum baseada em .NET/WCF, com o working set saltando de 15 KB para 15 MB
    • Também há o relato de que os builds noturnos ficaram sem funcionar por cerca de 7 meses
  • A organização do Windows fez um reset e removeu o código .NET do Windows, e o PowerShell também foi empurrado para fora
  • Depois disso, o PowerShell sofreu pressão recorrente de cancelamento por ser uma interface de linha de comando e também por ser baseado em .NET
    • Bill Gates entendia o valor, mas isso não ajudava na defesa cotidiana
    • O responsável pelo Windows Server deu apoio em momentos decisivos
    • A equipe do Exchange ajudou a bloquear o cancelamento ao argumentar que dependia do PowerShell para um “negócio de dezenas de bilhões de dólares”
  • Os requisitos do WinArch para colocar o .NET no Windows eram muito rigorosos, mas a equipe do PowerShell se preparou para cumprir todas as condições
  • Quando a liderança do Windows pediu a retirada da solicitação, o gerente de programa exigiu uma recusa formal, o que levou à abertura de um processo de revisão
    • A organização do Windows Server tinha a palavra final e decidiu que o PowerShell atendia aos requisitos, permitindo sua volta ao Windows

PowerShell 1~4 e o impacto real

  • O PowerShell 1 foi lançado como parte do Windows Vista
  • Após o lançamento, Snover recebeu conselhos para ir fazer outra coisa e alertas de que aquilo prejudicaria sua carreira, mas ele continuou focado na mesma visão até o PowerShell 2, 3 e 4
    • Segundo ele, a versão 1 atingiu parte dos objetivos, as versões 2 e 3 completaram recursos importantes, e a versão 4 quase concluiu a visão original
  • O PowerShell fez com que administradores de Windows passassem a escrever scripts e automatizar tarefas complexas
    • Surgiram grupos de usuários, perguntas e respostas online, compartilhamento de scripts e apresentações em conferências
    • Alguns administradores se tornaram palestrantes profissionais graças à experiência com PowerShell
  • Cerca de 5 anos depois, Snover se tornou Distinguished Engineer e depois virou Technical Fellow
  • O responsável pelo Office afirmou que, sem o PowerShell, a migração do Office para a nuvem teria sido difícil, e que essa migração também influenciou a ida do Azure para a nuvem
    • Antes, o provisionamento de servidores era feito por cliques, o que dificultava repetição e correções
    • Com scripts, foi possível escalar e, quando surgiam problemas, bastava ajustar os scripts para responder

Leituras relacionadas

1 comentários

 
GN⁺ 2024-07-05
Comentários do Hacker News

  • Do ponto de vista do apresentador, o PowerShell enfrentou uma oposição extrema dentro da Microsoft, e seu criador, Jeffrey Snover, chegou a ser rebaixado por insistir nele
    Jeffrey foi originalmente contratado para ajudar a Microsoft a aprender a competir em datacenters, mas a cultura da época estava presa demais a uma visão de mundo centrada em computadores pessoais, então houve resistência a cada passo
    Outro ponto interessante é que o PowerShell surgiu porque o Windows não era baseado em arquivos. O objetivo de Jeffrey era a administração de servidores, mas no Windows não era possível gerenciar tudo apenas editando arquivos de configuração; era preciso chamar várias APIs e trocar dados estruturados, então um modelo de objetos rico era, na prática, a única saída
    A transcrição foi feita na ordem de transcrição profissional, Descript, revisão de pontuação pelo GPT-4 e uma passada manual, então a qualidade pode não estar tão alta quanto o esperado

    • Se a equipe MS-PWSH estiver vendo isto, gostaria que adicionassem recursos básicos de GUI que não exigissem escrever muito código .NET diretamente
      Gosto do PowerShell porque ele é uma linguagem dinâmica simples e permite encadear comandos fáceis de usar, então seria bom ter um novo conjunto de cmdlets para criar interfaces de usuário simples e gráficos
      Por exemplo, um recurso como Create-Chart -Type "Bar" -XAxis $Cities -YAxis $GDP -OutputFile "C:/Documents/ProjectAnalysis/CitiesBarGraph.png" parece algo que a Microsoft poderia incluir facilmente no produto, e eliminaria uma página de código boilerplate que eu nem entendo bem
      Deve haver milhões de usuários que sabem o básico de programação, mas para quem ferramentas como Java ou C# não combinam com a função que exercem. Python geralmente se encaixa bem, mas eu gostaria que a Microsoft criasse algo a mais que pudesse ser usado não só por administradores de servidores ou profissionais de TI, mas também por usuários corporativos comuns
      Se a Microsoft investisse mais para que o PowerShell não fosse lento em tarefas como parsing de arquivos e adicionasse os recursos mencionados acima, além de cmdlets de estatística e ciência, ele poderia se tornar uma ferramenta bastante incrível para um analista de negócios comum criar rapidamente softwares de melhoria de processos ou protótipos a serem repassados à equipe de desenvolvimento
      A Microsoft parece enxergar as opções como três: desenvolvedores de software formais usando C#, trabalho de TI usando PowerShell e Excel para usuários de negócios. O Excel é excelente em muitos aspectos, mas é bastante limitado, e VBA+Excel está entre os ecossistemas mais restritivos com que já lidei. Linguagens de terceiros como Python e R são uma quarta opção, mas eu gostaria que a Microsoft dedicasse mais tempo a essa área
    • Vendo no GitHub os MVPs reclamarem que o investimento adicional prometido pela Microsoft não se concretizou, que mudanças não foram incorporadas e que bons recursos estão abandonados, parece que isso já não é uma prioridade da MSFT
      Eu gostava do PowerShell, inclusive de suas esquisitices, mas já o deixei para trás
    • Fico curioso sobre por que o criaram do zero, em vez de usar Python ou alguma ferramenta existente semelhante
    • Tentei ler a transcrição, mas não consegui chegar ao fim, e achei um pouco difícil de ler
      Enquanto lia, imaginei que tivesse sido gerada por máquina, mas é difícil dizer exatamente por quê; parece que precisaria de um pouco de edição para ficar mais legível
      Ainda assim, é muito melhor do que não ter transcrição nenhuma

  • Como desenvolvedor que usa Bash há muito tempo, fiquei realmente empolgado quando o PowerShell apareceu
    Achei que finalmente o Windows teria um shell bacana para desenvolvimento, mas depois disso nunca consegui assimilar de fato o PowerShell, e continuo usando no Windows o Bash com o qual já estou familiarizado
    Fico curioso para saber como desenvolvedores proficientes nos dois shells os comparam. Quero saber se o PowerShell realmente cumpriu a promessa de ser um shell mais eficiente e moderno, ou se é usado por vir instalado por padrão e ser melhor que o CMD

    • Usei bastante Bash e também li alguns livros, mas acredito firmemente que não se deve escrever scripts Bash complexos
      Para mim, passou de umas 50 linhas é cheiro ruim de código, e deixei esta página salva para quando precisar convencer alguém: http://mywiki.wooledge.org/BashPitfalls
      Testando PowerShell recentemente, o fato de os comandos retornarem objetos em vez de texto, sem precisar manipular texto à força, tornou tudo muito mais fácil como linguagem de script e de linha de comando
      Também é excelente existir uma forma oficial de tratar parsing de argumentos. Tudo é unificado, e na janela da linha de comando dá para autocompletar praticamente todas as opções, algo que o Bash nem sonha em fazer; isso aumenta muito a produtividade
      Por outro lado, conversões de tipo também criam bugs novos que não existiam no Bash. Hoje prefiro mais o PWSH, mas desgosto um pouco dos dois e estou esperando a próxima evolução natural
    • O PowerShell é mais verboso que o Bash e tem esquisitices, como desembrulhar automaticamente arrays de 0 ou 1 elemento em escalares em momentos inesperados, mas é mais produtivo e legível
      A orientação a objetos é bastante útil ao montar pipelines
      Por exemplo, para agrupar recursivamente arquivos dentro de uma pasta por tamanho e encontrar candidatos a duplicados, dá para escrever Get-ChildItem -File -Recurse | Group-Object -Property Length | Where-Object { $_.Count -gt 1 } | Sort-Object -Property Count
      Não é preciso decorar invocações obscuras de file nem fazer parsing de saída textual. Você recebe objetos reais com propriedades, e o autocomplete por Tab consegue enxergar essa estrutura
      Se precisar fazer parsing de JSON, basta usar Get-Content -Raw whatever.json | ConvertFrom-Json, sem jq. Para transformar XML em CSV, use ConvertFrom-Xml ou Select-Xml, faça o que for necessário e depois use ConvertTo-Csv
      Se Get-ChildItem for longo demais, use gci, dir ou ls; se Where-Object for longo, use where ou ?. Por padrão, também não diferencia maiúsculas de minúsculas
    • Comecei a carreira em um terminal X de uma pizza box SunOS, escrevi milhares de scripts, muitos deles com milhares de linhas
      Alguns anos atrás, precisei escrever em PowerShell um sistema robusto de transferência de dados, complexo e autônomo, e a experiência foi tão boa que troquei todos os shells do macOS e do Linux por PWSH
      O que mais gostei foi o poder de passar objetos pelo pipeline. Mesmo extraindo e manipulando algumas propriedades do objeto no primeiro filtro, eu ainda conseguia acessar, nos filtros posteriores do pipeline, outras propriedades e as propriedades do objeto criadas pelo primeiro filtro
      A consistência de comandos, tratamento de erros e propriedades dos objetos também era muito boa
      Depois, com a mudança no tipo de trabalho, a memória muscular antiga voltou e reverti todos os shells para Bash. Quando eu trabalhava e pensava bastante naquele espaço, o PWSH parecia natural como shell, mas, depois que saí dele, pensar em PWSH ficou mais difícil do que voltar ao Bash
      Às vezes sinto falta. Não há nada tão próximo nesse espaço de shell e, pelo menos, nenhuma alternativa próxima o bastante para justificar o esforço de migração
    • Não sou especialista em nenhum dos dois, mas já usei bastante, e sinto que o PowerShell se tornou horrível de usar por causa de algumas armadilhas
      Primeiro, a tentativa de ser uma linguagem .NET. Não sei por que a promessa do .NET de um runtime e várias linguagens floresceu no lado do Java mesmo sem essa promessa, mas murchou no .NET; se é para escrever código .NET, acho melhor usar C#
      Segundo, ele não acertou bem os fundamentos de um shell. Os detalhes já ficaram no passado e não lembro mais, mas o tratamento de redirecionamento era quebrado, e coisas triviais no Bash eram quase impossíveis no PowerShell. Tive a impressão de que os desenvolvedores estavam empolgados em criar algo novo e poderoso e ignoraram aquilo que Bash e outros já faziam bem
      Terceiro, há uma fixação em exigir o formato Verb-Object em todos os nomes. É subjetivo e há quem defenda, mas acho que deixa os scripts feios, torna a digitação estranha e não melhora de forma substancial a capacidade de descoberta nem de memorização
    • Não gosto do PowerShell porque há inúmeros pontos em que ele surpreende de formas muito diferentes do Bash
      Também é confuso acabar usando a seta para a direita em vez de Tab, e me incomodam a ausência de comandos familiares e as regras fortes de nomenclatura
      Ainda assim, conhecendo bem, o PowerShell parece mais capaz que o Bash. Ele tem um sistema de tipos melhor e é mais fácil lidar com argumentos, enquanto os valores do Bash são mais próximos de strings sem forma
      https://github.com/bionicles/tree_plus/blob/main/tests/more_... é uma versão um pouco antiga que uso ao configurar um ambiente de testes em uma máquina Windows, e mostra um pouco do que é possível

  • Ao usar PowerShell diretamente, não era horrível, mas eu não entendia por que um array de comprimento 1 era desembrulhado do array e virava seu tipo interno
    Por causa disso, era preciso se preocupar toda vez com quantos itens poderiam vir no array e, em vez de tratar de forma genérica, verificar a cada alteração, o que gerou bugs enormes. Fico curioso se alguém sabe por que fizeram assim

    • O motivo de haver essa flexibilidade em torno de arrays é que a API de saída dos cmdlets também é flexível em relação a arrays
      Uma única função chamada WriteObject grava um valor dado como saída do cmdlet e, se for chamada uma vez, aquilo passa a ser a saída. Se for chamada várias vezes, o shell não tem escolha a não ser juntar todos esses valores em um array como saída
      Portanto, se em uma execução de um cmdlet ele chama WriteObject apenas uma vez e em outra execução chama duas vezes, no primeiro caso o shell não tem como saber que deveria embrulhar aquela saída única em um array também. Por outro lado, se sempre embrulhasse a saída dos cmdlets em arrays, isso atrapalharia cmdlets cujo resultado semanticamente é único, como Get-Date
      Por algum motivo, parece que não quiseram complicar a API para que o próprio cmdlet expressasse se sua saída é semanticamente única ou múltipla, independentemente do número real de chamadas a WriteObject. Uma API assim não poderia ser uma propriedade estática do cmdlet, já que a saída pode variar bastante dependendo dos parâmetros, e um overload de WriteObject como (Object, bool iMightWriteMoreValues) também seria problemático, pois teria de funcionar com arrays vazios. Provavelmente seria necessária uma função separada IWillWriteMultipleValues()
      Também há uma explicação aqui: https://news.ycombinator.com/item?id=40874873
    • Isso é realmente irritante. Comecei a usar o comma hack, colocando uma vírgula no início para forçar um array
      $Ary = @(, "value")
      Ao criar arrays, especialmente arrays grandes, isso também tem desempenho melhor do que +=, então o recurso de atribuir um loop for a um array é bem interessante. Não era intuitivo como forma de preencher um array, mas certamente é útil
      $Ary = foreach ($Obj in $Objs) { @{ foo = $Obj.foo } }
    • Isso soa como um caso clássico de software que falha ao tentar ser esperto demais
      Desenvolvedores de software devem estar sempre atentos à tentação de tornar seu software esperto demais
    • Parece um recurso meio incompleto
      A outra metade que faltou provavelmente seria converter automaticamente um valor único em um array de comprimento 1 quando o lado receptor esperasse um array
    • Parece que linguagens de nicho sempre acabam tendo esse tipo de esquisitice maluca
      Mesmo já existindo algo como Lua, em vez de usar aquilo como está ou modificá-lo um pouco para obter uma linguagem simples, pequena, elegante e consistente, parece a tragédia de Sísifo de pessoas reinventando a roda e ainda assim não conseguindo fazê-la redonda

  • A menos que eu precise de um comando específico do PowerShell porque tenho que interagir com subsistemas do Windows, fico pensando: “por que não estou usando Python?”
    Para 90% do que eu faria em Bash, ele é verboso e lento demais, e o mesmo vale para coisas que, em outra vida, eu teria feito em Perl
    Frequentemente me pergunto por que a Microsoft não o construiu em cima de algo como Python ou Node. Não lembro quando o PowerShell apareceu pela primeira vez, então não tenho certeza do que teria sido ideal na época

    • O REPL padrão do Python é realmente péssimo
      Além disso, ele não foi projetado para as tarefas de console em que o PowerShell é bom. Em vez de simplesmente pegar o conteúdo de um arquivo e passá-lo para outro comando, você precisa fazer coisas manualmente, como gerenciar handles de arquivo
      O PowerShell é bom porque é um canivete suíço: tem um ótimo REPL com autocompletar, não tem comportamentos estranhos com espaços em branco, tem readline[0] e, se necessário, permite fazer tudo o que é possível fazer com .NET
      Além disso, por ser orientado a objetos, você pode se concentrar no trabalho real que precisa fazer em vez de descobrir como analisar a saída baseada em texto de um utilitário antigo com outro utilitário antigo
      0: https://learn.microsoft.com/en-us/powershell/module/psreadli...
    • Originalmente, era vagamente baseado em Perl e Korn shell
      A primeira edição de “Powershell in Action”, de Bruce Payette, tem uma observação lateral dizendo que o PowerShell parece Perl porque usa o símbolo @, a variável padrão $_ e o operador de chamada de função &. Na prática, em certo momento Perl foi usado como linguagem-raiz, e esses elementos vieram dessa época. Mais tarde, a sintaxe mudou para se alinhar mais ao C#, mas esses elementos foram mantidos porque funcionavam bem e, em termos de Perl, contribuíam muito para o “whipupitude quotient” da linguagem
      Também diz que a linguagem central do PowerShell se baseia na sintaxe POSIX 1003.2 do Korn shell e que, originalmente, ele adotou idioms de Perl para conceitos mais avançados, como tabelas hash, mas, conforme o projeto avançou, ficou claro que fazia mais sentido alinhar a sintaxe do PowerShell ao C#
    • PowerShell saiu 3 anos antes do Node
      O fato de não ter sido baseado em alguma outra coisa provavelmente se deve ao fato de a Microsoft controlar o .NET
      Não acho que a lentidão seja por causa do .NET; parece mais um problema de design ou de falta de investimento em desempenho
      Mas depende de qual versão do PS você está usando. Pelo que lembro, as versões mais recentes são bem rápidas

  • No trabalho, tive a bênção de lidar com uma base de código de stored procedures do SQL Server com mais de 20 anos
    Eram cerca de 300 mil linhas de código crítico de negócio testado por “monkey testing”, mas não havia controle de código-fonte, nunca tinha passado por um ajuste de desempenho de verdade, o SQL era editado e executado no SSMS para fazer deploy nos ambientes e, obviamente, não havia testes automatizados
    A empresa é centrada em Windows, o desenvolvimento é feito no Mac e o GitHub Actions usa Linux
    Escolhi ferramentas como PowerShell Core, sqlcmd, docker para executar uma instância do Windows SQL Server, RedGate SQL Compare para extrair schema e código dos servidores legados existentes, tSQLt para testes unitários, TSqlLint para conformidade de código, SQLFluff para conformidade de estilo e Flyway para deploy
    Quando o Windows precisa ser uma das plataformas, logo percebi que o PowerShell Core é o shell de scripting multiplataforma com a melhor interoperabilidade
    Programar nele não foi prazeroso. O motor de expressões regulares vem do .NET e tem problemas fatais de backtracking, e o comportamento dos arrays também era estranho. Iniciar executáveis do jeito desejado e capturar os streams de saída também era inconsistente, então muitas vezes eu precisava executar o processo, redirecionar a saída para um arquivo temporário e, depois que o processo filho terminasse, ler esse arquivo. Passar a saída padrão de um processo filho por pipe para uma variável de string também era mais trabalhoso do que precisava ser
    Mas o PowerShell Core é rápido de executar. Se há algo que a Microsoft faz bem, é micro-otimização. As ferramentas para interagir com o usuário também são boas, como seletores de lista em ASCII art ou geradores simples de prompts de entrada. Se você evitar pastas com arquivos bloqueados, a maioria das estranhezas peculiares do sistema de arquivos do Windows também fica escondida
    Procurando com afinco, em geral dá para fazer o que se quer. Recomendo

  • Concordo com outros comentários dizendo que, toda vez que a carreira se aproximava de administração Windows, a experiência era algo de que realmente não gostavam
    Mas, ao contrário de todo o restante do Windows, que é extremamente tosco, o PowerShell em si era de fato muito bom e sempre pareceu cuidadosamente projetado
    Linux é excelente e vou continuar usando como ambiente diário de trabalho, mas usar Bash é realmente horrível. Ainda assim, como ele está sempre em todo lugar, todo mundo acaba recorrendo a ele primeiro, e provavelmente ainda estaremos lidando com scripts Bash cheios de defeitos em 2100

  • O PowerShell realmente parece um produto nascido da confiança monopolista da Microsoft
    Criar uma linguagem com quase nenhum ponto de ligação sintática para quem vem de outras linguagens é algo ousado. Não dava para adivinhar nem inferir comandos, parâmetros ou flags. Mesmo considerando a ambição da Microsoft, eles deveriam saber que legiões de administradores e programadores teriam de aprender e manter PowerShell e scripts Bash em conjunto por pelo menos várias décadas
    Uma sintaxe extremamente verbosa pode parecer boa em uma apresentação de comitê, mas, quando você lida com ela com frequência, ela entra em conflito com limites bem estudados do cérebro humano. Quando o tamanho da informação ou a latência passa de certo nível, o fluxo de imersão se quebra, e passam a ser necessários concentração, memorização explícita e reconfirmação. Mesmo com prática, é difícil executar rapidamente os feitiços comuns de shell que transformam pensamento em realidade; só esperar o autocompletar aparecer e decidir se aceita a próxima palavra de um comando com várias partes já obriga a lutar com a sintaxe
    Se você procura por pow.. no menu Iniciar, aparecem quatro belas opções: PowerShell, PowerShell ISE e as versões normal e x86 de cada um. Qualquer uma delas leva um tempo para carregar e quebra o fluxo. O ISE mostra uma pequena tela de splash e pula para outro lugar. Outro diálogo informa que você fechou a última sessão sem salvar um arquivo de script sem nome, mas de qualquer forma o reabre como esperado. Então não sei por que me dá bronca
    Você pode digitar ou copiar texto e executar qualquer código malicioso, mas, se salvar em um arquivo e tentar executar como script .ps, começa um procedimento ridículo de política de execução. Talvez fosse trauma da má reputação de segurança do Internet Explorer inicial e do Windows
    Mesmo assim tentei gostar dele, até que um dia um script encontrou um nome de arquivo com colchetes, e o PowerShell interpretou implicitamente aqueles [1], [2] como algo parecido com iteradores: https://stackoverflow.com/questions/21008180/copy-file-with-...
    Uma das tarefas centrais de uma linguagem de scripting é lidar com arquivos, mas nomes de arquivos não estão sob controle de quem escreve o script, e ela deveria conhecer o espaço de nomes de arquivo válido no Windows. Esse episódio criou para mim um problema duradouro de confiança na linguagem
    A equipe do Azure aparentemente tinha poder suficiente dentro da Microsoft para criar à parte uma sintaxe sensata e legível como az find vm, az account show

    • Não é bem assim. O PowerShell se inspirou em shells, Perl e várias outras linguagens, e esses traços aparecem no design
      O outro lado era querer consistência. Conhecimento de *NIX, na prática, costuma ser obtido por memorização bruta. -v geralmente é verbose e -h geralmente é help, mas, na realidade, não dá para confiar nem depender de nada

  • Olhando agora, é estranho que a Microsoft não tenha visto o valor de tornar todas as configurações do Windows e de aplicações corporativas importantes como Active Directory e Exchange fáceis de compor e programar
    A ideia de propor, como alternativa, conectar por Remote Desktop e sair clicando com o mouse é absurda. Automatizar esse tipo de trabalho é, pelo menos pela minha experiência com AutoHotkey e Window Spy, terrivelmente difícil e irritante

    • Existe toda uma indústria de consultores e fornecedores de software que não quer o resultado de tornar as configurações do Windows facilmente componíveis e programáveis
      Conectar por Remote Desktop e clicar com o mouse gera muitas horas faturáveis
      É irônico que o fato de esse tipo de coisa ser terrivelmente difícil e irritante provavelmente seja um dos principais motivos para existirem sistemas operacionais alternativos
    • O mais estranho ainda é que essa mentalidade de “sair clicando por aí” entrou também no Azure
      Antigamente — para ser justo, uns 10 anos atrás —, recebi de uma pessoa do suporte técnico a sugestão séria de que a melhor forma de automatizar certa configuração era Selenium

  • Uso computadores desde 1982, mas nunca fui usuário de Windows, nem uma única vez.
    No começo dos anos 1990, quando o Wintel estava em ascensão, acompanhei o crescimento do Linux e do 386BSD; no fim dos anos 1990, quando o Win95 e o NT dominavam os desktops corporativos, refugiei-me em SPARCStation, Linux e hardware NeXT descontinuado. Depois da virada do século, adotei o Mac OS, que havia passado a ser compatível com POSIX.
    Por quase meio século, evitar produtos da Microsoft foi um ponto central da minha política de computação, com uma exceção digna de nota: o Applesoft BASIC.
    Mas PowerShell é bom.

    • Parece ter uma longa experiência com computação, especialmente com ondas de inovação que mudaram paradigmas.
      Só que o segundo parágrafo desvia deliberadamente da expectativa criada pelo primeiro; eu gostaria que explicasse por que considera o PowerShell “bom”.
    • Fico curioso para saber o que torna o PowerShell melhor que o Bash.

  • Quando é preciso escrever ferramentas de linha de comando diretamente em algo que seja uma linguagem de programação adequada, como C/C++, a diferença de produtividade entre fazê-las para shells tradicionais e fazê-las para PowerShell é subestimada.
    Em geral, nunca consegui criar uma ferramenta CLI útil sem milhares de linhas de código bagunçado ou menos do que isso. Normalmente é preciso lidar com entrada via pipeline, parâmetros opcionais, parâmetros com valores, valores padrão e sobrescritas, modo dry run, requisitos de vários formatos de saída etc.; 90% acaba sendo ruído, e só 10% é o comportamento real.
    No PowerShell, um módulo em C# basicamente tem só umas 20 linhas de overhead, e todo o resto é comportamento real. A produtividade é surpreendente.
    Você ganha de graça validação de parâmetros, autocompletar com Tab para nomes de parâmetros, entrada e saída via pipeline, formatação, tipagem forte, globbing etc.

    • Nunca usei C#, mas concordo.
      Em tarefas de manutenção e administração, estou migrando cada vez mais de ferramentas CLI para linguagens compiladas ou interpretadas.