A não ser que você seja realmente uma exceção, sua barriga irá crescer ao poucos conforme você vai amadurecendo. Aquela magia da adolescência que lhe permitia comer muito mal, não se mexer muito e, ainda assim, permanecer magrão irá se dissipar e a gordura começará a se acumular (alguns até dizem que ela vem de repente, como se para compensar a adolescência magra).

Quando você começar a se sentir incomodado, sua mulher irá fazer pouco caso e dizer que “isso não é nada”. Conversa mole. É alguma coisa, sim. E se você não fizer nada, sua gordura só vai aumentar e aumentar e o problema ainda maior é que você cria barriga ao longo de muitos anos, mas quando resolve perdê-la, quer fazê-lo rapidamente — e dificilmente dá certo.

Então comece agora. Vá correr na rua. Vá para uma academia. Preparação física e músculos são saúde.

Se a série que você assiste está muito boa, é tentador ver “só mais um episódio”. Se na churrascaria continua vindo carne boa uma depois da outra, é tentador sempre pedir um pedaço, mesmo estando de barriga cheia. E o resultado da falta de auto-controle é o sono insuficiente ou a sensação de que vai explodir a qualquer momento. Nunca é algo bom.

Moderação é bom.

Ter tratamento de rei não pode vir antes de se tornar um rei. A glória de ter entrado no prédio em chamas para salvar alguém não vem se não houver dentro do homem a capacidade de entrar num prédio em chamas, quente como uma churrasqueira em brasa.

O jovem quer uma namorada pelo simples fato de ter uma namorada, mas enfrenta dificuldade porque ainda não é o tipo de homem para quem estar acompanhado por uma mulher é algo natural.

O pobre quer ter muito dinheiro, mas quando acontece de ganhar algum, logo queima tudo, porque no fim das contas ele nunca fica rico: no muito se torna um pobre com dinheiro.

Nossa frustração vem de onde, mesmo? Ah, sim: de expectativas erradas. Esperamos que ter a namorada faça de nós mais descolados (ou pior: mais felizes). Esperamos que ter dinheiro nos faça ricos. Esperamos que o poder nos dê automaticamente autoridade. E nos frustramos, mesmo tendo as coisas.

Uma pergunta que ajuda muito nesses cenários é “e depois?”. Você consegue a namorada, mas e depois? Não admira que tanto jovem seja largado depois de poucos dias. Você consegue muito dinheiro, mas e depois? Sabe como investi-lo? Sabe onde gastar? Sabe manter? Você consegue poder, mas e depois? Sem saber usá-lo, terminará apelando para abusos?

Toda vez que você pensar em ter qualquer coisa, primeiro pense no tipo de homem que você precisa ser.

There are no solutions. There are only trade-offs. (Thomas Sowell)

O mundo é habitado por homens caídos — é dos nossos corações, afinal, que procede todo tipo de mal. Por isso não existem soluções. Só o que podemos esperar são trocas: precisamos decidir qual das opções não-ideais é a melhor ou menos problemática.

E essas decisões são geralmente complicadas e imersas em debates infindáveis entre pessoas de princípios, pessoas pragmáticas e pessoas sonhadoras. Tudo é cheio de nuances, e a pergunta que sempre é cabida, quando escolhe-se seguir por algum caminho é: a que preço?, além de e qual é a alternativa?.

If you think there's a solution, you're part of the problem. Se você acha que há uma solução, você é parte do problema. (George Carlin)

Você nasceu triângulo e culpa quem nasceu círculo por tudo de ruim que acontece na sua vida? Lembre-se: você entrega poder a quem você culpa.

Você está rodeado de pessoas que constantemente falam sobre como outro grupo de pessoas é o culpado por tudo de ruim? E essas pessoas que te cercam vivem dizendo que querem “te empoderar”? Como? Como você terá mais poder se só o que conversa a respeito é a culpa alheia sobre sua própria sina? E que poder é esse? Poder sobre a própria vida? Esse poder já não lhe pertence?

Existe, nisso que você segue, alguma possibilidade de você ser simplesmente feliz? Há algo que você possa fazer que possa lhe alcançar uma boa existência hoje? Ou a essência de tudo é essa tal “luta”? Você é uma pessoa contente, feliz e satisfeita nessa luta?

Há uma porção de ideologias e “movimentos” por aí que só servem para te deixar revoltado. Constantemente revoltado. Você nunca pode estar tranquilo e relaxado, deve estar sempre enfurecido com algo, sempre com os nervos à flor da pele, sempre à beira de fazer alguma bobagem. E é assim que te dominam. É assim que, dizendo te “empoderar”, retiram de você qualquer poder e te transformam num mero soldado de infantaria, obedecendo ordens, e fazem de tudo para que você não pense muito a respeito das coisas que diz defender.

Esse é um artigo um tanto complicado de se escrever. Então, para não deixar de pelo menos publicar o essencial (porque a versão completa disso dá bem um livro), vou apresentar um resumão da coisa toda em formato de bullet points:

• “Happy wife, happy life” (”esposa feliz, vida feliz”) é sim um chavão de homem fraco.

• Nós devemos focar nossas energias nas coisas sobre as quais temos controle.
• Casamento é uma união de duas pessoas, portanto nem o homem e nem a mulher tem controle. Ambos compartilham apenas influência.
• Tentar “salvar meu casamento” é um conceito ingênuo. Devemos focar nossas energias no que temos controle.
• Você só tem controle sobre si mesmo.
• Se você não é feliz sozinho, sua esposa jamais poderá ser feliz ao seu lado.
• Você não pode fazer feliz ninguém mais além de você. E tentar fazê-lo trará o resultado oposto.
• Você não pode completar ninguém e ninguém pode te completar. Exigir que sua esposa te complete é injusto para com ela e só gerará ressentimento.
• Um homem cheio de ressentimento não pode ser um homem cheio de amor.
• Seja homem: assuma a responsabilidade!
• Focar no próprio desenvolvimento é um bom conselho, mas o tiro facilmente sai pela culatra se você esquecer que o objetivo é justamente ter a capacidade de amar sua esposa de maneira sincera, consciente e sem ressalvas.
• As “ressalvas” seriam o teu próprio ressentimento e rancor. Eliminando o ressentimento e sendo feliz consigo mesmo você consegue amar sua esposa de maneira sincera, consciente e sem ressalvas.
• Somos homens. Quando o bicho pega, é para nós que as pessoas olham.
• Não existimos para os prazeres. Devemos aprender a viver bem sem eles.
• Prazeres ou sofrimentos não são nem bons nem ruins, pois não podem nos tornar melhores ou piores.
• O cumprimento dos deveres resulta em satisfação.
• “Melhor é o que tarda em irar-se do que o poderoso, e o que controla o seu ânimo do que aquele que toma uma cidade.” (Provérbios 16:32).
• Aprenda a controlar seu ânimo! Leve o assunto a sério. Estude. Dedique-se. Trabalhe.
• “O temor do Senhor é o princípio da sabedoria, e o conhecimento do Santo a prudência.” (Provérbios 9:10).
• Pedir a Deus um corpo musculoso ou a capacidade de correr uma maratona sem o devido treino é uma ingenuidade. Ninguém acusa o que treina e se exercita de “confiar na carne”. Pedir a Deus que conserte e corrija as faculdades atrofiadas da sua alma e do seu intelecto também é ingenuidade. Buscar exercitar seus sentimentos, entendimento, discernimento, sabedoria e prudência não é “confiar na carne”. Pelo contrário: é “não tentar o Senhor vosso Deus”.
• O Senhor ilumina nossa mente e nosso coração. Deixa que se atrofiem é um desinteresse blasfemo. O homem que é grato ao Senhor trabalha dia e noite para fazer (e aprender a fazer) o melhor uso dos seus dons.
• Liderança é sobre dar direção.
• Quem não lidera a si mesmo não pode liderar mais ninguém.
• É importante descobrir seu propósito. E também é importante saber que passamos por períodos em que o propósito desvanece e ficamos à espera do próximo. (Se “propósito” soa muito forte para você, chame de “projeto”, então.)
• As mulheres não são homens. Não espere que a cabeça da sua esposa funcione como a sua.
• Não existe troca: a sua esposa só será atraída para você se você for atraente. Fazer coisas para ela (tarefas domésticas, presentes, agrados, elogios ou o que for) não funciona e é fácil dobrar a aposta e fazer ainda “mais coisas” quando ela parece perder ainda mais o interesse. Eis você gastando energia em algo que não pode controlar! Invista sua energia em você, amadureça, ame-se, desenvolva seu autocontrole e então ela se sentirá naturalmente atraída.
• Você não precisa da sua esposa para ser feliz. E esse é o único jeito de ela poder ser feliz com você. Ela não precisa de um navio levado ao vento amarrado a ela, que também é um navio: ela precisa de um porto seguro. E o porto é porto, com ou sem qualquer navio.
• A vida de um homem apoia-se sobre quatro pilares: a vida espiritual, a vida da alma, a vida intelectual e o seu corpo. Descuidar de um é viver desequilibrado. Descuidar de dois é queda certa. Você quer ser feliz? Organize-se para conseguir cuidar bem de cada um desses pilares.
• Quando você finalmente entende que o único responsável por fazer você feliz é você mesmo, verá que na verdade você sempre foi faltante e sua esposa é que foi sobejante. Assim o ressentimento dará lugar à admiração e seu amor infantil e cheio de ressalvas dará lugar a um amor maduro, consciente e resiliente.

Se você está começando agora nesse tal Kubernetes e já está naquele ponto em que seu navegador tem +200 abas abertas em materiais diversos, desde o site oficial até artigos diversos por aí, bem-vindo! A meu ver, você já pode deixar isso tudo de lado e ficar tranquilo, porque por meio da leitura deste artigo, você conseguirá ainda nesse dia de hoje (a não ser que você esteja lendo-o próximo da meia-noite, claro) adquirir conhecimento suficiente para tornar-se um profissional muito decentemente capacitado a trabalhar com essa tecnologia bacana que é o Kubernetes.

