Toda a minha carreira na Microsoft incluiu a criação de ferramentas para desenvolvedores Linux. Entrei na Microsoft em agosto de 2016, depois de me formar na Universidade da Virgínia, tendo estudado ciência da computação e empreendedorismo. A maior parte da minha experiência em programação na universidade era com o C ++, e o sistema operacional que eu usava quase exclusivamente era o Linux.
Minha experiência pode não parecer um ajuste óbvio para a Microsoft, mas, na época, a Microsoft passava por uma mudança total em engenharia e cultura para um lugar onde todos os sistemas operacionais eram importantes, incluindo o Linux.
Meu primeiro trabalho na Microsoft foi no SQL Server na equipe do Linux – eles especificamente me pediram para se juntar a eles para trazer minha experiência em Linux para a equipe. Isso me surpreendeu ao ouvir que eu poderia fornecer valor para a equipe com base na minha experiência, mesmo que eu fosse uma nova graduada.
A ideia de que a Microsoft faria uma versão do SQL Server no Linux tinha sido uma piada do Dia da mentira de alguns anos antes, mas em 2016 era real. Entrei na equipe logo após o envio da primeira versão e me concentrei em aprimorar as ferramentas do SQL Server – especificamente para administradores usados no gerenciamento de servidores e aplicativos Linux. A execução do SQL Server no Linux exigia a criação de ferramentas de linha de comando projetadas para o funcionamento normal do Linux.
Eu também tive a chance de projetar a primeira versão das ferramentas de GUI para SQL Server para Linux, começando com uma bifurcação do Visual Studio Code que hoje é chamado Azure Data Studio, um aplicativo baseado em elétrons que pode funcionar para todos os tipos de SQL Server, independentemente do sistema operacional.
Durante meu primeiro ano na Microsoft, trabalhando no SQL Server no Linux, aprendi muito, incluindo uma apreciação pelo gerenciamento de programas, que combina tecnologia com pensamento de negócios.
Em agosto de 2017, ingressei na equipe do Windows Subsystem for Linux como Gerente de Programa. Eu ouvi pela primeira vez sobre a WSL quando ela foi anunciada no evento Microsoft Build em 2016 como o “Bash on Ubuntu on Windows”. O vídeo do anúncio no Channel9 se tornou viral quando lançado pela primeira vez, sobrecarregando muitas das outras histórias que vêm do Build. A WSL fez uma breve menção no Build by Kevin Gallo, talvez dois minutos de todo o keynote, mas o público ficou louco e a imprensa ainda mais. Em determinado momento, a equipe do Channel9 receava que a enorme demanda pelo vídeo da WSL fosse na verdade um ataque de DDoS! Microsoft executando Bash no Ubuntu dentro do Windows foi um sucesso instantâneo.
A equipe que trabalhava no Windows Console foi a primeira a identificar a necessidade do cliente pela WSL. Quando começaram a fazer o desenvolvimento do cliente, eles ouviram repetidas vezes que as pessoas queriam algo como o Bash no Linux. Eventualmente, a equipe percebeu: por que fazer algo como o Bash quando você pode apenas fazer o próprio Bash rodar no Windows?
Não que isso fosse fácil de fazer. A criação do Windows Subsystem for Linux foi uma combinação de profundo conhecimento do Windows de uma equipe de kernel, junto com uma tecnologia da Microsoft Research chamada picoprocess. Engraçado o suficiente, picoprocessos também é a tecnologia que torna possível o SQL Server no Linux! O picoprocess hospedaria uma implementação não modificada do modo de usuário do Linux e, em seguida, a equipe do kernel implementaria correções para conectar os syscalls do Linux ao Windows. Em outros termos, o WSL possibilita a execução de binários compilados para o Linux no topo do kernel do Windows NT, sem recompilar aplicativos ou usar máquinas virtuais.
O que não escrevemos foi uma distribuição do Linux – há muitos deles por aí. O Ubuntu foi o primeiro sabor do Linux disponível na WSL: contatamos as pessoas da Canonical para ver se elas estariam dispostas a ajudar a tornar a WSL realidade. Eles estavam entusiasmados com a ideia, resultando no Ubuntu estar disponível na Windows Store. O que é uma frase muito engraçada por si só: existem versões do Linux (na última contagem, seis delas) disponíveis na Windows Store. Quantas lojas de aplicativos possuem outros sistemas operacionais?
O código que escrevemos foram os syscalls do kernel compatíveis com o Linux, fazendo interface entre os processos do Linux e o kernel do Windows. Existem cerca de 340 syscalls no Linux. A questão era qual dos syscalls implementar primeiro: como todos os sistemas operacionais, novos syscalls são adicionados com novas versões do sistema operacional, mas as chamadas antigas nunca são removidas para manter a compatibilidade com versões anteriores. Houve uma onda inicial de implementação do syscall e todo o resto foi envolvido em eventos “ainda não implementados”, para que a equipe da WSL pudesse começar a entender o que as pessoas do syscalls precisavam.
Responder a pergunta sobre o que o syscalls deve implementar primeiro significava conectar-se com as pessoas que o usariam, e era disso que se tratava o anúncio e os vídeos do Build – fazer as pessoas usarem o WSL e fornecer feedback. O local para obter o WSL era o próprio Windows através do Windows Insider Program: qualquer um pode ser um Windows Insider e obter os novos bits do WSL. Você poderia pensar que eram apenas entusiastas do Windows no programa Insiders, mas atualmente há mais de dez milhões de inscritos e eles estão interessados em todo tipo de coisas, como jogos, inovações de Bluetooth e WSL.
Um dos grupos interessados em ter o Bash rodando no Windows foi o desenvolvimento de aplicativos web que rodam em servidores Linux. O pipeline de construção inteiro de seus aplicativos seria, com frequência, uma série de comandos Bash. Além disso, se você estiver procurando por ajuda na criação de um aplicativo da Web, no Stack Overflow, a maior parte do código de exemplo encontrado será executado no Linux – e se você estiver trabalhando em uma máquina Windows para desenvolvimento, isso pode ser frustrante . Muitas vezes, a solução mais simples para um desenvolvedor da Web era migrar para um Mac e um MacOS, onde esse código é executado.
Nas primeiras duas semanas em que o WSL estava no Windows, um usuário empreendedor do WSL conseguiu obter o XEyes como um aplicativo de GUI em execução no WSL e no X11. Tudo o que o XEyes faz é desenhar um par de olhos de desenho animado na tela que seguem o ponteiro do mouse, mas todas as mídias sociais se acenderam quando a demo funcionou!
Houve muita discussão sobre como queríamos coletar feedback. O mecanismo tradicional é UserVoice, e havia um site UserVoice configurado para o WSL que tem centenas de ideias enviadas e milhares de votos. A verdadeira questão era se usar o GitHub. Como um dos primeiros públicos-alvo da WSL eram desenvolvedores da Web, o GitHub fazia muito sentido. Mas o WSL não era um projeto de código aberto – e colocar um projeto de código aberto no GitHub parecia estranho. Decidimos encontrar os desenvolvedores onde eles estavam e criar um fórum para problemas, comentários e discussões no GitHub. Desde então, recebemos milhares de problemas em vários tópicos relacionados ao Linux no Windows.
Milhares de pessoas contribuíram com problemas para o repositório do GitHub da WSL e a equipe da WSL analisa cada um desses problemas, discute-os por meio do sistema de comentários de problemas e decide o que fazer. Se houver um novo código para gravar para implementar um recurso ou corrigir um problema, ele será gravado e adicionado ao projeto WSL, que é incluído na compilação geral do Windows que é distribuída por meio do Windows Insider Program. O tempo de ciclo pode ser tão rápido quanto apenas algumas semanas.
No final, é o tempo de ciclo rápido de pessoas usando WSL sendo capazes de discutir um recurso que desejam ou problema que eles têm com a equipe via UserVoice ou GitHub que aparece nas versões Insiders que faz toda a diferença – a comunidade é parte do processo de criação da WSL.
Quando cheguei a bordo da equipe da WSL como gerente do programa, concentrei-me em levar a WSL para além do beta. As reclamações das pessoas estavam relacionadas a compatibilidade e desempenho. Mas, do meu ponto de vista, se é com isso que os usuários se preocupam, eles estão usando seu produto com seriedade; você só se preocupa com o desempenho quando está executando algo grande. Então, enquanto ainda tínhamos trabalho a fazer, foi por um bom motivo: as pessoas queriam fazer mais com a WSL e mais rápido.
À medida que os recursos da WSL começaram a se expandir, também levamos a WSL para onde os desenvolvedores estavam, e não apenas para aqueles que tradicionalmente estavam no ecossistema da Microsoft. Ir a eventos como PyCon e OSCON foram experiências incríveis: os desenvolvedores que participaram desses programas ficaram surpresos ao ver o pessoal da Microsoft lá. E quando dissemos a eles que eles estavam executando o Linux em ferramentas para desenvolvedores da Microsoft, eles estavam céticos. Eu demonstrei o SQL Server, o WSL e o Visual Studio Code nesses eventos.
Eu encontrei seu ceticismo deixando que eles experimentassem por si mesmos. E quando esses desenvolvedores começaram a executar seus próprios comandos, pequenos scripts e trechos de código, eu sempre tive uma reação enorme: “Espera, isso é na verdade Linux. Como você fez isso? Como eu não sabia disso? ”E muitas vezes chegaram à mesma conclusão, que construímos algo relevante para eles e que é bem legal.
Nós até aceitamos as reclamações sobre compatibilidade e desempenho com a WSL e lidamos com isso em uma nova arquitetura – a WSL 2. Ela fornece compatibilidade total por meio do envio de um kernel Linux no Windows e desempenho 20x. Criar a base para o WSL 2 e vê-lo ir ao ar no Build em maio passado foi uma ótima experiência. Hoje, a WSL está sem beta e até a versão 2. Você pode aprender mais no blog de anúncios.
Também trabalhei com outras equipes da Microsoft para permitir que o WSL fosse usado com seus produtos também: um grande exemplo disso foi o Visual Studio Code, que é o editor de texto mais popular para JavaScript e Node.js. Minha exposição ao código do Visual Studio começou quando percebemos que os desenvolvedores que o usam poderiam se beneficiar muito da WSL. No começo, não era uma grande quantidade de código, mas o objetivo principal era facilitar a depuração do código Node.js em execução no WSL. Os desenvolvedores podem codificar em um computador Windows que executa o WSL para direcionar uma versão do Node.js do Linux e depurá-lo nativamente do Linux.
E quando obtivemos recursos como esse trabalhando para o Node.js, isso levou a uma abundância de solicitações de suporte semelhante para C ++, Python e outras linguagens. Fiquei fascinado por essa integração e encontrei minha paixão por lá, o que levou ao meu novo papel na criação de ferramentas para desenvolvedores Linux. Agora estou me concentrando na experiência do código do Visual Studio para desenvolvedores de C ++, claro, com foco no Linux. Foi ótimo ver o desenvolvimento remoto de código do Visual Studio entrar em produção na PyCon neste ano, quando lançamos a extensão da WSL e o suporte à extensão C ++ da nova equipe.
Apesar do meu curto período na Microsoft, estou entusiasmada com a amplitude de ferramentas que ajudei a construir para desenvolvedores Linux – de bancos de dados a sistemas operacionais para IDEs. Estou animada para continuar espalhando o amor pelo Linux e criando ferramentas que impressionam os desenvolvedores em todo o mundo.
Fonte: Tara Raj
