Programando às cegas: utilizando Windows e Linux juntos para aumentar sua produtividade parte I

Salve, galera!

Este é o primeiro artigo de nossa série sobre como usar ambientes Windows e Linux juntos para uma maior produtividade em ambientes de desenvolvimento.

• parte I – Introdução
• parte II – Instalando a máquina virtual
• Parte III – Instalando o Arch Linux
• Parte IV – integrando Linux e Windows

Neste primeiro artigo sobre programação para deficientes visuais, vou trazer uma maneira consistente de usarmos o Linux no ambiente profissional sem abrir mão das comodidades do uso dos leitores de tela Windows.

Problema a ser resolvido

Por vezes, você vai trabalhar em projetos nos quais todos os desenvolvedores estão usando sistemas operacionais e / ou ferramentas inacessíveis. No meu caso, a linguagem utilizada no projeto foi Java e todos os desenvolvedores da equipe utilizavam MacOS, para o qual não existe acessibilidade em nenhuma IDE conhecida neste eco-sistema. A possibilidade de usar o Text Edit, sem completude de código, ferramentas automatizadas de build entre outros era inaceitável. Não apenas diminuiria alarmantemente a minha produtividade, como também causaria problemas de integração com o restante da equipe. A enorme falta de eficiência do VoiceOver no terminal, o que forçou o desenvolvimento de leitores de tela alternativos, como o TDSR, também era fator de risco, uma vez que não sabemos até quando esses leitores de tela serão mantidos e, de qualquer maneira, a integração entre os dois (VoiceOver e TDSR ) é bastante desconfortável.

Assim, ficou claro para mim que o MacOS não era um sistema viável para uso diário, ao menos neste cenário. O que fazer então?

Levantamento de soluções

Como MacOS não era viável, comecei a buscar por outras soluções.

Instalar o Linux

Em ambiente corporativo, nem sempre temos a liberdade de instalar um equipamento de acordo com o nosso desejo. Precisa haver uma integração de logon em determinados domínios, determinadas permissões precisam ser concedidas, determinados softwares de segurança e outros precisam ser instalados e as equipes de microinformática precisam estar confortáveis e dispostas a abrir fluxos de exceção que, ainda por cima, talvez conflitem com as políticas de segurança da organização, disposição esta que normalmente inexiste para instalações fora dos padrões que foram por elas estabelecidos. Veja, essas equipes tem lá a sua razão. Se qualquer coisa acontecer, elas responderão por eventuais falhas. No meu caso, o número de instalações Linux na empresa era rigorosamente zero … o que me deixaria com a péssima opção de mexer com metade de uma empresa na qual eu havia recém chegado para me atender em algo no qual eles não tinham qualquer experiência. Mesmo se, de maneira inédita, uma instalação Linux oficial fosse feita, ainda havia outros riscos a considerar. A pouca documentação sobre leitores de tela para Linux, principalmente para casos de uso que envolvem seu uso em conjunto com ferramentas de desenvolvimento de software, tornaria enormemente arriscado afirmar que esta solução sequer valeria a pena ser tentada. Era só o que faltava envolver um time inteiro, já muito ocupado, com a tarefa de homologar e instalar uma distro apenas para descobrir que, por causa de uma atualização tal de pacote tal, o Orca não iria funcionar com o Eclipse por causa de tal e tal justamente na distro e versão escolhidas.

Rodar o projeto no Windows

Java? Tudo bem, a linguagem é portável, As ferramentas são portáveis. Então usar o Windows, sistema já utilizado na organização para o pessoal não técnico, resolvia por si só um monte de problemas. Pessoal da microinformática apenas razoavelmente desconfortável, sistema operacional conhecido, software base instalado, imagens prontas. Estamos, portanto, totalmente resolvidos e não há mais qualquer problema, certo? Certo, até a hora em que você descobre que todo o eco-sistema do projeto é dependente de *nix. Shell scripts de apoio, imagens docker que, sabidamente, não rodam bem no porte para Windows, todas as coisas que precisarão ser adaptadas apenas para que seu processo de build / run / test funcionem adequadamente, tomando claro o cuidado de não quebrar, na adaptação, a compatibilidade com os sistemas que seus colegas estão usando. Você pensa em usar o git bash para ganhar suporte a shell scripts, pensa em versões alternativas de imagens docker, pensa em talvez instalar outras ferramentas exóticas … e olha uma infinidade de código que precisará ser mudado, coisas que precisarão ser estendidas, apenas para que uma única pessoa, no caso você, consiga usar um ambiente de desenvolvimento diferente dos demais. A esta hora, depois de tanto tempo de área, você sabe que ninguém pode, e nem deveria, parar para te explicar o que aquela linha esquisita de um script que apresentou erro no seu Windows faz. Esse script, possivelmente, foi escrito anos atrás por alguém que provavelmente nem está mais trabalhando ali. Na verdade, ninguém sabe o que ela faz nem no MacOS, que dirá a razão de estar dando pau em um sistema que ninguém nunca tentou usar, até você chegar. Você pesa todos os prós e contras e, em desespero, verifica que o Windows seria uma opção demasiadamente complexa para valer o esforço.

Resumindo

Muito bem então:

• MacOS? Inacessível.
• Linux? Impossível.
• Windows? Muito complexo.