Então, por favor, leve numa boa os parágrafos um tanto mais “filosóficos” do início, porque ainda teremos uma abordagem bastante prática para deixá-lo a par e, se possível, acostumado com o instrumental todo (que nem é muito, mesmo).

0: Disclaimer

Este artigo é longo e é um esforço e tanto escrever tudo de uma vez. Ele certamente será melhorado com o tempo. Quero começar focando no que é mais essencial e ir adicionando melhorias aos poucos.

1: As dores

(Você pode pular essa parte, se estiver com pressa.)

O mais importante ao adotar uma nova ferramenta é entender e, especialmente, sentir as dores que ela promete sanar. Quando comecei a tentar lidar com Docker, por exemplo, eu simplesmente não tinha nenhuma das necessidades que a ferramenta busca suprir, então a via como algo supérfluo e, portanto, nunca me engajava realmente no aprendizado da mesma, mais ou menos como o famoso cálculo de massa molar do Ensino Médio, que por mais que o professor tente ensinar da melhor maneira possível, não passa de uma enorme encheção de linguiça e, portanto, ninguém dá muita bola ou aprende direito.

Você lembra como era antigamente? Antigamente nós tínhamos O Servidor. Não que isso tenha desaparecido (não mesmo!), mas antigamente meio que era a única opção disponível. Depois surgiram as public cloud e as pessoas demoraram a entender como usá-las e passaram muito tempo reclamando que eram caras sem perceber que estavam usando uma tecnologia nova ainda sob um ponto de vista antigo.

Eventualmente, com a containerização das coisas, surgiram outras alternativas e escalar uma aplicação horizontalmente tornou-se mais ou menos trivial, embora a configuração desse tipo de arquitetura ainda dependesse de muitos conceitos particulares de cada provedor de serviços. Configurar um sistema assim acabava sendo trabalhoso, de qualquer forma, e exigia um investimento e um certo compromisso com aquele provedor de serviços específico, o que terminava amarrando você ou sua empresa a este.

Bom mesmo é simplicidade, não? Se você tem um projeto simples, pode pegar qualquer máquina barata, como Linode ou Vultr, e instalar o Dokku, que é um software open source que busca simular uma espécide de Heroku, e passar a vida sendo feliz fazendo deploys simplesmente com git push dokku! Eu faço isso com uma porção de projetos (incluindo esse blog) e é uma experiência magnífica.

É tão legal que eu queria usar esse tipo de coisa em todo lugar! Quer criar uma nova aplicação? dokku app:create nova-app; dokku git:init nova-app e depois é configurar o novo remoto no repositório local, dar o primeiro push e pronto. Precisa de TLS? Tem um plugin para gerenciar tudo automaticamente. Precisa de um banco de dados? Tem um plugin para isso. Redis? Plugin. Precisa de um volume? Tem um comando. Quer configurar algo muito específico do Docker? Edita um arquivo, é bem fácil!

Mas existe uma limitação, e é essa dor que me ajudou a entrar a fundo no aprendizado de Kubernetes: isso tudo é limitado aO Servidor. Quer fazer isso tudo dividindo a carga entre duas máquinas? Usando Dokku? É... Boa sorte...

Então, para mim, Kubernetes é um Dokku que funciona em N >= 1 máquinas: já tem tudo meio pronto, não precisa pensar demais nas coisas e não precisa se amarrar com algum cloud provider específico. Isso tudo e mais um bônus: IaaC, ou infrastructure as code, na maior parte do tempo.

No último mês eu terminei de configurar, com Kubernetes e de maneira muito simples, um “gitops”, que é mais ou menos como eu faço com Dokku, mas sem a parte de ter que mandar um push para um remoto separado: um push no repositório de infra já faz toda a mágica acontecer e eu vejo o que anda rolando por um bot no Discord. É magnífico!

2: O que realmente importa

Para mim, a parte mais complicada e que ninguém se deu ao trabalho de explicar adequadamente foi entender, no meio de tanta coisa que há para aprender, no que realmente eu devo focar no começo e o que eu posso deixar para depois.

Veja só, Kubernetes é um conjunto de padrões, não exatamente uma implementação. Então qualquer componente do sistema pode ser implementado por quem bem entender, contanto que adeque-se às especificações, e esse componente se integrará sem problemas no “ecossistema” do Kubernetes e, portanto, para algumas áreas específicas existem várias opções de componentes e é muito fácil para um iniciante perder-se completamente nisso e ficar estancado tentando fazer uma porção de escolhas que absolutamente não são importantes (novamente: para um iniciante).

Assim, talvez a parte mais importante deste artigo seja justamente essa aqui, a parte na qual eu te ajudo a entender o que é importante mesmo e o que você absolutamente deveria deixar para depois!

As coisas com as quais você não deve se preocupar agora: * “Control plane”: eu nem sei porque insistem tanto em falar disso... Meus clusters estão rodando de boas por todo esse tempo e em momento nenhum eu parei para sequer considerar o que fosse um tal de control plane. Não perca seu tempo pensando nisso agora. * Rede: é só questão de abrir algumas portas nas máquinas que farão parte do seu cluster e pronto. * “Distribuição”: depois que as configs do seu cluster estiverem em arquivos, alterar a implementação de Kubernetes ou mudar o próprio cluster de lugar passa a ser quase trivial. * Sistema Operacional: não fique de “nojinho”, porque o sistema operacional só servirá para rodar o Kubernetes e mais nada além do bash e do vim . * Ingress: a não ser que já de começo sua aplicação tenha alguma necessidade extremamente específica e absolutamente importante, qualquer ingress serve, então não gaste muita energia comparando as alternativas, meramente pegue o que já estiver pronto para uso. * Outras implementações específicas: já vi um par de gente dizendo que “X não é Kuberntetes de verdade, porque não tem o etcd”, o que é, até onde posso ver, uma baita bobagem, porque Kubernetes é uma série de padrões e não as implementações: qualquer implementação que siga as especificações é válida. * Helm e seus Charts: não agora! Helm ajuda muito em setups um pouco mais complexos, mas ao mesmo tempo meio que tira um pouco do seu controle sobre as coisas, e se você ainda não é familiar com Kubernetes, acredito que isso possa te prejudicar, então o meu conselho é que por agora evitemos lidar com Helm o quanto pudermos.

As coisas que realmente importam: * Conceitos: diferenciar um container de um pod, diferenciar um pod de um daemonset, saber o que cada coisa faz, etc, etc. * kubectl: usar a linha de comando para conseguir entender o estado geral do seu cluster é bem importante. Eventualmente você pode lidar numa dashboard e há várias excelentes opções, mas acredito que o melhor para o aprendizado é começar digitando os comandos, mesmo. * yamls de configuração: enquanto usar o kubectl bem te mostra o estado atual do sistema, ler os yaml de configuração te mostrará o estado desejado do sistema.

Okay?

Tendo dito isso, já podemos partir para as questões práticas.

3: Os pogramas

Algumas ferramentas, como Minikube, permite que se trabalhe com uma espécie de cluster-de-uma-máquina-só-que-é-o-teu-PC. Minha recomendação: não.

Minikube e similares são ferramentas que serão muito úteis depois que você já tiver dominado Kubernetes, já tiver um cluster de produção e outro de desenvolvimento rodando e, então, quiser implantar Kubernetes no localdev da galera, para unificar as coisas. Agora no começo? Não boto fé que vão te ajudar muito.

Minha recomendação para iniciantes é o microk8s, por uma série de motivos:

1. Já empacota meio que tudo que você vai precisar;
2. Já vem com umas coisinhas extremamente úteis prontas para uso (que você só vai descobrir mais tarde, mas ficará muito grato que já estão configuradas);
3. Usa poucos recursos das máquinas;
4. É muito fácil de rodar local, mas também é production-ready.

Como eu disse antes, tem aí uma meia dúzia de gringos dizendo que “microk8s are not really Kubernetes”, mas isso é bobagem e não vai te ajudar em nada. Quer dar a eles o benefício da dúvida? Bom, primeiro faça uso do microk8s para aprender Kubernetes e em seguida procure o que quer que seja “real Kubernetes”. De um jeito ou de outro, você ficará grato por esse conselho.

Microk8s tem um drawback, porém, que é o seguinte: os desenvolvedores distribuem oficialmente somente via snap, o que meio que te amarra ao Ubuntu e seus derivados. Efeito prático? Dar um nojinho em quem não curte Ubuntu, por qualquer que seja o motivo, mas mais nada. Novamente: o sistema operacional está aí apenas para rodar o Kubernetes, o bash e o vim. Então não faz muita diferença.

E você pode usar qualquer outra implementação (eu chamo de “distribuição¨, porque meio que é o que é, mas não é bem um termo comum da literatura a respeito), inclusive porque os comandos específicos destas que você vai querer usar são pouquíssimos (e são: habilitar plugins e adicionar ou remover nós).

4: microk8s

Você não precisa de “um cluster” para começar a lidar com microk8s! Pode fazê-lo no seu próprio computador ou alguma outra máquina local (eu acho que pode funcionar de boas dentro de um container Docker e não vejo por que não funcionaria, mas nunca tentei).

Se seu cluster tiver apenas 1 nó, os pods e containers simplesmente serão executados nesse nó. E o efeito é simplesmente esse: vai tudo rodar na mesma máquina.

Enquanto isso não é exatamente o comportamento esperado de um cluster na vida real, é perfeitamente suficiente para você dar seus primeiros passos com Kubernetes, conhecer os comandos, aprender a averiguar o que anda acontecendo no cluster, etc.

Para instalar:

$ sudo snap install microk8s --classic

Na primeira execução, recomendo mandar um “wait ready”, porque pode ser que demore mais alguns segundos até tudo ficar pronto para uso:

$ sudo microk8s status --wait-ready

E para não precisar usar sudo para tudo:

# Adicionar o usuário atual ao grupo com permissão de rodar o comando:
$ sudo usermod -a -G microk8s $USER
# Atualizar a lista de grupos do usuário corrente:
$ exec sudo su $USER

5: Cluster

(Você pode pular esta parte se ainda não vai configurar várias máquinas num mesmo cluster.)

