Pra mim pode ser um "redflag" se ele depender do Windows pra programar.

Sendo bem sincero nunca perguntei se um desenvolvedor utilizava Windows ou Linux durante uma entrevista. Não tem a ver com o SO. Se você decide por um desenvolvedor que ele deve usar X ferramenta ao invés de Y, há dois aspectos principais:

• Curva de aprendizado
• Disposição

O redflag está aí. Eu, como líder técnico, sempre me coloco à disposição para auxiliar com a curva de aprendizado. Mas se ele não está disposto a enfrentar esta curva, ele não vai ser produtivo, independente do SO.

Na minha equipe todos trabalhamos primariamente com Python. Não há qualquer imposição direta de ferramentas como IDE e sistema operacional.

Mas a questão é que temos uma diretriz sobre nosso estilo de código (famosa PEP-8). E para reforçar a diretriz, há uma verificação que faz parte da nossa pipeline de CI. Se o desenvolvedor não conseguir garantir um código dentro destas diretrizes, a pipeline irá falhar e o PR não prosseguirá. Não me importa muito se ele prefere PyCharm ou VSCode, Windows ou Linux, etc.

Mas se a maioria usa VSCode, e alguém decide usar o PyCharm, ele assume a responsabilidade de descobrir sozinho como configurar corretamente para que o resultado seja consistente, e acaba tirando menos proveito das descobertas dos demais. Isso naturalmente encoraja a uma padronização.

Obviamente esta liberdade de escolha depende da maleabilidade que o sistema possui em se adequar ao sistema de arquivos da máquina. Eu trabalhei isso desde quando decidimos reescrever o sistema. É mais fácil quando é pensado pra ser assim desde o zero.

Além do que você já pontuou sobre o caminho do volume, como a aplicação resolve o caminho das subpastas? Se for através de uma concatenação de string simples, pode dar ruim pois pode resultar em algo do tipo D:\\host\\path\\no\\windows/resto/do/path, ou você pode tentar fazer a separação do caminho (famoso split ou slice) manualmente levando em conta o separador incorreto. Dependendo do caso gera erros. Isso significaria ter de refatorar todo o código para usar um método programático, através de bibliotecas que lidam com o sistema de arquivo, pra formar um caminho adequado para o sistema que estiver executando dinamicamente.

Eu passei a dar mais atenção a este tipo de "detalhe" após ler o Twelve-factor App. Recomendo, e é bem curto.

Mas aí refatorar nunca é uma decisão simples, e nem sempre o melhor caminho. Leve em consideração tempo e recursos disponíveis e envolvidos na alteração, os benefícios reais que esta transição irá trazer, etc, porque como líder você deve observar antes de tudo a integridade do projeto. Não dá pra deslocar seu roadmap em 1 mês simplesmente porque 2 desenvolvedores usam Windows e se recusam a usar Linux. Diga isso em uma reunião de produto (quando não de diretoria, em último caso) e provavelmente perderá pontos com pessoas importantes/influentes.

Eu costumava colocar Linux de forma impositiva. Porém com o avanço do Docker e WSL, todos meus projetos foram pra dentro do Docker inclusive em dev, então, qual o sentido de impor Linux?

Porém, eu acho que todo dev DEVE saber usar linux entre básico e intermediário, para entender o que acontece dentro do docker, se não, a demanda acaba indo para outra pessoa que saiba.

qual é a vantagem produtiva em 2024 de se utilizar Windows

Tenho um dock conectado no notebook que apenas por uma única porta USB-C estão conectados:

• Terceiro Monitor
• Cabo Ethernet
• Mouse, teclado
• Mesa de som com mic, fone, caixa de som
• stream deck conectado na Luz (também da elgato)
• webcam

Adivinha o motivo? Não existem driver para linux dos dispositivos:

• Dock
• Mesa de som
• Stream deck e Luz
• Software de corzinha pro teclado e mouse

WSL

Hoje o WSL é a engine padrão do docker.

então se na sua configuração está

path: D:\host\path\no\windows

é porque simplesmente o projeto está instalado no caminho errado. não é problema de compatibilidade, é de usuário.

Além disso porque esse caminho não está dinâmico?

path: ./storage:/app

Docker suporta isso.

Porque usar linux