Você se levanta e vai tomar um café aflitivo e solitário. Sabe que não pode compartilhar seu problema com ninguém e que, mesmo as pessoas bem intencionadas que se importam, tem um conhecimento de tecnologia assistiva e acessibilidade praticamente nulo, razão pela qual não podem te ajudar. Você ouve as pessoas ao seu redor e só deseja enxergar para se livrar deste peso, apenas deseja abrir sua IDE e codificar, livre como qualquer um … e se lembra de que esses pensamentos, por mais que sejam por vezes justificados, não te levarão a nada. Você ainda precisa do seu emprego, precisa se integrar a equipe e precisa colocar para fora o conhecimento que possui e que, no momento, está preso por causa de ferramentas. Seria bom, muito bom, se você pudesse usar seu Windows para escrever código e, de alguma forma, rodá-lo diretamente no Linux … Então você tem a ideia. Agradece a Deus pela inspiração e começa a elencar as premissas de como vai funcionar.

A solução

A ideia foi usar uma máquina virtual Linux para rodar o software que seria escrito usando o Eclipse e o Visual Studio Code no Windows. Instalar Linux em uma máquina virtual resolveria uma série de problemas, pois o Linux virtual, se configurado adequadamente, seria visto apenas pela máquina Windows, e, portanto, não interferiria com os demais equipamentos da empresa. Por outro lado, precisaria haver uma integração entre máquina física e máquina virtual em termos de sistemas de arquivo, para que os editores no Windows pudessem acessar os fontes de maneira transparente na máquina Linux. A parte final deste quebra-cabeças seria integrar o controle da máquina Linux de maneira mais transparente possível na máquina Windows, para que as duas trabalhassem efetivamente como se fossem uma só e rodar os scripts de build, test e outros fosse o mais simples possível. Por fim, e muito importante, usar software pirata estava fora de questão, pois isso implicaria em causar riscos para a empresa, além de ser ilegal. O Linux a ser instalado também não deveria ter interface gráfica, já que sua principal função seria a de servidor e máquina de build. Instalar uma interface gráfica seria disputar memória entre sua máquina física e virtual e, definitivamente, uma estratégia tão lenta a ponto de se tornar inviável não era o que eu queria. Mesmo assim, seria importante ter um leitor de telas instalado que funcionasse no terminal da máquina linux, para as primeiras configurações e a própria instalação do sistema.

Pacotes utilizados na solução

Gerenciador de máquinas virtuais

Que ninguém se engane: O VirtualBox está longe de ser minha primeira escolha. De desempenho sabidamente baixo no Windows, o produto aparenta, em sua interação com o usuário, uma experiência grosseira, quase como se os seus desenvolvedores não quisessem de fato tê-lo construido, mesma impressão que tenho sobre quem escreveu sua documentação. Apesar disso, ele foi a melhor opção entre os virtualizadores disponíveis. Isso porque o VMware Workstation Player, que seria minha solução preferida, não é livre para empresas e o Hyper-V, dos três virtualizadores que eu conheço, é o único a não oferecer drivers virtuais de som, o que anula a premissa de usar um Linux com suporte a leitores de tela rodando diretamente do terminal. Além disso, a maneira com que networking é gerenciada neste produto apavora qualquer pessoa que não tenha, possivelmente, participado de sua concepção. Para um data center profissional talvez esteja ok, mas não para um desenvolvedor que quer apenas instalar uma máquina virtual em uma estação de trabalho. Quanto ao Windows Subsystem for Linux (WSL), na corrente data, a versão 1 não oferece suporte nativo ao docker, o que o tira fora da jogada, e a versão 2 é só uma promessa, que traz consigo a enervante sugestão de que o Hyper-V, do qual já falamos anteriormente, deverá ser instalado consigo. Assim, com alguma tristeza, fui tentar descobrir como usar o VirtualBox. Espero, sinceramente, que este tutorial alivie a dor de quem vem pelo mesmo caminho, porque desbravar o uso deste pacote não foi fácil.

Distro Linux

Para o Linux, usaremos o Tarch, que é a continuação do Talking Arch, distribuição que oferece um DVD de instalação do Arch Linux já com o leitor de telas Speakup e o sintetizador de voz eSpeak pré configurados, através do pacote espeakup. Esta distribuição foi escolhida porque os múltiplos componentes envolvidos em fazer um leitor de telas que opera no terminal já estão configurados e, também, porque o Arch Linux é uma distribuição rápida, complexa e que não vem com um gerenciador gráfico instalado.

Acesso remoto

Para acessar remotamente a máquina virtual, optamos pelo cliente nativo SSH para Windows 10, já que sua interação com o NVDA praticamente não difere de uma interação normal com o próprio prompt de comandos do Windows.

Compartilhamento de arquivos

Aqui, precisamos escolher entre usar o próprio serviço de compartilhamento de arquivos do VirtualBox ou uma outra solução. Pesquisando um pouco, e dada a falta de qualidade na implementação, na documentação e na acessibilidade do VirtualBox, optamos por utilizar o Samba, delegando ao Linux, e não ao virtualizador, a tarefa de deixar suas pastas acessíveis para o Windows.

Na segunda parte deste artigo, a gente conta para você como fizemos nossa máquina virtual, que nos permitiu trabalhar, praticamente sem adaptações, não somente neste, mas em muitos outros projetos de desenvolvimento de software que também seguiam as mesmas características na empresa.

Artigos da série

• parte I – Introdução
• parte II – Instalando a máquina virtual
• Parte III – Instalando o Arch Linux
• Parte IV – integrando Linux e Windows

© Copyright BlindTec 2020 - 2024, todos os direitos reservados.
Para mais detalhes, consulte a página de direitos autorais do portal.