Um cluster é um conjunto de máquinas que compartilham alguma coisa. No nosso caso, chamamos cada máquina de “nó” (em inglês: node). Este nó em que você instalou o microk8s é um nó mestre (master). Você pode adicionar mais nós-mestres para ter alta disponibilidade (3 ou mais) ou simplesmente workers, de onde não se espera que o cluster seja controlado, mas simplesmente que tarefas sejam executadas.

Caso você esteja já em um “setup fechado”, em que somente as portas necessárias são abertas, a lista das que precisam estar ouvindo em cada nós está aqui:

https://microk8s.io/docs/ports

na seção “Services binding to the default Host interface”. Estas devem estar prontas para receber conexões externas.

Tendo isso pronto, você vai rodar esse comando no nó mestre:

$ microk8s add-node

E a saída deste irá indicar o comando que você deve rodar no nó que será adicionado. Leia com atenção o que está escrito ali.

Esse add-node gera um token com tempo de expiração que serve como uma forma de a outra máquina autenticar-se junto ao cluster. Se esse tempo expirar, não se preocupe, simplesmente rode o add-node novamente e copie o novo comando.

6: kubectl

A implementação do kubectl, que é o comando usado para operar o cluster, está “dentro” do microk8s, e é chamada como um subcomando deste:

$ microk8s kubectl

Mas isso é muito para ser digitado. É bastante comum criar-se um alias para isso:

$ alias k="microk8s kubectl"

Então, doravante, toda vez que você vir o comando k, considere que é microk8s kubectl sendo invocado.

O próprio kubectl tem também seus subcomandos. O mais comuns são:

• get
• delete
• apply
• logs
• events

Uma dica legal que te permite visualizar facilmente o que anda acontecendo no cluster é a seguinte: deixe o seguinte comando rodando num terminal à parte (se você usa zellij, tmux ou similares, deixe num “pane” facilmente visível).

$  k events -w

O “w” vem de “watch”: esse comando ficará mostrando os eventos que acontecem no cluster, como “baixando imagem”, “pod criado”, “pod deletado”, etc. Assim você consegue ver os efeitos de cada outro comando que rodar.

7: Pods e containers

Um container, em qualquer que seja o contexto, é basicamente “uma aplicação em execução”. Tudo bem que haja diversos processos rodando, mas, por convenção, um container representa uma aplicação ou serviço específicos.

Se você tem uma aplicação que precisa de Postgres e Redis, por exemplo, poderia rodá-la usando 3 containers:

1. Redis
2. Postgres
3. App

Mas acontece, algumas vezes, que a aplicação necessita de algum tipo de sidecar, como um coletor de métricas ou de logs. Localmente, é só questão de rodar outro container. Mas conceitualmente esses dois-ou-mais containers (App e coletor de métricas) fazem parte de uma coisa só, certo?

Por isso existe o conceito de pods no Kubernetes. Um pod é como se fosse um “lugar” onde rodam N >= 1 containers e, dentro dele, todos podem se comunicar baseados no localhost, ou seja, é como se todos estivessem na mesma máquina — inclusive por que é assim mesmo. A menor divisão do que se pode rodar em um nó dentro do cluster é justamente o pod (ou seja: dentro do pod há a garantia, de fato, que todos estão efetivamente na mesma máquina).

Então, nesse caso, App e sidecars fariam parte de um pod só, enquanto Postgres e Redis seriam pods à parte (quando não serviços externos).

E é só isso. Não precisa pirar muito a respeito. Um pod é a menor divisão inter-nós e dentro de um pod roda-se 1-ou-mais containers. Mais nada.

Para listar os pods que estão rodando no seu cluster:

$ k get pods

8: Namespaces

O legal do Kubernetes é que, apesar do que pode parecer, não tem muita mágica. Por exemplo: existe uma aplicação, que no microk8s é a tal calico, que gerencia a rede do cluster. Inclusive é por isso que eu disse antes que não precisava se preocupar com configurações de rede: contanto que aquelas portas estejam abertas, o calico cuida de fazer com que os pods consigam comunicar-se entre si.

Mas onde está essa aplicação? Oras, num pod!

Mas por que não a vejo quando listo os pods? Ora, porque seria terrível ficar vendo boilerplate o tempo todo enquanto gerencia-se um cluster e por isso o Kubernetes implementa namespaces.

Quando você roda um k get pods, está listando os pods do namespace default, que é onde você vai querer rodar suas próprias aplicações. Mas as aplicações “internas” do Kubernetes aparecerão em outros namespaces.

Você tanto pode adicionar a opção -n $namespace para ver os pods de um namespace específico quanto pode mandar um -A para ver de todos os namespaces:

$ k get pods -A

Legal, né?

9: O pod de depuração

Um dos comandos mais úteis que tenho anotado aqui comigo é o seguinte:

$ kubectl run -i --tty --rm shell --image=jrecord/nettools -- /bin/bash

O que esse comando faz é iniciar um container baseado na imagem jrecord/nettools e cujo pod se chamará shell (experimente rodar isso e, em outro terminal, listar os pods). Você então terá uma linha de comando com os comandos mais úteis para se depurar a rede e, se quiser, já fazer uns testes nos pods (e serviços) que tem rodando.

Por ora não parece muito útil, mas pelo menos você já consegue (i) rodar um container/pod baseado numa imagem, (ii) rodar testes de rede dentro do cluster, se precisar, (iii) testar a listagem de pods e (iv) ver os eventos naquela janela que mostra os eventos mencionada anteriormente (k events -w, lembra?).

Uma opção interessante para o k get pods é a -o wide. Isso faz com que o comando mostra mais coisas para você, sendo uma delas em qual nó cada pod está rodando.

No Kubernetes você *pode, mas não precisa* definir previamente em qual nó cada pod deve rodar. O que é excelente, já que do contrário você teria que planejar tudo de antemão e a própria extensibilidade do cluster seria prejudicada. Existe a opção de definir “node affinity” e outras formas de afinidade, mas por default o Kubernetes tenta distribuir os pods dentro do cluster da melhor maneira possível (ou “mais distribuída possível”, até onde percebi).

10: Serviços e Endpoints

Imagine que você tenha um serviço que ouve requisições HTTP e que esse serviço usa um banco de dados. É fácil imaginar que basta que o container exponha uma porta e, pronto, você tem um serviço rodando.

Mas o que acontece quando você quiser escalar esse seu serviço? Cada um dos 25 containers ouvirá naquela porta... e como as requisições serão distribuídas? Você vai implementar um load balancer, um proxy reverso ou algo assim?

Absolutamente não. Escalar serviços é uma prática tão comum que já existe um padrão para fazer-se isso. São os serviços.

Você pode listar os serviços rodando no seu cluster assim:

$ k get services
$ k get svc  # para os preguiçosos
$ k get svc -A  # para listar os serviços de todos os namespaces

A arquitetura de um serviço é assim: um serviço conecta-se a um endpoint, que lista N IP:porta de N pods.

Okay?

1 Service –> 1 Endpoint –> N IP:port –> Pods

Toda vez que você roda um pod que contenha algum container que expõe uma porta (imagine uma funçãozinha HTTP que ouve na porta 5000) e cria um Serviço relacionado a esse container nessa porta (imagine que você quer expor essa função na porta 80 dentro do cluster), o Kubernetes cria lá uma lista de IPs:portas para onde as requisições a esse serviço serão roteadas.

Imagine que dentro do teu sistema há um “create-user”, que é um serviço HTTP que será chamado por outros componentes. Por default, o container expõe a porta 5000. E você espera ter pelo menos 10 instâncias desse serviço rodando simultaneamente dentro do cluster. O que isso significa na prática?

• haverá 10 pods chamados “create-user”, cada um ouvindo na porta 5000;
• cada um desses pods tem um determinado IP interno no cluster;
• você vai criar um Serviço chamado “user-creation” (o nome tanto faz: eu mudei apenas para não dar a impressão de que os nomes precisam coincidir, o que não é verdade) ouvindo na porta 80;
• os outros componentes do sistema deverão chamar http://user-creation:80 quando quiserem criar usuários;
• ao criar o Serviço “user-creation”, o Kubernetes fará automaticamente uma lista de endpoints para onde roteará as requisições, sendo estes os IPs de cada pod que provê o “create-user” e suas respectivas portas.

Menciono os endpoints porque é uma ferramenta muito útil de depuração: algumas vezes eu criei Serviços que “não funcionavam” porque os containers ouviam em portas erradas, por exemplo. Um bom k get endpoints mostra facilmente se há mesmo algum endpoint escutando ou não.

Mão na massa: o yaml de um “deploy”

// TODO

ConfigMaps

// TODO

Secrets

// TODO

Ingress

// TODO

TLS

// TODO

TCP Proxy

// TODO

Volumes

// TODO

Helm

BotKube

Apesar do que a documentação pode parecer requerer, não é preciso rodar o Elastic Search para ter o botkube rodando.

https://botkube.io/

// TODO

Webhooks

• Script “apply.sh”
• apt-get install webhooks

// TODO

Uma das grandes influências de Now foi Tcl. Tcl é uma linguagem magnífica! Com relação a sintaxe, concorre fácil com qualquer outra para ser a que mais gosto.

Como concluímos, eu e um colega: “Tcl é um diálogo, não uma fórmula matemática”.

E talvez o maior trunfo de Tcl seja justamente não ter sintaxe. Os caras se apegam ao “dodecálogo” da linguagem e é isso aí. Fora aprender novos comandos, não existe nenhum momento “aha! Descobri uma parada nova na sintaxe!”, porque não usa-se sintaxe para resolver os problemas.

Voltar a trabalhar num projeto Tcl, depois de alguns meses sem mexer no mesmo, é interessantíssimo: a impressão que eu tive foi a mesma de voltar no dia seguinte. E eu nunca tinha experimentado algo assim antes!

Porém, essa simplicidade toda tem um custo: falta sintaxe, haha! Há momentos em que essa troca de simplicidade por previsibilidade faz c om que certas operações sejam previsivelmente chatas. Indexação de arrays é um bom exemplo. Extrair coisas de dentro de strings. Índices e slicing são sempre complicados, geralmente exigindo uma porção de [] aninhados.