Se tenho um ambiente Windows que tem compatibilidade com todos os driver e uma máquina virtual TOTALMENTE integrada com o sistema inteiramente em linux?

SIM! Na WSL (Windows 11) funciona até plicativos graficos. Ja instalei o firefox na wsl e executei rodando na maquina virtual linux como se fosse uma aplicação windows.

colocaria Mac de forma impositiva

Você vai pagar 30k para ter um notebook com desempenho semelhante ao meu que paguei 8k? Se sim, sinta-se a vontade

Se não ajuste as configurações do projeto e ensine seus colaboradores a configurar o projeeto no local certo.

Docker resolve o problema de diferentes SOs / Hardwares.

Ele roda em tudo de forma igual. Se configrar certinho sua aplicação não saberá em qual sistema está, e isso não importa.

Tenho AQUI um docker compose que usei no WSL com todos os pontos que falei nesse post

O deploy já não devia usar variáveis de ambiente justamente pra não ter problemas com ambientes diferentes de desenvolvimento?

Ao menos sempre peguei projetos preocupados com isso, mas não conheço os possíveis impedimentos pra isso no seu caso.

Antigamente isso fazia mais sentido, mas hoje com docker e WSL é muito mais tranquilo. No momento estou com um note ubuntu meio antigo e acabo trabalhando mais no meu PCzao que montei pra jogar hahaha

Na verdade hoje em dia com o Docker e o WSL, pra quem precisa subir um aplicativo é só usar eles.

O Windows tem bem mais compatibilidade com as IDEs de programação, e elas rodam melhor no Windows e tem menos bugs que as versões do Linux.

O desenvolvedor só tem que:

• Usar as IDEs pra programar, elas rodam melhor no Windows.
• Se for pra debugar, o Linux é indiferente pois os debugs são feitos pelos códigos e pelas IDEs.
• Pra testar a aplicação, é só rodar um container do Docker.

Não faz sentido essa afirmação de que se um dev. não usa Linux ele é um red flag.

sobre o ambiente, todos rodam o ambiente de desenvolvimento com kubernetes? e porquê?

o ideal seria utilizar um dockerfile para desenvolvimento + docker-compose para orquestrar caso seja necessário subir mais de um container e os apontamentos dos volumes serem feitos de forma relativa e não absoluta isso garante compatibilidade independente do S.O.

a Questão da redflag por optar por um S.O acredito que isso não diz muita coisa, no fim cada desenvolvedor tem que que utilizar as ferramentas que vão lhe propor maior produtividade e maior compatibilidade com a stack e as ferramentas da empresa, e se ele preferir usar windows e nao comprometer os critérios mencionados anteriormente que o faça.

Não considero o uso do Windows uma preocupação ("red flag").

Pessoalmente, não acho que Kubernetes seja a escolha ideal em um ambiente de desenvolvimento. Prefiro a simplicidade do Docker Compose ou mesmo o uso direto de um Dockerfile para necessidades imediatas.

Informações confidenciais deveriam ser configuradas como variáveis de ambiente ou através de outro método mais eficaz de gerenciamento. Isso facilita a colaboração em equipes diversificadas, onde cada desenvolvedor pode escolher entre Linux, Windows ou Mac. A flexibilidade para trabalhar no sistema operacional da preferência de cada um, a meu ver, é fundamental. Além disso, diferenças de ambiente, tabulação e código podem ser gerenciadas pelo uso de um arquivo .editorconfig.

No que se refere ao C#, é sabemos que é possível programar usando apenas o VSCode. Sim, é viável, mas o Visual Studio é imensamente superior em termos de produtividade, e ele só funciona para Windows, e tem uma versão "OK" para MAC

Atualmente, meu ambiente de desenvolvimento é totalmente baseado no Windows, com integração do WSL e Docker. Algumas tarefas são executadas dentro do WSL e outras diretamente no Windows, variando conforme a necessidade de cada projeto.

A única dificuldade que encontrei até agora foi ao experimentar recursos do Docker para o projeto "Rinha de Backend". Notei que o modo de rede 'host' não é suportado pelo Windows, mesmo utilizando o WSL. Para contornar isso, recorri ao uso de Linux em dual boot.

Exceto isso, nunca encontrei grandes obstáculos utilizando o Windows para desenvolvimento.