Uma coisa que a gente aprende na escola ou universidade quando começa um curso de programação é: “Coloque comentários no seu código”.

Isso normalmente é tão mal-ensinado que você acaba achando por aí coisas desse tipo:

x = x + 1 # adiciona 1 a variavel x

Parabéns, você poluiu seu código com informação inútil e acabou fazendo ele pior do que o original.

Longe de mim dizer que sou um programador experiente, mas depois de ter a oportunidade de trabalhar em código realmente bom em alguns empregos e de ler livros excelentes eu percebi um padrão: Código bom não precisa de comentários.

Não é segredo nenhum o quanto gosto de ZFS. É um sistema de arquivos sensacional com tantas vantagens que dá até pena comparar os outros.

Infelizmente o principal problema é a licença CDDL que não é compatível com a licença do Kernel, então o suporte não pode ser colocado nativamente na árvore principal do Linux.

Isso é facilmente resolvido compilando um módulo externo e um abraço. Inclusive o Ubuntu desde o 19.10 tem suporte até a instalar o root drive em zfs. Mas infelizmente não tem opção de criptografia no boot.

Já falei de Python diversas vezes aqui no blog e meu interesse pela linguagem continua a crescer. Estou continuamente estudando, lendo livros, ouvindo podcasts e fazendo cursos.

Existe uma expressão para quando você escreve código utilizando facilidades, convenções, formatação e sintaxe típicas da linguagem: Abordagem Pythonica.

É um termo com uma escopo enorme, mas uma das coisas que gera mais discussão e rivalidade é como formatar o código corretamente.

O Python tem um guia de estilo oficial, definido na PEP8. Algumas grandes empresas também tem seu guia de estilo interno, como o Google por exemplo.

Vira e mexe a gente – sysadmins, programadores, devops, etc – precisa de um servidor web rapidinho para testar uma coisa, servir arquivos temporariamente, fazer protótipos ou provas de conceito.

Minha abordagem sempre foi para coisas mais simples – tipo servir arquivos de um diretório – subir o servidor HTTP nativo do Python:

python3 -m http.server 8000

Boom! Tá no ar um servidor de arquivos expondo o diretório local.

Mas às vezes queremos uma coisa mais complicada. Digamos que você está querendo testar uma aplicação cliente-servidor. O cliente é daqueles que exige uma conexão segura com certificado válido, mas o seu servidor de teste roda em HTTP inseguro.

“A prática faz a perfeição“, diz o ditado. Mas será que isso é verdade mesmo? Quanta gente dirige diariamente a 20, 30 anos e são péssimos motoristas? Quantos colegas você tem ou já teve com “15 anos de experiência” que são tecnicamente fracos?

Veja bem, não estou dizendo que praticar não é importante. Estou dizendo que praticar sem uma intenção ou foco específico provavelmente não vai trazer nenhuma melhora depois do aprendizado inicial.

E antes que vocês se preocupem, o post é sobre seu ambiente virtual. Mais especificamente sua linha de comando.

Se você não utiliza um console shell como seu principal ambiente de trabalho pode parar de ler aqui.

Fazem muitos anos que utilizo Linux como meu desktop tanto em casa como no trabalho. Nos últimos 10 anos devo ter tido um total de 1 ano e meio onde a máquina disponibilizada pelo meu empregador do momento era Windows. Mas mesmo assim instalei uma máquina virtual Linux e só usava o Windão pra ler email e acessar aqueles lixos corporativos que só funcionam em Internet Explorer 6.

Dando sequência aos posts relacionados à mudança de sysadmin tradicional para o cenário moderno de DevOps vou dar minha opinião® à respeito de Cloud.

Como tudo começa

O passo inicial de toda empresa migrando para Cloud parece ser simplesmente subir algumas máquinas virtuais no provedor de preferência e instalar alguma coisa nelas.

Faz todo sentido: Dá pra entender como fazer as configurações básicas, se familiarizar com o ambiente, fazer provas de conceito e testes de como migrar as coisas numa primeira fase.

Wireguard é uma VPN que foi recentemente adicionada ao Kernel oficial do Linux. É extremamente rápida, simples e com excelente criptografia, além de ser multi-plataforma.

Tem vários tutoriais por aí, mas talvez por ainda ser bem nova tive dificuldade de achar todos os passos necessários num só local.

Terminei agora a pouco a minha configuração usando meu novo router/access point baseado num Raspberry Pi 3B+ que comprei esses dias. Pastei umas boas horas, então vão aqui algumas dicas e links que me foram úteis

Comentei no post anterior que checagem de erros em bash pode ser meio complicada. Mas não necessariamente impossível. Só chata de implementar. Vamos dar uma olhada melhor como fazer isso.

Shell script tem um problema inerente à sua natureza: É, genericamente falando, uma lista de comandos. Ele vai executar todas as linhas de comando, uma após a outra, independente se o anterior funcionou ou não.
Pense nas consequências disso olhando esse script:

No post anterior comentei da minha transição de syadmin para DevOps e minha opinião sobre 3 linguagens de programação ideais para DevOps: Shell, Python e Go.

Shell Scripting

Vou começar dizendo que se hoje a sua profissão é Sysadmin eu já assumo que você sabe shell script. Pelo menos um pouco acima do básico.

Mas fazer os famosos one-liners com sed ou awk e meia dúzia de pipes não é o que eu considero suficiente para a realidade DevOps. Algo mais complexo com condicionais, loops, funções, checagem de erro, estrutura de dados e outros conceitos mais complexos é o que você vai precisar para fazer DevOps direito.