Então uma das ideias de Now é favorecer composição linear, ou seja, evitar chamadas de comandos aninhadas.

Um exemplo da vida real:

return [clock format [clock seconds] -format %y-%m-%d]_[clock format [clock seconds] -format %H:%M:%S]

Em Now, imaginando que os mesmos comandos estivessem disponíveis, isso seria escrito assim:

list
    . [clock seconds | clock format -- (format = "%y-%m-%d")]
    . [clock seconds | clock format -- (format = "%H:%M:%S")]
    : join "_"
    | return

Como a ideia é retornar dois valores de duas chamadas de comandos, não tem muito como fugir dessas duas chamadas com []. Mas dentro dessas chamadas, pelo menos não temos aninhamento.

(Para quem não sabe, -- separa “args” de “keyword args” em Now.)

Objetos

Já é um avanço, mas não é o bastante, ainda. Repare que chamamos um mesmo comando, clock, para retornar o tempo em segundos since Epoch e para fazer a formatação. Mas ficaria mais fácil se clock seconds retornasse um objeto e format fosse um método:

list
    . [clock seconds : format "%y-%m-%d"]
    . [clock seconds : format "%H:%M:%S"]
    : join "_"
    | return

(Para quem não sabe, line continuation em Now se faz com aquele . no começo da linha ao invés de um \ horrível no fim da linha anterior.)

Veja como a chamada toda fica bem mais limpa!

O macete para ler Now facilmente é olhar tanto o pipe (|) quanto o dois-pontos sempre pensando em “o que vem antes?”. Por exemplo: ao nos depararmos com : join "_", devemos nos perguntar o que vem antes: no caso, uma chamada a list. Então sabemos que isso é uma chamada ao método join de um objeto List.

Ao nos depararmos com | return, o que vem antes? O resultado de um List : join, que é uma String! Logo, estaremos retornando uma string.

Forma alternativa

list "%y-%m-%d" "%H:%M:%S"
    | transform fmt { clock seconds : format $fmt | return }
    | collect
    : join "_"
    | return

• list cria uma lista com aqueles 2 elementos;
• transform lê de uma lista ou generator e “vai cuspindo” o que vier como retorno no SubPrograma;
• collect lê de uma lista ou generator e “cospe” uma Lista com os elementos coletados;
• join vai unir todos os elementos da lista, separador pela string passada como argumento;
• return vai retornar o que vier como input ou args.

É, pois é, a ideia é ser uma ferramenta auxiliar em projetos de software, mas no fim do dia o formato é tão legal que eu acabo usando para anotar algumas coisas que ficam bem como “dados estruturados”, inclusive quando misturados com anotações desestruturadas.

Eu mantenho minhas notas como arquivos em alguns diretórios e acontece com certa frequência que essa anotações contém dados que seguem um formato chave-valor. Não que toda a anotação seja no formato chave-valor, mas uma parte dela. E agora que o formato de um documento Now me é tão familiar, acabo sempre caindo em algo parecido com isso:

[Reunião sobre Ovo]
date "2023-12-25"
time "12:34"
participants {
    > Cléber
    > Fulano
    > Cicrano
}
topic "Decidir se ovo faz bem ou faz mal à saúde"

Ai que reunião chata, bicho...

[Notas]
> Tem pesquisa que diz que sim, tem pesquisa que diz que não.
> A turma do café sabe bem como é.
> Tem ano que faz bem, tem ano que faz mal. "A ciência muda".

[Conclusão]

Ninguém sabe de nada. Confio mais na vovó do que na turma do jaleco branco.

[Referências]
- "http://pudim.com.br"
- "https://nostr-resources.com"

Acho isso legal porque, sim, ainda vou implementar um nowdoc2markdown nativo, ou seja: se eu quiser ver isso formatado “bonito” eu conseguirei. E se quiser fazer uso desses dados para algum tipo de análise eu também consigo!

Strings

Uma adição recente à ferramenta foi o uso de > para indicar strings nos dicionários de seção (os cabeçalhos). Eu já andava fazendo anotações em Now, mas ter que ficar lidando com aspas é muito chato. Agora posso simplesmente botar o “bullet” certo e sair escrevendo sem medo.

> Isso aqui é uma string, que equivale a
- "Isso aqui é uma string, que equivale a"

Situação comum durante o desenvolvimento de software é entrar no Dilema Makefile/Shell Script. Afinal, existe sempre um conjunto de operações básicas que os desenvolvedores querem efetuar no projeto, seja rodar o projeto localmente, os testes unitários, compilar algo, análise estática, popular o banco com dados mockados, rodar migrations, pingar alguns serviços ou mesmo engatilhar um deploy. E a melhor opção para entregar isso geralmente é fazer uso do bom e velho make, que permite usar “subcomandos” (os targets do Makefile) e chamar comandos, tudo de maneira muito simples.

Repositório: https://github.com/now-run/now .

Entretanto, a partir de certo ponto isso mostra-se simples demais e logo pensa-se em criar alguns scripts shell para lidar com as tarefas que podem ser mais complexas. É questão de um for e um grep e já torna-se óbvio que escrever tal lógica dentro do próprio Makefile seria meio estranho.

E então cria-se um diretório bin/ na raiz do projeto para armazenar o diversos scripts — que nunca são apenas um ou dois, eles sempre acabam se multiplicando! Afinal, dois scripts que fazem tarefas similares sobre os mesmos dados (no caso, os arquivos do projeto, mais comandos e até processos) certamente compartilham algum tipo de configuração, certo? E aí surge o bin/settings.sh que todos os scripts devem “sourcear”. E por aí vai.

Agora alguns targets do Makefile chamam scripts de dentro de bin/ e o desenvolvedor começa a se perguntar se talvez não seria o caso de ter tudo como scripts shell — os que resistem a essa pergunta estão de parabéns. Mas implementar a funcionalidade aparentemente simples do make num script shell envolve switch/case, shift e mais alguns macetes para trabalhar com argumentos (aspas para todo lado!), o que torna os scripts auxiliares ainda mais complexos e ainda perde-se o autocomplete do shell.

Scripts auxiliares deveriam ter o nível de complexidade mais baixo possível, menor que dos testes unitários. Mas é muito fácil acabar com algo complexo ao nível do próprio algoritmo principal!

E existem, de fato, algumas ferramentas que prometem aliviar esse problema, mas eu, particularmente, nunca encontrei algo que fosse um substituto viável do famigerado make+bash.

Não que essas opções sejam horríveis. Mas sempre tem um gotcha que complica as coisas...

Now

Acontece que, eventualmente, quase por acaso, vindo de um turbilhão de ideias e outras motivações, acabou que, veja você, comecei a trabalhar numa ferramenta que chamei de now. A ideia do nome é semântica, mesmo, é você, desenvolvedor, clonar um repositório, adentrar o diretório raiz e poder dizer “agora rode”, ou now run. Ou “agora teste”, now test.

Para isso, algumas caixas precisam estar marcadas:

• O binário deve ser amplamente disponível: linux/*BSD/MacOS x x86_64, arm64 é o mínimo. make cobre o espectro todo, afinal!
• Escrever o Nowfile deve ser simples e intuitivo: nada de usar uma linguagem de programação de uso geral para um nicho como esse!
• Um arquivo apenas deve ser suficiente! Ter scripts esparramados pelo projeto acabaria sendo pior que simplesmente usar shell scripts.

Ademais, percebo um problema recorrente em ferramentas que buscam atender esses cenários que é o “tentar ser mas não sendo”. Há coisas em que um bom shell é absolutamente a melhor solução e acho importante reconhecer isso. Ao invés de competir com o shell, por que não integrar-se muito bem com ele?

Inclusive esse é o outro dilema, o Dilema Shell Script versus Python (ou Ruby ou Perl ou qual seja a sua linguagem “de script” favorita). Não demora muito para chegar o momento em que sente-se que já se levou os shell scripts longe demais e que iria bem, além de sumir com a maioria dos problemas escondidos que o shell costuma manter (pense naquele nome de arquivo que tem um espaço no final), ter estruturas de dados fáceis de usar.

Só que ler e escrever e buscar coisas em arquivos e diretórios é tão mais fácil no shell...

Só que lidar com estruturas de dados, listas, dicionários, conjuntos, etc. é tão mais fácil no Python...

E algum transeunte empolgadinho dirá “é, mas tem esse e aquele pacotes Python que permitem lidar com essas coisas de maneira muito mais fácil”, ao que eu respondo:

1. Não.
2. Não perca de vista o cenário em que estamos.

Você realmente quer um requirements.txt específico para poder realizar operações no seu projeto? Você vai exigir que todos tenham a versão certa do Python ou, o que é ainda pior, exigir que todos tenham pyenv instalado e habilitado para poder simplesmente “buildar” as imagens Docker do seu projeto???

Não, né?

Logo, boa integração com shell e programas do sistema é essencial.

O Documento Now

Uma coisa interessante de Now é que não se escreve “programas”, mas “documentos”. A sintaxe de um documento Now é razoavelmente simples:

[Meu Primeiro Documento]

E aqui vai algum texto que explique o que esse documento deveria fazer ou representar.

O texto acima é um documento Now válido. Obviamente, ele também não “faz” nada além de carregar um título e um texto breve. Mas já é o suficiente para mostrar uma parte da sintaxe.

Sintaxe

Um documento Now é composto por seções. Cada seção tem:

1. um título, como “Meu Primeiro Documento”;
2. um cabeçalho, que no exemplo acima está vazio e
3. um corpo, como o breve texto que vimos.

A divisão entre cabeçalho e corpo é como a divisão de headers e body de uma requisição HTTP: uma linha em branco, vazia, separa ambos.

[título]
cabeçalho

corpo

O título pode representar tanto um título mesmo, quando começa com letra maiúscula, quanto uma chave, quando começa com letra minúscula.

A definição de um procedimento nos ajuda a visualizar como uma seção mais “orientada a código” se parece:

[procedures/hello]
parameters {
    name {
        type string
        default "World"
    }
}

print "Hello, $name!"

Nessa seção temos um título ou chave, “procedures/hello”. O que isso significa é que o documento possui um chave “procedures”, que é um dicionário (dicionários em Now são sempre indexados por strings), que por sua vez contém uma chave “hello”, que é definida de acordo com o que vimos no exemplo.

Esta seção tem um cabeçalho. Cabeçalhos podem ser dicionários, como no exemplo, ou listas. Um dicionário-de-seção é composto por duplas chave-valor separadas por 1 espaço em branco, como em

chave valor

(A sintaxe poderia ser extremamente compatível com TOML e eu cheguei a tentar isso, mas a enorme quantidade de = no meio do documento é um negócio feio demais...)

Já o corpo do procedimento compõe um SubPrograma. Aí já não estamos lidando somente com estruturas de dados, mas com código mesmo. Now inclui uma linguagem razoavelmente simples que busca favorecer composição linear — ou seja: temos pipes!

Programando

Now oferece uma gama de ferramentas para que seu documento faça alguma coisa. São elas:

• Commands
• Procedures
• System Commands
• Shells e Scripts
• Templates

Commands

São os comandos que serão invocados pela linha de comando. Quando você chama now run, o comando chamado é run, que seria definido assim:

[commands/run]
parameters {
    # parâmetros esperados aqui
}

# code

Uma característica dos comandos é que eles só podem ser chamados via linha de comando. São entrypoints e se a ideia é criar procedimentos reaproveitáveis para serem chamados por outras partes do código, deve-se criar... procedimentos.

Procedures

Um procedimento é como uma “função”. O nome não é “função” porque um dos objetivos de Now é que você pense mais num diálogo do que numa fórmula matemática.

[procedures/md5hash]
description "Return the md5 hash of a given string."
parameters {
    string {
        type string
    }
}

obj $string | md5 | return

System Commands

Now não tenta ser um shell. Para chamar comandos do sistema é necessário “envelopá-los” numa declaração específica. Veja um exemplo:

[system_commands/find_pattern_in_file]
description "Find occurrences of a given regexp in a given file"
parameters {
    regexp {
        type string
    }
    file {
        type string
    }
}
command {
    - grep
    - $regexp
    - $file
}
which "grep"

A ideia da chave which é poder saber ahead of time se algum comando está faltando. Descobrir isso no meio do runtime é algo extremamente frustrante em scripts shell. Já a ideia de encapsular é justamente poder isolar esse conhecimento muito específico que é a magia negra envolvida em cada comando shell em um nome mais amigável e com parâmetros mais claros.

É mais burocrático? Certamente. Mas no longo prazo acredito que é algo que se mostrará útil.

Shells e Scripts

Escrever um script bash dentro de um documento Now é muito simples. Seções representando scripts seguem em seus títulos o padrão shells/$nome_do_shell/scripts/$nome_do_script.

Se o shell em si for bash ou zsh, não é necessário declarar o shell. Do contrário, um novo shell define-se de maneira muito parecida com um “system_command”:

[shells/python]
description "Python 3 shell"
command {
    - python3
    - "-c"
    - $script_body
}

As variáveis disponíveis para a definição do shell são:

• script_body
• script_name
• shell_name

“shell_name” pode parecer confuso, a princípio, mas lembre-se que você pode definir N shells com nomes distintos chamando o mesmo comando, então pode ser o caso em que diferenciar um do outro seja uma necessidade.

O script em si é bastante simples:

[shells/bash/scripts/adjust_volume]
description "Change main audio channel volume by a given number of points."
parameters {
    points {
        type integer
    }
}

amixer -c 0 sset 'Master',0 $points;

Uma parte muito legal desse sistema de scripts é que você não precisa se preocupar em como as variáveis serão “inseridas” no script, porque elas não serão inseridas no script (a não ser que você adicione expand_variables true no cabeçalho!). Aquela string que representa o script é absoluta, total e completamente a mesma string que você vê, e o que Now faz é exportar os valores dos argumentos (como points) como variáveis de ambiente, tornando o manuseio desses valores muito menos complicado.

Ou seja: quando Now chamar bash, no caso acima, já o fará exportando points, então quem faz a expansão daquele valor ($points) é o próprio bash!

Event handlers

O exemplo acima é interessante porque esse comando, amixer, espera valores no formato 1+, 2+, 3-, etc. O valor é sufixado pelo sinal! E isso pode tornar o uso do nosso system_command extremamente propenso a erros.

A primeira alternativa que viria à mente do desenvolvedor seria encapsular a chamada ao system_command em um procedure, mas Now permite ajustar-se os parâmetros em um passo separado, um evento chamado on.call.

[shells/bash/scripts/adjust_volume/on.call]

obj $points : lt 0 : then {
    # if $points is lesser than zero:
    set p ($points * -1)
    set points "${p}-"
} {
    # or else:
    set points "${points}+"
}

Usando um procedure como exemplo (só porque o corpo é escrito na mesma linguagem), você pode pensar nesses event handlers dessa forma:

[procedure/p]
parameters {
    x {
        type int
    }
}

`on.call` é chamado aqui!

O corpo do procedimento

`on.return` é chamado aqui

Se ocorrer um erro, `on.error` é chamado.

Os event handlers, exceto on.error, compartilham do mesmo escopo que o procedimento ou comando. E funcionam da mesma forma tanto para comandos, procedimentos, system_commands e scripts.

Dessa forma, o que shells/bash/scripts/adjust_volume/on.call faz é ajeitar o valor de points para que o script em si possa funcionar da maneira esperada (5 -> 5+ e -5 -> 5-).

Templates

Esse tópico merece um artigo à parte, mas segue um breve exemplo:

[Now Document Example]

Show how the document syntax works.

[templates/html_base]
description "Basic HTML structure."

<html>
<head>
    <title>$page_title</title>
</head>
<body>
    % body %
    BODY
    % ---- %
</body>
</html>

[templates/htmls]
description "Display a list of files in HTML format."
extends html_base

<div class="files-list">
% body %
    <h2>Files in $directory</h2>
    <ul>
    % file %
        <li>$file</li>
    % --- %
    </ul>
% --- %
</div>

[commands/run]
description "Show how templates work."

template htmls (page_title = "Directory Listings Example") | as tpl

list "/home" "/opt" | foreach directory {
    obj $tpl : emit "body"
    path $directory : glob "*" | foreach file {
        obj $tpl : emit "file"
    }
}
obj $tpl : render | as rendered_template | print

Resumo

Na data em que esse artigo foi escrito (2023-05-14), Now nem está contando número de versão. Mas a linguagem em si já está bastante estável e as principais funcionalidades também. A ideia é ir aumentando os casos de uso para encontrar corner cases que precisem de ajustes, mas sem adicionar nada novo.

Além disso, é necessário documentar os comandos. Para conhecê-los, hoje é necessário ler o código fonte ou os exemplos que estão no repositório.

Mas, de qualquer forma, já é possível compilar localmente (basta ter o gdc instalado) e ir testando, se quiser.

:–)

Hey, dear friend! So you was invited to visit my sweet home, huh? That's great! I'm sure we're going to have a great time!

There's some important points, though, that would be really neat if you knew them beforehand:

I live in a house

It's not that big but it's also not that small. All the floor is paved, so there's no grass or dirty anywhere, except in our plant pots — we cultivate some vegetables and greens “vertically”.

There's a small salon in the back where we receive our victims. I mean, visitors! Again, it's not that big, but it's also not that small.

Without a doorbell

Nowadays we're all connected and communicating all the time, but if you're already here and I didn't realize that, you'll have to clap.

(You know clapping? Do other cultures have this? Is it a possibility that you may have no idea on how to clap-as-if-it's-a-doorbell?)

(Well, you can also call my phone...)

I have 3 dogs

Two of them are big and one is what I personally consider medium-sized.

Remember I said there's no grass in my land? Well, it may happen that one or more of the dogs pooped somewhere in our patio in the meantime we were receiving you, so I hope you're not that sensible about that.

If you are: sorry about that.

We have a dog-lock.

You know what an airlock is? Well, we have two gates in our house and they serve as a dog-lock: they should not be open at the same time so that our dogs don't go astray.

So, you enter the exterior gate, we compliment each other, exterior gate is closed, I open the interior gate and the dogs go crazy.

The twins

Rufus and Dollar, that we call “the twins”, are basically the same thing: they will bark at you at first, but will soon realize you're not strangers from outside, but visitors, and then they'll try to hug you and sniff you all around and simply be the happier creatures in this planet because of your presence. Seriously, they now love you.

But they're still big dogs (Labrador and golden retrievers). And they'll be anxious to demonstrate their now-unconstrained love, but don't feel bad about showing them some limits! And don't worry: that's how it works in dog world, so they won't love you less because of that. On the contrary: on top of love, it'll add some respect.

Nice, huh?

For instance: it's not okay to jump on you and you can restrain them from doing so, both by using your hands and by saying an authoritative “no!”. If you're bringing things in your hands, pay special attention to that behavior!

Actually, the ideal behavior for visitors is to not take the dogs as a big deal. Ignoring them can feel weird or even disrespectful, somehow, but if you ask dog owners (at least those who understand the basics about dogs), they'll confirm this: best scenario is visitors being calm and focused on others things than the dogs, so that their “hyperventilation” probably won't scale up.

It's not mean. We, the owners, are supposed to do the same. Look for “separation anxiety in dogs” to know more.

(Anyway, you'll have plenty of time to pet them, later.)

Simba

Simba is a wonderful dog. He came originally from a shelter, adopted by one of my wife's aunts. Another aunt took care of him when the first one moved to the USA. And then he ended up in our home. “Temporarily” at first, but after some time we simply couldn't let the little guy go.

The thing is: we're not sure if he wasn't mistreated somehow in the shelter or before he was... found? Or born? His origins are uncertain. But we know for sure he's very wary of strangers and other animals. Actually, he'll be reasonably comfortable with other animals much earlier than with other people...

Therefore, he'll bark. A lot.

And that's why he'll much likely be locked in some room when you first come: it's enough for him to have visitors around, imagine adding all the commotion the fully-energized twins are going to create on top of that!

Simba will be barking a lot and it might be that he'll look aggressive, but he's probably more afraid than full of hatred as it may seem. And that's why it's important that you know that staring into a dog's eyes is a sign of a challenge. You'd be basically saying “I want to fight you”.

Never make direct eye contact with an possibly-aggressive dog. You can look at them, but as soon as they bark at you or look at you, the best thing to do is to look away, possibly lowering your head. That is a sign that you are not a threat to the dog, that you are not challenging him and that you are actually harmless.

Harmlessness is key. If a dog seems aggressive, do not try to pet him, do not stare directly into his eyes, do not move in a way that may make you look threatening. Be calm, look away, prefer a body language that shows harmlessness instead of “confidence”.

(I'm not saying Simba will certainly be wandering around all the time. I have some portable fences, here, so it may be that I'll simply isolate our little friend in the garage or something. We have enough space for that.)

(Besides, he's not that aggressive, but he struggles with accepting new people.)

The two-steps protocol

So, about the dogs,

1. You meet the twins / They get used to your presence.
2. Simba meets you / He'll bark a lot. Maybe he'll get used to your presence too.

If you're bringing your own dog

If it's a sociable animal, the protocol is the same as above. But depending on how obedient-or-not your dog is, it may be a good idea to keep it leashed while Simba first appears.

If your animal pees or poops in our patio: no problem at all. Don't feel embarrassed, we'll be actually content that he/she is relieved here and not in your car, later. I'll clean it up myself and that's how I prefer that things go, since it's easier and I'm so used to doing that.

If that happens inside the house or salon: it's not a big deal. We also have dogs, we are used to these “accidents”. Just try to make sure nobody's stepping into that and we'll quickly fix up everything.

The end

And that's pretty much it! See you there! I mean, here.

/etc/udev/rules.d/50-bluetooth.rules

ACTION=="add", SUBSYSTEM=="input", ATTRS{uniq}=="<keyboard-mac-address>", RUN+="/home/cleber/bin/on-bt-keyboard-connected.sh"

Preste atenção ao <keyboard-mac-address>. Você pode vê-lo usando o comando bluetoothctl:

$ bluetoothctl
[prompt] devices
Device F4:73:xx:xx:xx:xx Keyboard K380
Device 2E:D6:xx:xx:xx:xx Philips TAT1215

bin/on-bt-keyboard-connected.sh

#!/bin/bash

export DISPLAY=:0.0

(
    sleep 2.5
    su -c 'xmodmap /home/cleber/.Xmodmap' cleber
    # su -c 'command' user
) &

O sleep é necessário (pelo que entendi) porque o Xorg demora um pouco para “carregar” o teclado depois que o mesmo é detectado pelo udev.

~/.Xmodmap

No meu caso, eu mapeio o CTRL para a tecla Caps Lock, enquanto o Caps Lock mesmo vai parar na right-CTRL.

$ cat ~/.Xmodmap 
remove Lock = Caps_Lock
keysym Caps_Lock = Control_L
add Control = Control_L
remove Control = Control_R
add Lock = Control_R

Hoje bloqueei um determinado CTO no LinkedIn. É fato que eu não economizo blocks, mas dessa vez o motivo foi diferente do clássico “esse cara só posta bobagens sem conteúdo disfarçadas de grande conteúdo”.

Esse colega trabalha numa empresa que faz um trabalho bem interessante e, pelo que vi, talvez poderia contribuir muito com insights legais sobre as tecnologias que usa. Entretanto, seu desequilíbrio emocional acabou fazendo com que suas últimas postagens fossem todas bastante tóxicas, o tipo de coisa que faz com que você se sinta meio estranho quando lê, mais ou menos como quando dois amigos seus brigam bem feio, você não tem muito como ajudar e acaba só observando e se sentindo meio estranho.

A coisa toda começa com uma postagem a respeito de uma personagem que recebeu uma proposta de emprego em uma empresa legal, com bom salário e tudo o mais. O sujeito recusou porque preferia a liberdade de “dirigir Uber”. E o CTO Desequlibrado chegou a comentar que considerava “ser motorista de aplicativo” uma forma de empreender.

Não sei se concordo totalmente, não sei se discordo totalmente, e é exatamente isso que torna a coisa toda “food for thought”. Achei interessante, me fez pensar em algo novo, dei like.

Mas acontece que, em seguida, alguém comentou a respeito da questão salarial. Obviamente, uma desvirtuação completa da discussão, já que era claro que o rendimento com Uber seria menor que o da vaga de emprego e isso era justamente “o tempero” da história toda. E tal comentário foi feito daquele jeito agressivo que muita gente tem quando está no teclado, e que em muitos casos jamais teria se fosse uma interação face a face.

E aí começam os problemas. A resposta do CTO foi sobre o motorista ganhar “mais que você, menos que [sei lá quem|acho que era o Elon Musk]”. Houve réplica, e a tréplica do CTO, por sua vez, foi “eu sei a média salarial da empresa em que você trabalha e você ganha pouco mesmo” (ou algo assim, escrevo de memória).

Vê? Eu já me sinto meio mal só de repetir esse tipo de interação.

Mas a gota d’água foi quando esse mesmo CTO estava sendo incomodado por alguma pessoa, sabe-se lá quem, e resolveu postar que entrou no perfil da figura, viu que ela postava críticas a um monte de gente, adjetivou a pessoa de “perdedor” e a essência do post era “vi que não vale meu tempo”.

Mas, ué!, não vale teu tempo mas você teve todo esse trabalho e ainda terminou escrevendo uma nova postagem no LinkedIn a respeito do cara?

Eita.

Peralá, peralá… blocked!

---

É claro, eu admito que não sou perfeito e não é a minha própria suposta “elevação espiritual” que serviria como parâmetro para analisar esse tipo de situação. Mas sei que posso contribuir um pouco contando sobre minha própria experiência.

Sempre me expressei internet afora, geralmente via texto, e admito que não sou exatamente a pessoa mais sensível e delicada do mundo. E, se isso é verdade hoje, imagine há mais de dez anos!

Pois eu fui aprendendo, bem aos poucos, às vezes tomando pancada, às vezes vendo o belo exemplo de outros, a tomar mais cuidado tanto com meu equilíbrio emocional quanto com minha forma de me expressar.

A regra de ouro, desde algum tempo, tem sido a seguinte:

1. Você pode ficar furioso. Não tem problema. Curta seu momento de fúria.
2. Só não tome nenhuma atitude enquanto sua cabeça não esfriar.

Obviamente, isso pode ser um desafio e tanto. Mas é sábio. Tomar decisões “com o sangue fervendo” é a pior coisa que pode-se fazer, pois a raiva e o desequilíbrio em geral fazem com que nossa racionalidade saia pela janela para ir tomar um sol no quintal e voltar só depois de algum tempo, geralmente algumas horas.

Depois, é importante tomar muito cuidado com a adjetivação pessoal. Referir-se ao próximo como “perdedor” é um sinal de tanta coisa errada no coração da figura que eu nem sei por onde começar… Mas é evidente, acredito eu, que esse é um caso clássico em que “o problema não são os outros, mas você mesmo”.

E, claro, “tomar cuidado” não é o mesmo que “nunca faça”. Cá estou eu, por exemplo, referindo-me a uma pessoa como “o CTO Desequilibrado”. E garanto que tomei muito cuidado ao escolher esse “título”. No fim das contas, me parece bem adequado, especialmente porque transmite um pouco de reflexão pessoal tanto para mim (pois eu mesmo sou um CTO, então é só mais um passo para eu perder a linha e tornar-me eu mesmo um “CTO desequilibrado” também) quanto para você, leitor (que espero que esteja refletindo a respeito, pensando se você mesmo, de vez em quando, não dá uma de desequilibrado também).

Além disso tudo, uma regra que tenho adotado é a de evitar ao máximo postar qualquer coisa que não sirva para construir. Se eu estou me sentindo de alguma forma e quero expressar isso, tenho me acostumado a perguntar a mim mesmo: “mas isso edifica quem vai ler?”.

Particularmente, acho que os perfis mais interessantes em qualquer rede social são justamente aqueles nos quais eu percebo que tem um filtro bem rigoroso sobre o que será postado. De certa forma, é como aquele personagem mítico genérico (pelo menos na minha cabeça) que passou os últimos vinte ou trinta anos sem falar uma palavra, mas hoje resolveu dizer algo. É de se imaginar que alguém assim vai falar algo que seja extremamente relevante, não? Pois é. Tem gente que só se manifesta para falar algo que tenha valor e nada mais. E esses são os meus perfis favoritos.

E, enfim, mesmo que isso tudo seja coisa que você já sabia, acredito que sempre é bom rememorar essas ideias que nos ajudam, de alguma forma, a sermos pessoas que edificam mais do que destroem. Acho curioso aplicar o famoso ditado (de autoria difícil de precisar) a essas questões pessoais:

O preço da liberdade é a eterna vigilância.

---

Este artigo foi escrito originalmente em 16/06/2019.

Nesse artigo escreverei pouco ou quase nada e, ainda assim, o conteúdo valerá por mais que mil palavras:

Raio X

Resumo

• Às vezes é melhor aprender a usar Lynx, Elinks e/ou w3m.

---

UPDATE: ou partir para Gopher ou Gemini.

---

Este artigo foi escrito originalmente em 29/12/2019.

Sempre achei o modelo de negócios do Medium a própria receita do fracasso: vender gelo para esquimós. O que me levaria a pagar para ler algum artigo quando vivo num mundo com milhões de vezes mais artigos do que é possível um ser humano ler, a respeito de todos os assuntos imagináveis?

“Ah, não pago para usar o Medium, agora ficarei sem saber como construir minha marca pessoal sem gastar dinheiro…”

O site até te permite ler um punhado desses artigos antes de te impedir de ler outros. E, para quem ainda não reparou, os artigos atrás do “muro de pagamento” são marcados com aquela estrela logo após o “18 min read”, que eu chamo de Estrela da Morte, pois ela acaba marcando, basicamente, a morte do artigo.

Existe até uma extensão para Firefox chamada “Medium Free” que serve para eliminar da listagem os artigos pagos:

Medium Free Firefox extension

(Usei por muito tempo e funciona bem.)

Blogar versus escrever artigos

O Medium foi, certamente, um grande acerto por parte de seus idealizadores, e pouca gente tem falado da grande inovação apresentada sem que ninguém realmente percebesse com clareza: foi trazido à tona um novo nicho, que ou não existia ou vivia sufocado no meio de outro, completamente diferente, que é o nicho da “blogosfera”.

A palavra “blog” tem como origem o “web log”, ou “registro na web”, que seria uma espécie de diário virtual público que uma pessoa manteria, como uma “linha do tempo” própria, antes mesmo de as redes sociais “orientadas a timeline” ganharem a força que tem hoje. E a mentalidade por trás de um blog é diferente da que hoje move o Medium e sites similares. No blog as coisas tendem a ser mais pessoais e menos “editoriais”, digamos assim.

Não que seja impossível, impróprio ou mesmo incomum manter um blog com a ideia de escrever artigos mais parrudos. A questão que trago, aqui, é que há, de fato, duas mentalidades distintas, quais sejam, “blogar” e “escrever artigos”, e estas duas acabavam misturando-se com pouca distinção uma vez que as ferramentas e plataformas que serviam para um propósito acabavam servindo também para outro, de forma que a amálgama de ambas acabava servindo para preterir um pouco o “escrever artigos”.

Sim, a linha é muitíssimo tênue, mas um experimento mental interessante é tentar trazer para dentro do Medium um “blogueiro” tradicional e perceber que as coisas funcionam de maneira distinta, aqui, e que o conceito de blog não se traduz automaticamente para uma Publicação do Medium.

Logo, essa foi a grande jogada do Medium, a meu ver: focar em escrever e ler artigos e não em tentar ser uma plataforma de blogging.

Além disso, escrever no Medium é uma experiência muito boa. Navegar por ele, especialmente no começo, era extremamente agradável.

“Temos API”

Mas o que me fez vir de vez para cá foi a promessa de que “temos uma API”. Tendo já migrado de diversas plataformas para diversas outras, conseguir extrair todos os meus artigos de maneira sã era uma grande necessidade.

Todavia, não passava de uma grande mentira. A API do Medium é um lixo e não há um endpoint específico para baixar seus próprios artigos em formato decente, tendo-se que recorrer a tricks mal costurados sobre o feed RSS. Enviar um artigo via API é mais tranquilo, mas é muito difícil conseguir fugir de ainda precisar abrir o editor e corrigir um problema ou outro de formatação.

E esse foi o primeiro grande desrespeito do Medium. Eu entrei achando que não ficaria preso. E, no fim das contas, deu bastante trabalho salvar em outro lugar todos os meus artigos.

Outros problemas

Mão de ferro em potencial

Por algum tempo, inclusive, rolou uma conversa de que a equipe por trás da plataforma tentaria colaborar com a melhoria do mundo (olha só) decidindo quais artigos eram bons e quais eram maus.

De acordo com quem?

De acordo com os californianos, claro.

Mas acabou que a moda do momento em questão passou e me parece que acabaram não implementando nada, mesmo.

Modelo de negócios bizarro

Nunca entendi como uma empresa esperta o suficiente para trazer o Medium à vida foi besta o bastante para tentar monetizar via paywall.

Eles ganham dinheiro? Provavelmente.

É um bom modelo de negócios? A meu ver, absolutamente não.

Futuro incerto

E esse modelo de negócios estranho, que inclusive me soa como uma medida desesperada (eu lembro que ficaram bastante tempo tentando decidir como monetizar a plataforma), me faz pensar que logo chegará o dia em que alguma “gigante” comprará o Medium e, a partir daí, sabe-se lá o que acontecerá com a plataforma.

Layout que não para quieto

PARA DE MEXER NO LAYOUT DO SITE, MEDIUM! Credo! Tá com formiga na bunda, que não para no lugar?

Palminhas

Antigamente havia um botão para indicar que você havia gostado de um artigo. E lá pelas tantas o Medium mudou para o sistema de palmas, com um algoritmo bizarro, extremamente duvidoso e, acima de tudo, meio inútil: a única diferença que existe, mesmo, é entre 50 palminhas e qualquer-coisa-menor-que-isso, algo que poderia ser feito meramente com uma ação “gostei” e outra “gostei muito, parabéns”.

Descentralizar não é a solução

Por algum tempo eu pensei que a solução para esses problemas estivesse em tecnologias de publicação descentralizadas. Mas hoje vejo que seria como usar um canhão para matar uma mosca. O problema não é o modelo cliente-servidor tão comumente usado, mas simplesmente a falta de respeito com o usuário e, especialmente, os modelos de negócios baseados em dados e propagandas.

Afinal, tratando-se da publicação de artigos, qual é o problema inerente dos modelos cliente-servidor? Apenas a possibilidade de o servidor sair do ar por qualquer motivo. O restante é tudo questão da atitude dos donos das plataformas. “Não ser dono do próprio conteúdo” não é um problema causado por limitações tecnológicas, mas simplesmente porque a equipe responsável resolveu que não implementaria um jeito simples para que os autores pudessem baixar seus conteúdos e mantê-los onde acharem melhor.

A solução, então, é simplesmente ter a atitude certa e respeitar os autores.

“Justiça com as próprias mãos”

Já me aventurei antes tentando criar uma alternativa viável e própria, mas acabei errando em alguns pontos cruciais (e jogando tudo fora). E isso é ótimo, porque dessa vez vou focar em cometer apenas erros novos.

Estou desenvolvendo uma plataforma alternativa novamente, dessa vez escorado em alguns princípios bem básicos:

• Respeitar o autor.

(Eu ia escrever mais itens, mas todos acabam sendo um desdobramento do primeiro.)

Num próximo artigo falarei mais a respeito. Até.

---

UPDATE: criei, usei e larguei mão, já. :–)

---

Este artigo foi escrito originalmente em 04/01/2021.

Talvez o maior desperdício da minha vida, assim como da vida de um exército de desenvolvedores, foi dedicar tanta energia em desenvolver e publicar e manter e jogar fora e refazer e republicar essas porcarias dessas “web applications”. A web tornou-se a maior prova da estupidez humana e a cada dia que passa esse buraco negro está sugando mais jovens cheio de energia e faltos de entendimento das coisas nessa dança de marionetes em direção ao Grande Ciclo do Vazio, em que tudo o que é feito hoje será desfeito amanhã e no qual a busca pelo jeito certo de fazer os “sistemas web” é eterna, sendo que nunca poderemos alcançá-lo, simplesmente porque começamos de um jeito completamente errado.

Just like the Pied Piper
Led rats throught the streets
We dance like marionettes
Swaying to the Symphony of Destruction!
  -- Symphony of Destruction do Megadeth

[Nota: esse artigo é um “rant”. Ele é negativo e reclamão, mesmo, e embora possa ser, sim, construtivo, não é seu propósito terminar com uma lição para a vida ou uma sugestão de como as coisas podem melhorar. Escrever “rants” é uma espécie de arte, assim como escrever crônicas. Aprecie o texto pelo que ele é e não ache que estou ralhando com você ou algo assim.]

Tudo vira lixo: um estudo de caso

No princípio havia o Unix e um cara, talvez o Rob Pike, talvez o Ken Thompson, talvez os dois, disse que “tudo é um arquivo” e que “faça uma só coisa e faça com perfeição”. Mas isso não foi o bastante para combater a gana desenvolvedora dos jovens programadores que acham que quanto mais código escreverem e quanto mais “funcionalidades” puderem socar dentro de um programa, mais legais eles serão.

Que diabos, leia o manual do raio do comando cat em qualquer distro Linux e você entenderá o que eu quero dizer.

O RAIO

DO

COMANDO

CAT

O que essa desgraça deveria fazer? Ler um ou mais arquivos e “imprimir” na tela. Só isso. Só precisa abrir os arquivos na ordem que o usuário passou e ir jogando tudo na tela do raio do terminal. Ok? Podemos fazer isso?

Não.

Não podemos fazer isso.

Um belo dia um miserável, provavelmente na faixa dos vinte e poucos anos, resolve que não, “só” abrir um raio de um arquivo não é suficiente. Essa peste decide que o cat ficará muito mais “irado” e muito mais “sinistro”, quiçá mais “supimpa” se, além da tarefa mais trivial do universo, que é abrir uns arquivos e imprimir o conteúdo deles na tela ou na impresso ou no que quer que seja a saída padrão, ele também numere linhas.

Mas só se você quiser, claro.

Ou suprima linhas em branco repetidas.

Mas só se você quiser.

Ou imprima um '$' no fim de cada linha.

Mas, veja só, só se você quiser.

É um verdadeiro favor que essa criatura fez para a humanidade. Se antes o cat tinha 50 linhas, agora ele tem 250. Olha que maravilha!

Obrigado, jovem. #todosaplaude

Unix é lixo

Não fosse essa leitura, talvez você nunca ficasse sabendo da triste verdade sobre o tão amado Unix: foi uma ideia bacana que gerou um “produto” legal, mas o Unix é o equivalente da “V1” que serviu para alavancar a empresa e que hoje serve uma porção de clientes mas que acaba tão miseravelmente arraigada que obriga a equipe de desenvolvimento a conviver com ela por um tempo muito mais longo do que todos gostariam, mesmo que todo mundo saiba o quão problemática ela é e quantas decisões erradas foram tomadas no passado e quão melhor será a “V2” que nunca consegue deixar o papel e, mesmo que seja o caso, dificilmente vai ao ar oficialmente porque sempre há algum empecilho no caminho.

Empresas já faliram por tentar botar a “V2” no ar.

O Unix não foi sempre um lixo, assim como o cat nem sempre numerou linhas (mas só se você quiser!). O Unix era elegante e simples por algum tempo, até que algum jovem (pensem, humanos: o BSD é coisa de universidade! Certamente algum garoto meteu a mão nele) resolveu criar os “maravilhosos” sockets.

Ora, qual é o problema dos sockets? Simples: um socket não é um arquivo. Você não “lê” de um socket, você “recebe”, assim como não “escreve”, mas “envia”.

Você consegue listar sockets com o comando ls? Não. Você consegue estatísticas sobre os sockets abertos com cat /proc/net/tcp ou cat /proc/net/udp. Mas sockets não são arquivos.

E depois (ou antes) implementaram sinais. E você pode não conseguir perceber, porque essa situação caótica tornou-se o “normal” para você, mas como uma bola de neve descendo um ladeirão branco, uma coisa levou à outra e hoje o kernel Linux tem mais de 400 syscalls.

E os *BSD não estão assim muito melhor, não.

E quando aparece alguma “maravilhosa inovação” como o controle de “capabilities”, #todosaplaude, certo? Porque é bom, certo? É ótimo, mas nunca será nada mais que um chuncho, uma baita enjambração, porque se tudo fosse o raio de um arquivo ninguém teria que ficar criando uma syscall atrás da outra porque o bom e velho sistema de permissões de arquivos resolveria tudo de maneira simples e eficiente.

Lembra dele, o chmod? Pois é. Já pensou que ao invés de ficar configurando CAPS você poderia liberar ou bloquear tudo o que um programa e seus filhos podem fazer só usando chmod?

Mas, não, assim não é bacana, certo? Simples demais. Pra que facilitar se podemos dificultar?

A web é lixo

Aqui perto de casa tem uma panificadora movimentada que dá de frente para uma rua com largura para somente três carros. E não há faixa amarela proibindo estacionar em nenhum lado. O resultado é que estacionam de ambos os lados e resta somente a lacuna central para se passar com o carro.

Tudo bem: não há sinalização, então ninguém está errado.

Mas frequentemente um ou outro espertinho, andando pela lacuna central, percebe que do lado certo para ele estacionar, ou seja, à sua direita, não há vagas, enquanto à sua esquerda, ou seja, na contra-mão, há uma ou outra vaga. E o que o triste faz? Estaciona na contra-mão.

E eu sempre fico tentado a parar do lado do veículo de uma dessas figuras e dizer: “ei, tá estacionado errado”. A pessoa vai achar que o carro ficou torno na vaga e vai ou tentar “consertar” ou dizer que “não está errado”.

“Meu filho, se você para NO RAIO DA CONTRA-MÃO, você NUNCA estará estacionado certo.”

A web está na contra-mão. E é por isso que nós, “desenvolvedores web” estamos literalmente patinando nesse ofício lascado como um exército de Sísifos empurrando suas pedras até o topo da montanha, apenas para que elas rolem novamente até o chão no dia seguinte.

“Ah, mas eu uso Javascript moderno, não essa tralha do passado [literalmente: do ano passado] que você insiste em continuar usando”, um diz para o outro, sem perceber que todas as pedras são do mesmo tamanho, no mesmo formato e com o mesmo peso, e só o que muda são as luvas que cada um usa.

É triste ver a baderna que nós criamos. Diabos!, nós ficamos a toda hora reimplementando sistemas de autenticação. Nós nos reunimos para discutir o melhor formato de armazenamento dos dados. Que são meio que os mesmos dados de sempre, só que agora temos mais uns campos apontando para outros elementos “do sistema”.

Nós temos essa sensação de que as pessoas só usarão nossos sistemas se eles forem bonitos e com “uma UX maravilhosa”, sendo que só o que as pessoas querem é que tudo funcione com o mínimo de atrito possível.

Mas a cada dia que passa incontáveis Joules são gastos reimplementando as mesmas porcarias de sempre, que são erradas por natureza para começo de conversa. Você já viu quantos clones do Trello existem por aí?

Você já tentou contabilizar todas as coisas que o seu navegador, que é um programa só, faz? Você nunca se perguntou por que a “filosofia Unix” é tão bonita em escala pequena (como o cat) mas parece nunca ser aplicada em maior escala?

O código fonte do Firefox é monstruoso. E vergonhoso.

O repositório dessa infâmia demora meia hora para ser clonado. E é capaz de haver mais linhas de código no Firefox do que no kernel Linux — que é outro monstro absurdo, diga-se de passagem.

(E por que alguém, em sã consciência, resolve usar mercurial? Eu só quero clonar o tal repositório e essa parada já está tentando me convencer a usar um tal de fsmonitor, sem o qual ele admite ficar mesmo miseravelmente lento.)

...

(E agora o dito cujo está sugando toda a memória da minha máquina. É inacreditável: o mercurial está gastando mais memória, nesse momento... do que o Firefox!!!)

Olha só, encontrei outro software para odiar. Bem-vindo à família, mercurial!

Vocês sabe quantas malditas linhas de código esse projeto infernal tem? É, você percebeu que eu fiquei [ainda mais] alterado nesse ponto, porque já faz quase 10 minutos que eu botei um cloc (“count lines of code”) para rodar e o dito cujo ainda está tentando contabilizar quanto lixo tem nessa pilha gigantesca.

Mas, veja bem, eu sou um usuário do Firefox. Eu realmente aprecio tanto o navegador quanto boa parte do trabalho da Mozilla. Pelo que eu vejo, entre os sujos, eles são a espécie menos fétida. E, mesmo que os meios sejam terríveis, me parece que há um anseio bacana na Mozilla para fazer da internet um lugar realmente livre. E eu aprecio isso.

Mas a questão aqui é ontológica: o problema, caro leitor, reside na quintessência do que é desenvolver software. A “filosofia Unix” existe por um motivo. Os caras que a trouxeram à tona já desenvolviam software havia muito tempo e, naquela época, o cenário era caótico como hoje. O Unix surgiu enquanto os caras estavam ocupados tentando domar uma besta gigante chamada “MULTICS”. E a experiência foi mostrando a eles que padrões coerentes e simples é muito melhor do que a arrogância de tentarmos fingir que somos capazes de lidar com programas com milhões de linhas de código.

Hoarde (foi ele, certo?) já diria que há duas maneiras de se desenvolver software: tão simples a ponto de não restarem erros óbvios ou tão complexos a ponto de não restarem erros óbvios.

Você escolhe.

O cloc ainda não terminou e eu te pergunto: você realmente acha seguro executar código alheio (Javascript é exatamente isso, meu filho) na mesma “caixa de areia” em que você digita a senha do seu cartão de crédito? Você já considerou que está depositando muita confiança em um programa absurdamente grande, com, literalmente, milhões de linhas de código?

Quantos bugs escondem-se entre essas linhas? Eu tenho visto muita gente usando a proporção 1/25, mas digamos que seja 1/1.000: ... PAUSA.

*Eu achei estranho demorar tanto, fui no diretório onde clonei o Firefox e resolvi excluir o diretório .hg. O que eu vi (rm -rfv .hg) me deixou horrorizado.*

O Firefox tem cerca de 261.408 arquivos. ARQUIVOS. Se eu considerar que há um bug a cada 1.000 ARQUIVOS, e praticando a extrema benevolência de tentar ignorar os muitos arquivos de testes automatizados e scripts de build ou outros utilitários, ou seja, considerando que, quando você usa o Firefox para ver algum “website” você toca em meros 25.000 arquivos, poderíamos considerar que ele tem cerca de 2.500 bugs a serem descobertos.

DOIS MIL.

E QUINHENTOS.

BUGS.

Nessa tralha que você usa para acessar o internet banking.

Pegamos o gosto pelo lixo

Você pega um lixo repleto de lixo e em cima disso acha que vai construir o quê? Diabos, mais lixo, oras!

Há um caso interessante que mostra o quão funestamente perdidos nós estamos.

O ano era 2014 e um mesmo trabalho de processamento e análise de dados foi feito usando a linha de comando, com comandos e pipes e tudo o mais e, do outro lado, usando o “Amazon Elastic Map Reduce”/Hadoop.

O cálculo que o Hadoop demorou cerca de 26 minutos para fazer foi concluído em 12 segundos.

DOZE.

SEGUNDOS.

Estamos nessa época estranha em que o sujeito se depara com alguns terabytes de dados e logo pensa “oh! Eu preciso usar ferramentas de Big Data para lidar com isso”.

“Ferramentas de Big Data”. Eu poderia apostar que 90% dos casos em que alguém pensa assim poderiam muito bem ser resolvidos com a boa e velha linha de comando. Mas não soa tão legal, certo? E, no fim das contas, “ninguém nunca foi demitido por usar o Hadoop”.

O “mundo do desenvolvimento de software” está enchendo-se de novos jargões a cada dia que passa e, enquanto todo mundo acha a última “shiny new thing” toda “ultra-moderna” e como-nós-vivemos-sem-isso-até-agora, em algum lugar do mundo há alguém que viu a luz e hoje chora.

Opa! Terminou o cloc do Firefox! Até que enfim. Eu deveria ter chamado o comando junto com o time. Mas vamos aos números:

• Mais de 4 milhões de linhas de C++.
• Quase 4 milhões de linhas de Javascript.
• Quase 2 milhões de linhas de C.
• Quase 2 milhões de linhas de cabeçalhos C/C++ (que também é código).
• Mais de 1.3 milhão de linhas de Rust.

Sério, galera. Isso não é bom.

Resumo

Nós temos construído lixo sobre lixo e nos acostumado com isso de maneira tal que nosso “instinto de sobrevivência” ou de apego ao que nos é familiar simplesmente nos cega e nos mantém nesse rumo maluco e caótico em que nós achamos que estamos no caminho certo quando estamos apenas andando em círculos, mas cada vez mais longe do alvo.

Eu acredito que tudo o que hoje é usufruido como uma “web app” pode ser implementado e usado, por indivíduos e por equipes, como um conjunto de aplicações simples e, especialmente, sãs (em que a contagem de linhas de código se dê em centenas, não milhões).

Eu acredito que mais da metade das coisas que usamos hoje, mais da metade dos termos e mais da metade dos conceitos que hoje povoam “o mundo da T.I.” pode ser simplesmente jogado no lixo.

Não acho, claro, que o mundo vá mudar. Ninguém ouvirá a minha voz e, muito menos, fará qualquer esforço para começar a por em ordem essa baderna absurda.

Mas eu posso mudar. E quero mudar.

---

Este artigo foi escrito originalmente em 07/01/2019.