Não podia terminar o ano com pendências, então eis a parte final da Saga da Rinha de Backend. Neste video vou aproveitar os temas da rinha pra demonstrar em mais detalhes como configurar um Docker Compose de verdade, como funciona testes de carga com Gatling, como usar esses dados pra configurar coisas como o Postgres melhor. Também vamos ver como avaliar exatamente quanto pesa rodar SQL num Postgres, como determinar coisas com tamanho de pool de conexões e muito mais!

Hoje é dia de aprender ferramentas que todo programador deveria mesmo saber no dia a dia de projetos de verdade.

Capítulos

• 00:00:00 - Intro
• 00:01:03 - CAP 01 - Minhas Pendências da Rinha - Como Começar?
• 00:03:28 - CAP 02 - Entendendo Docker Compose - PHP do Lauro
• 00:07:38 - CAP 03 - Aprendendo a Lidar com Poucos Recursos - Configurando NGINX
• 00:15:33 - CAP 04 - Gargalos de Docker - Network Mode: Host
• 00:21:41 - CAP 05 - Prefira Docker em Linux - Problemas em Mac e Windows?
• 00:26:51 - CAP 06 - Algumas Dicas de Docker Compose - Node do Lucas Weis
• 00:30:21 - CAP 07 - Básico de Testes de Carga - Gatling
• 00:44:26 - CAP 08 - Comparando com Network Mode HOST - Faz diferença??
• 00:52:53 - CAP 09 - Entendendo PostgreSQL - Banco era Gargalo??
• 01:01:12 - CAP 10 - Full Text Search no PostgreSQL - Faz diferença??
• 01:07:35 - CAP 11 - Estratégia de SQL com EXPLAIN ANALYZE - SQL por baixo dos panos
• 01:16:11 - CAP 12 - Quantas Conexões Configuro no Banco? - Medindo com pgAdmin
• 01:23:34 - CAP 13 - Discutindo sobre Linguagens - Kotlin e Crystal
• 01:31:05 - CAP 15 - Como Linguagens afetam Recursos do Banco? - Só a saber, sobre threads vs fibers
• 01:35:00 - Bloopers

Links

• Repositório Oficial da Rinha
• GitHub Versão Node.js do Lucas Poole
• GitHub Versão PHP do Lauro Appelt
• GitHub - akitaonrails/rinhabackend-rails-api
• Docker Network Mode Host
• Gatling
• Vegeta
• HAProxy - The Reliable, High Perf. TCP/HTTP Load Balancer
• Envoy proxy - home
• Reverse proxy quick-start — Caddy Documentation (caddyserver.com)
• GitHub - jesseduffield/lazydocker: The lazier way to manage everything docker
• How to Insert Bulk Data in PostgreSQL - CommandPrompt Inc.
• pgAdmin - PostgreSQL Tools
• Spring Initializer
• Kotlin Programming Language (kotlinlang.org)
• The Crystal Programming Language (crystal-lang.org)
• Lucky - Web framework for Crystal (luckyframework.org)
• O que é a pilha ELK? | Explicação sobre a pilha Elasticsearch, Logstash, Kibana | AWS (amazon.com)
• O que é Elasticsearch – Explicação sobre o mecanismo Elasticsearch – AWS (amazon.com)
• Redis and Memcached-Compatible Cache – Amazon ElastiCache – Amazon Web Services
• Apache Kafka totalmente gerenciado | Amazon MSK | Amazon Web Services
• Working with read replicas for Amazon RDS for PostgreSQL - Amazon Relational Database Service
• Improve database performance with connection pooling - Stack Overflow
• How Postgres Makes Transactions Atomic (brandur.org)

SCRIPT

Olá pessoal, Fabio Akita

Antes de ir pro assunto de hoje, só confirmando que sim, o último video foi um experimento de fazer um episódio totalmente gerado por IA. Maioria sacou, mas muitos demoraram bastante ou nem se tocaram. Mas não se preocupem, foi só uma vez pra ver como fica. Não é nem um pouco prático fazer videos via ferramentas de IA como o HeyGen. Eu expliquei o processo na descrição do video, que vocês sempre pulam. Então leiam lá.

Assunto de hoje, finalmente, vai ser a prometida Parte 2 da Rinha de Backend. Sim, o video das 16 Linguagens em 16 dias foi lançado em Setembro e eu prometi uma parte 2. Estamos em dezembro, quase virando o ano e só agora estou soltando. Mas é assim que este canal funciona: me deu vontade de falar de outras coisas antes.

Objetivo deste video é complementar algumas dicas e informações que podem auxiliar nos seus estudos. Em particular algumas das técnicas que diferenciam projetinho de tutorial de projeto de verdade. Então, vamos lá …

(…)

Um dos motivos de porque demorei tanto pra fazer esse episódio é por causa destes dois itens que eu tinha colocado pra falar neste episódio: Resolvendo a Rinha em 5 minutos e O que é um framework web? Esses dois itens seriam um video inteiro de 2 horas e sinceramente, não estou com paciência pra esse tema porque já tem documentação suficiente online. Abra o site de qualquer framework web, seria o primeiro tutorial de como usa. Eu só estaria repetindo o que já existe online. Em vez disso vou só resumir alguns pontos principais.

Resolvendo a Rinha em 5 minutos. Sim, eu poderia fazer um speed run e editar um video demonstrando passo a passo como fazer uma versão das APIs. Eu acho inútil. Speed run de código só pra mostrar que sei fazer, realmente não me motiva. É óbvio que eu sei fazer. Flex desnecessário. Aliás, o video de 16 linguagens em 16 dias já foi flex o suficiente.

Se você é iniciante e tem dificuldade de resolver esse exercício, obviamente ainda falta estudar mais e treinar mais. O que eu sempre repito? Não existe uma única forma de resolver um problema de código. Não existe um único passo a passo de tutorial ou curso que consiga cobrir todas as permutações. O que vocês tem que fazer? Abrir o GitHub do evento e ir no diretório de participantes. Por isso achei este evento interessante: pela quantidade de versões diferentes que os participantes publicaram pra resolver o mesmo problema.

Vou dar um exemplo. Fiz clone do repositório principal da rinha na minha máquina. Peguem o link na descrição abaixo. Indo no diretório de participantes, temos 94 versões. Eu analisei a maioria delas no outro video, depois assistam lá. Mas digamos que esteja estudando PHP e queira ver como se resolve esse problema em PHP. A partir do diretório de participantes, só abrir um terminal e digitar grep "php" */README.* e olha só, aparecem 4 sub-diretórios, dois do Lauro Appelt e dois de um tal de Predator. No video anterior eu expliquei uma das versões do Lauro, que é feito em Hyperf com Swoole.

Vamos abrir o README de um dos diretórios e olha só, temos o link do repositório com o código em PHP do Lauro. Podemos clonar em qualquer outro lugar e fuçar pra ver como foi que ele implementou a versão dele. A parte mais interessante desse evento, é que um dos requerimentos foi pra todo participante criar Dockerfiles e Docker Compose pra tudo. Então é super fácil de executar, sem precisar adivinhar como configurar o ambiente pra cada projeto.

Hoje em dia eu considero de boa educação, boa etiqueta, que todo projeto, não importa quão pequeno ou quão grande, sempre deve ter um Dockerfile e um docker-compose. O Dockerfile demonstra como fazer pra rodar sua aplicação e o docker compose demonstra como subir as dependências desse projeto, como banco de dados. Vamos olhar o Dockerfile do projeto do Lauro.

Primeiro, ele inicia baixando uma imagem preparada pelo pessoal do framework Hyperf, que já trás tudo que você vai precisar. Em seguida, faz algumas configurações de timezone. Maioria das imagens boota com tempo UTC de Greenwich, timezone zero, como padrão. Pra ter os horários corretos da sua região geográfica, precisa colocar algo como “America/Sao_Paulo”, sempre. Ninguém vai adivinhar.

FROM hyperf/hyperf:8.2-alpine-v3.18-swoole

ARG timezone

ENV TIMEZONE=${timezone:-"America/Sao_Paulo"} \
    APP_ENV=prod \
    SCAN_CACHEABLE=(true)

Esse trecho seguinte grandão aqui é opcional e eu não testei o suficiente pra saber se era ou não necessário pra melhorar os tempos do benchmark. Tudo que ele está fazendo é criando um arquivo de variáveis de configuração, pra mexer em configurações como tamanho máximo de upload, que é desnecessário neste projeto, ou limite de memória, que talvez possa ser útil ou não, não medi pra saber.

RUN set -ex \

    && php -v \
    && php -m \
    && php --ri swoole \

    && cd /etc/php* \

    && { \
        echo "upload_max_filesize=128M"; \
        echo "post_max_size=128M"; \
        echo "memory_limit=1G"; \
        echo "date.timezone=${TIMEZONE}"; \
    } | tee conf.d/99_overrides.ini \

    && ln -sf /usr/share/zoneinfo/${TIMEZONE} /etc/localtime \
    && echo "${TIMEZONE}" > /etc/timezone \

    && rm -rf /var/cache/apk/* /tmp/* /usr/share/man \
    && echo -e "\033[42;37m Build Completed :).\033[0m\n"

Não saia copiando e colando achando que vai automaticamente melhorar alguma coisa. Vá na documentação e entenda item a item daqui. Daí rode uma versão sem isso, e outra versão com isso, rodando o mesmo benchmark, daí compare se faz alguma diferença. O fato de coisas que não importam pra este desafio, como tamanho máximo de upload, me diz que o Lauro copiou o Dockerfile de exemplo no site da imagem desse Hyperf, e colou aqui.

Finalizando, adicionamos drivers de postgres pra PHP, mudamos o diretório de trabalho pra /app, que é pra onde vamos copiar os arquivos do projeto na sequência. O que eu achei estranho é que não tem um último comando de ENTRYPOINT indicando como rodar a aplicação, também senti falta de rodar “composer install” pra baixar as bibliotecas. Isso é uma peculiaridade desta versão do Lauro, guardem isso que já já explico porque tá faltando.

RUN set -ex \
    && apk --no-cache add \
    && apk add php82-pdo_pgsql

WORKDIR /app

COPY . /app

Agora vamos ver o docker-compose.yaml. Docker compose é a descrição de uma mini-infraestrutura. Do que instalar, configurar e subir Redis, Postgres, Nginx, tudo na mão, podemos automatizar tudo num único comando. É muito mais fácil pra um novo desenvolvedor que entra no seu projeto, aprender como as coisas funcionam, se tiver um docker compose já pronto. Funciona com uma documentação viva da infra do projeto. É de bom tom, todo projeto de verdade, ter docker compose configurado que funciona.

Nunca fez um docker compose na vida? Como faz? Simples, começa pegando qualquer um dos 90 e tantos exemplos que tem neste evento como base. Vamos abrir o do Lauro e ir de baixo pra cima. Olha só, já sabemos que esse projeto depende de Redis estar de pé. Esse nome “redis” na primeira linha é qualquer nome que quiser. Por convenção colocamos o nome do que vamos rodar, mas poderia ser “cache_server” ou algo assim.

    redis:
        container_name: rinha-backend-redis
        image: redis:latest
        command: redis-server --save "" --appendonly no --maxclients 20000
        network_mode: host
        deploy:
            resources:
                limits:
                    cpus: '0.1'
                    memory: '0.2GB'

A única linha obrigatória mesmo é o nome da imagem. Docker, por padrão, vai baixar tudo de dockerio.com. Se quiser baixar de outro lugar, tem que colocar a URL inteira, senão só o nome e a versão da imagem é suficiente. Aqui está “latest”, que é a versão mais recente. Não gosto de usar latest porque se amanhã mudar a versão, e sua app não foi adaptada e teve mudanças que quebram compatibilidade, seus desenvolvedores vão começar a ter problemas. Se forem muito júniors, não vão associar que foi porque mudou a versão do redis e por isso as coisas quebraram do nada. É melhor colocar a versão fixa, como 7.2.3-alpine3.19, que significa Redis versão 7.2.3 rodando em cima da distro Alpine versão 3.19.

As outras opções são específicas da Rinha, em particular os limites de recursos na seção de deploy. Esse foi um dos critérios, que achei inteligente. Tínhamos no máximo 1.5 CPUs e 3 Gigabytes de RAM pra usar. À primeira vista, parece muito pouco. Não é fácil de imaginar como esses recursos encaixam em cada componente. Se você é um iniciante e tem uma máquina fraca, já aprendeu a ter que lidar com isso: como faz pra tirar o máximo proveito do seu Dual Core com 2 gigabytes de RAM? Todo programador que ficou bom, começou tendo que fazer rodar programas pesados em máquinas fracas.

Se você é um iniciante e já começou com oportunidade de usar máquinas novas e parrudas pra trabalhar, qualquer coisa acima de um quad core, acima de 8 gigabytes de RAM, tipo um Macbook da vida, e não teve que lidar com máquinas fracas, cuidado. Você vai pode acabar ficando complacente, preguiçoso. Vai achar que o mundo é igual sua bolha: que tem CPU sobrando, que tem RAM sobrando, e nunca vai entender o valor de otimizar as coisas. Pra que otimizar? Se tá tudo sobrando? Na hora que ficar difícil, você vai ser o tipo que desiste fácil.

Por isso eu repito que na minha teoria de Aprendendo a Aprender, tem que ter a Dor de Aprender. Não importa se você cai, importa como se levanta. Não importa quantas vezes cai, importa que toda vez se levanta mais rápido. Quem nunca sentiu dor, nunca aprendeu nada. E nesta rinha, a versão disso é essa limitação de recursos, senão, claro, o participante com uma máquina como a minha, com 64 giga de RAM, Ryzen 9 de 32 threads, facilmente conseguiria gerar resultados com números muito melhores que todo mundo. Mas com esse limite, o participante com um quad core de 4 giga de RAM poderia ultrapassar minha máquina, se soubesse administrar melhor os recursos limitados.

E isso de limitar recursos no Docker, não foi feito pra concursos. Foi feito pro caso de alguém realmente precisar rodar dois processos numa mesma máquina, e caso um deles seja fominha demais e consuma recursos demais, não deixar o outro processo morrendo de fome. Se o servidor tem 4 giga de RAM, eu subo dois programas, cada um no seu container de docker. Digamos que o primeiro resolva alocar toda a memória disponível, mesmo que não vá usar. Daí quando o segundo container tentar rodar, vai crashear, por falta de recursos.

Existem processos que alocam mais memória do que deveriam? Sim, por exemplo, um Node.js tem recurso de cluster, que eu mencionei no episódio anterior. O que muita gente faz? Vai no Google pesquisar e só copia um trecho parecido com esse de algum stackoverflow da vida. Esse script roda “os.cpus.length” e vê que sua máquina tem 4 cores, ou seja, 4 cpus, então faz 4 forks da aplicação. Cada fork pode ocupar, digamos, meio gigabyte. Então 4 forks daria 2 gigabytes. Como sua máquina tem 8 gigabytes, você nem se preocupa. Funciona tudo direitinho.

const numForks = require('os').cpus().length || 4;

if(cluster.isPrimary && process.env.CLUSTER === 'true'){
    logger.info(`index.js: Primary ${process.pid} is running`);

    for (let i = 0; i < numForks; i++) {
      cluster.fork();
    }

Aí você aloca um servidor num cloud qualquer, com 8 giga de RAM. Mas resolve pegar um CPU potente, de 16 cores. Seu script de cluster vai ver 16 cpus e subir 16 forks. Cada fork ocupando meio giga de RAM. Ou seja, vai ocupar todos os 8 giga de uma só vez. E você não tem 8 giga sobrando, seu sistema operacional e outros serviços ocupam RAM. Alguns desses forks vão crashear logo no boot.

O certo é consertar esse script e trocar a chamada de os.cpus e usar uma variável de ambiente no lugar. Assim podemos declarar essa variável, como CLUSTER_WORKERS, no yaml do docker compose, e ter controle sobre quantos processos realmente vai subir. Como desenvolvedor você sempre precisa ter controle sobre o que exatamente vai rodar, quantos recursos vai usar. Um bom jeito de se exercitar é acertando script de docker compose.

const numForks = Number(process.env.CLUSTER_WORKERS) || 4;

Continuando, depois do redis tempos nginx. Esse foi outro pré-requisito nas instruções da rinha: ter um proxy reverso pra servir de balanceador de carga entre, no mínimo, duas instâncias da sua aplicação. Quando um estudante segue um tutorial de web qualquer, ele só entende que tem um único processo, o servidor da aplicação. Sobe numa porta como 4000 e no navegador coloca localhost:4000 e pronto, acabou.

    nginx:
        container_name: rinha-backend-nginx
        image: nginx:alpine
        volumes:
            - ./docker/nginx/nginx.conf:/etc/nginx/nginx.conf
        network_mode: host
        depends_on:
            - api-01
            - api-02
        deploy:
            resources:
                limits:
                    cpus: '0.1'

Esse é o nível zero no aprendizado. O nível logo acima desse hiper básico, tem que aprender que em projetos de verdade, subimos múltiplos processos em paralelo, seja na mesma máquina, seja em múltiplas máquinas. Se for na mesma máquina, um sobe na porta 3000, outro na porta 3001, outro na 3002. Em qualquer dos casos, sempre colocamos um balanceador de cargas na frente, na forma de um proxy reverso. Explico isso no episódio “Tornando sua Web App Mais Rápida”.

Alguns mais experientes poderiam criticar a escolha de NGINX, sendo que existem ou programas mais especializados pra isso como HAProxy ou mais modernos como o Envoy ou Caddy. Mas de jeito nenhum é uma escolha ruim, especialmente porque é um dos que tem mais documentação, é simples de usar, e pra esta rinha, está mais que bom. Nesta seção de docker compose temos duas coisas importantes, a primeira é a imagem. No caso estamos usando a versão de Alpine, que é uma das mais leves. Mais importante é o mapeamento de volume.

Precisamos mapear o arquivo de configuração que fica no nosso projeto do lado de fora, para que o container tenha acesso quando bootar. Lembrem-se, um container é só uma forma de mentir pro processo que roda dentro, pra ele achar que está sozinho, numa máquina vazia. Ele não enxerga nenhum arquivo de fora se nós não declararmos pra dentro, da seguinte forma.

volumes:
	- ./docker/nginx/nginx.conf:/etc/nginx/nginx.conf

O que tem nesse arquivo de configuração? Vamos dar uma olhada. Se nunca viu, parece complicado, mas vamos por partes. Esta primeira parte do topo tem a ver com a escalabilidade do serviço. Nginx funciona numa arquitetura de master e workers. Esse “worker_processes” como “auto” de automático quer dizer que ele vai avaliar quantas cpus sua máquina tem e subir 1.5 vezes. Então, se tiver 4 cpus, ele vai subir 6 workers.

worker_processes auto;

Por que não 1 worker por 1 cpu? Primeiro, uma cpu não é exclusiva de 1 processo. Quem controla qual processo vai rodar em qual cpu durante um período x de tempo, é o scheduler da kernel. Se seu processo é leve e precisa de pouco tempo pra fazer o que precisa, não tem porque bloquear uma cpu inteira só pra ele. Dá pra dividir com outros processos. Depois assista meus episódios sobre concorrência e paralelismo pra entender como schedulers funcionam.

Em seguida temos worker_connections como 4096. Isso indica quantas conexões simultâneas cada worker vai tentar aguentar. Não confunda conexões simultâneas com processamento paralelo. Se realmente vier 4096 requisições web, exatamente no mesmo instante, esse parâmetro só significa que o worker vai aceitar as 4096 conexões, mas uma boa parte vai ficar esperando numa fila, até ser atendido. Se demorar mais do que certo tempo, que podemos configurar, ele pode rejeitar e devolver erro de timeout. Como o nome diz, erro de tempo expirado.

events {
    worker_connections 4096;
}

No primeiro episódio que fiz da rinha eu expliquei como muitos ficaram tentando mexer nesse número meio que no chute. Só o Leandro, que fez a versão em Ruby, entendeu que o truque não era aumentar esse número e sim diminuir. Eu explico o raciocínio no outro video, então não deixem de assistir depois.

O Nginx é só o tirador de pedidos, lembram da analogia do caixa de restaurante fast food? Ele tira os pedidos, mas quem realmente executa, os cozinheiros, são estes servidores declarados nesta seção upstream. No caso apontando pra localhost, portas 9501 e 9502. Se já mexeu com docker compose antes, isso poderia parecer um pouco estranho.

http {
    access_log off;
    error_log /dev/null emerg;

    upstream api {
        server localhost:9501;
        server localhost:9502;
        keepalive 400;
    }

Normalmente, pra subir um nginx via docker compose, eu teria uma configuração mais ou menos assim: declararia dois serviços web, as instâncias da minha aplicação, como app1 e app2. Ambos carregando na porta 8080. Daí, na configuração do nginx, essa seção upstream estaria apontando pra app1 porta 8080 e app2 também porta 8080.

Mas como que dá pra ter dois serviços subindo na mesma porta? Não tem conflito? E não tem, porque na prática é como se cada container representasse um servidor externo separado. E sua aplicação está carreagando num servidor fora, só que virtual. Daí, cada servidor tem uma porta 8080 livre. Cada instância pode se pendurar na porta 8080 do seu respectivo “servidor virtual”. Acontece que o nginx e esses servidores virtuais se comunicam na mesma rede, também virtual, daí o nginx consegue fazer o balanceamento entre esses dois serviços.

No episódio anterior eu expliquei a descoberta que alguns de nós fizemos durante nossos experimentos, o Vinicius Ferraz fez a descoberta de que se usarmos o modo de rede de ponte virtual, que é o padrão, isso introduzia um gargalo pesado e os resultados dos benchmarks ficavam bem errados. Mas se colocarmos o modo de rede pra host, ou seja, sem virtualizar a rede, aí os tempos finalmente ficam corretos.

Não sei se notaram, mas na configuração do redis que mostrei antes, ou nesse de nginx, note que ambos já tem a opção network_mode igual a host, indicando que é pra pendurar o container nas portas da rede de verdade do sistema operacional nativo. Nesse modo não podemos pensar que temos “servidores virtuais separados” mas sim que estamos subindo realmente tudo na mesma máquina, na rede de verdade. Portanto, precisamos nos preocupar com conflitos de portas. Por isso no upstream do nginx, apontando pra dois servidores em localhost, cada um deles precisa estar numa porta diferente, 9501 e 9502.

É muito importante entender o que é modo de rede ponte e a diferença com modo de rede host. Estudem se não sabiam disso. Mas já que falamos do servidor de aplicação. Note que na configuração do nginx, tem esse seção de depends_on. Ele quer dizer: só suba o serviço nginx quando detectar que os serviços api-01 e api-02 estejam de pé. Então vamos pular pro começo do arquivo do docker compose, pra ver como essa aplicação está configurada.

services:

    #api1
    api-01:
        container_name: rinha-backend-api-01
        build:
            context: .
            dockerfile: Dockerfile
        environment:
            HTTP_PORT: 9501
            APP_NAME: skeleton
            APP_ENV: dev
            DB_DRIVER: pgsql
            DB_HOST: localhost
            DB_PORT: 5432
            DB_DATABASE: rinha-backend-db
            DB_USERNAME: rinha
            DB_PASSWORD: postgres
            REDIS_HOST: localhost
            REDIS_PORT: 6379
        volumes:
            - ./:/app
        depends_on:
            - db
            - redis
        command: bash -c "php bin/hyperf.php start"
        network_mode: host
        deploy:
            resources:
                limits:
                    cpus: '0.4'
                    memory: '0.3GB'

Precisamos dar um jeito de configurar a mesma aplicação duas vezes, como api-01 e depois como api-02 e, como estamos usando modo de rede host, precisamos declarar portas direrentes pra cada uma, que normalmente fazemos via variáveis de ambiente, como esse HTTP_PORT logo no começo. O jeito mais fácil é configurando esse bloco de configuração do serviço api-01 e depois fazendo um copy e paste embaixo pra ser o api-02, só mudando o HTTP_PORT pra 9502.

Existem outras formas de fazer isso. Como exemplo, que pegar o docker compose do projeto de Node.js do Lucas Poole, porque ele ainda está usando o modo de rede padrão, via ponte virtual, daí não precisou se preocupar em configurar portas diferentes, só precisou fazer hostnames diferentes. Vamos dar uma olhada.

services:
  app1: &app
    # image: lukas8219/rinha-be-2023-q3:latest
    build: .
    hostname: app1
    environment:
      DB_URL: "postgres://postgres:12345678@postgres:5432/postgres"
      DB_POOL: 35
      PINO_LOG_LEVEL: "debug"
      REQ_TIMEOUT: "2000"
      NODE_ENV: production
      CLUSTER: true
      CLUSTER_WORKERS: 5
    expose:
      - "8080"
    depends_on:
      - postgres
    ulimits:
      nproc: 1000000
      nofile:
        soft: 1000000
        hard: 1000000
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: '0.6GB'
  app2:
    <<: *app
    hostname: app2

Ele declarou o serviço de nome “app1” e em seguida anexou uma etiqueta com esse & comercial, chamando de “app”. Descendo pro próximo serviço no mesmo arquivo, observem, temos app2. E na linha seguinte é como se fosse um “include” ou “import”, dizendo pra copiar tudo que tinha no app1. A única coisa que muda é o nome do hostname. Entenderam? É assim que podemos reusar as mesmas configurações entre diferentes serviços. Isso é uma características de arquivos de configuração em formato YAML, não é coisa do docker compose. Qualquer outro programa que use YAML, dá pra fazer a mesma coisa.

Como falei antes, o projeto do Lucas não está usando o modo de rede host e sim o de ponte, por isso na configuração do app2, ele mantém o mesmo número de porta. Se fosse no modo host, precisaria declarar pelo menos um número de porta diferente, pra não conflitar no localhost. Se nunca viu isso antes, sei que pode ser confuso, mas se lembre dessa diferença entre ponte de rede virtual e rede host nativa.

A parte mais importante na configuração da nossa aplicação de API é este parâmetro “build”. Aqui está mais completo do que precisa. Bastaria ter escrito o valor “.”, mas o Lucas preferiu declarar o contexto como “ponto” e o arquivo como sendo “Dockerfile” mesmo, que é o padrão.

É aqui que ele vai usar o arquivo de Dockerfile que já vimos antes, pra construir a imagem pra este container. Todos os outros serviços, nós apontamos pra imagens já prontas no serviço do site Docker Hub. Aquelas imagens foram todas feitas com algum Dockerfile também. A diferença é que nossa aplicação não foi publicada no Docker Hub, estamos construindo ela aqui, então apontamos direto pro Dockerfile. No futuro, quando a aplicação estiver terminada, podemos dar upload da última imagem gerada e passar a apontar pra ela via parâmetro image em vez de build. No arquivo do Lucas, tem até comentado essa opção, porque pra participar da rinha, precisava ter publicado a imagem de verdade.

O Dockerfile do Lauro, que mostrei antes, usa de base a imagem do repositório do Hyperf e também incluímos coisas como o PDO de Postgres. Todos esses elementos podem ser configurados via variáveis de ambiente, que é o que estamos declarando na seção “environment”, como o HTTP_PORT, que indica em qual porta o servidor de Hyperf vai subir, ou DB_HOST ou REDIS_HOST que declara o nome do servidor que vai ter o banco de dados e o cache. Neste caso, em modo de rede host, vai ser tudo localhost.

No projeto do Lauro, quando fizemos as otimizações de performance que expliquei no outro episódio, ele fez alguns ajustes depois e preferiu não deixar tudo 100% automatizado. Lembram que falei que no Dockerfile dele estava faltando o comando ENTRYPOINT, que define que executável iniciar no container? Pra saber o que fazer, tem que ler o README dele. Ao subir o Docker Compose, os containers vão estar de pé, mas internamente quem vai rodar é este comando de “sleep infinity”, que é um truque só pro container ficar de pé e não morrer.

A razão disso foi porque ele não adicionou os próximos passos no Dockerfile, não sei por que, mas o README pede pra rodar manualmente, via “docker exec” o comando de “composer install” pra instalar as dependências. Como ele mapeia o diretório inteiro como “/app” pra dentro do container, se não me engano, “composer install” vai baixar e gravar as dependências no sub-diretório “/app/vendor”. Por isso tanto faz rodar em qualquer um dos dois containers, o outro vai enxergar automaticamente, já que compartilham do mesmo volume no disco.

Só depois de fazer isso que, via docker exec de novo, podemos rodar o hyperf em cada container, e vai subir direitinho. Durante desenvolvimento, dependências como bibliotecas de node, ou neste caso, do composer, não queremos deixar dentro da imagem, porque ocupam muito espaço e mudam o tempo todo. Seria trabalhoso toda vez reconstruir a imagem. O melhor é mapear um volume pra dentro do container e mandar instalar nesse volume. Só quando for gerar a imagem final pra publicar, aí sim, era bom mudar pra gravar as dependências dentro da imagem. Senão quem for baixar depois, vai precisar fazer isso manualmente, o que não é ideal.

Feito tudo isso, do terminal, basta subir tudo com “docker compose up”. Isso vai baixar as imagens que ainda não tem, construir essa da aplicação e subir tudo certinho, na ordem certa, graças aos depends_on que todos os serviços declaram. Olhem só, da primeira vez demora um pouquinho pra subir. Vou acelerar aqui um pouquinho e … pronto. Como expliquei antes, só pra esse projeto do Lauro, temos que rodar o composer install manualmente, aceleramos mais um pouco e … pronto. Finalmente, podemos subir o Hyperf em cada um dos containers.

Pra testar que tudo deu certo, podemos consultar o endpoint da API de contagem de pessoas, que é usado pelo script de benchmark pra mostrar quantas pessoas foram inseridas no teste de carga. Basta chamar do próprio terminal com “curl http://localhost:9999/contagem-pessoas”. E.. deu pau. O que aconteceu?

Se estiver rodando em alguma distro Linux, ia retornar bonitinho. Mas se estiver rodando em Mac ou Windows, como neste meu caso, via WSL 2, aquela configuração de network mode host não vai funcionar. Por que?

Se não entendem como um container funciona por baixo, não deixe de assistir o episódio sobre containers. Em resumo, Docker precisa da kernel Linux pra funcionar. Docker não é uma máquina virtual, é uma infraestrutura que pede pra kernel mentir pros processos, fazendo eles acreditarem que estão rodando sozinhos na máquina.

No caso de Mac, o problema é que Macs não rodam kernel de Linux. Apesar de rodarem programas que parecem de Linux, na realidade são todos recompilados pra serem compatíveis com a versão Darwin do BSD UNIX. Macs são UNIX e não Linux. Eu já contei essa história no episódio sobre as diferenças de Mac, Windows e Linux. Programas de Linux não rodam nativamente em Macs, todos precisam ser no mínimo recompilados. Mac e Linux são binariamente incompatíveis.

Windows, obviamente, também não é uma distro Linux. A kernel do Windows é fundamentalmente diferente de Linux e Macs. Mas hoje em dia existe o WSL 2, que é basicamente uma máquina virtual Linux super leve, rodando por cima do Windows usando a infraestrutura de hypervisor do Hyper-V. Essa é a única solução pra Macs e Windows: rodar Linux numa máquina virtual e, dentro dela, rodar Docker.

Tanto no caso de Mac, quanto Windows, uma das opções mais populares é baixar o pacote Docker Desktop, que vai instalar a máquina virtual pro Docker e uma interface gráfica, que é opcional, pra facilitar gerenciar os diversos elementos de Docker, como redes virtuais, imagens e containers. E aqui está o problema de porque não funciona localhost:9999 em modo de rede host. Segundo a própria documentação: o driver de rede modo host só funciona em Linux, rodando na VM do Docker Desktop, o container não vai receber nenhum endereço IP e a publicação de portas vai ser ignorada, tornando o container inacessível.

Quer dizer que Docker Desktop de Windows e Mac são uma droga, então? Recapitulando, porque estávamos usando modo de rede host? Porque no cenário de teste de carga, o modo padrão gera gargalo, então mudamos pro modo host. Isso é só pra situação de teste de carga. Pro dia a dia, enquanto você está programando, em situações normais, não vai sentir diferença nenhuma. Nesse caso, não precisa usar esse modo host e deixar tudo no padrão. No modo ponte virtual, Docker de Mac e Windows vai funcionar direitinho.

No caso do WSL 2, você pode instalar o Docker ou Podman dentro do WSL em vez de usar uma VM separada, como o Docker Desktop faz.

Falando de Docker Desktop, uma pequena tangente, se você quiser muito uma interface gráfica pra gerenciar imagens, containers e tudo mais, experimente outra opção: o Portainer, que por si só é uma aplicação que roda em container Docker, então é trivial de instalar, e te dá uma interface web de administração muito mais avançada do que Docker Desktop. Mas também é legal aprender a ficar na linha de comando e experimentar coisas como Lazy Docker. Dá pra fazer tudo só com o comando “docker”, mas às vezes não lembramos como fazer coisas que não se usa todo dia, tipo, “como era mesmo, pra apagar imagens que não estão sendo usadas?”, daí tanto Portainer como Lazy Docker podem ajudar. Dêem uma fuçada.

Na verdade, é muito mais fácil usar o NAT de portas, que é a opção padrão. Vamos pegar o arquivo de nginx do projeto do Lucas, que não optou pelo modo de rede host. Olha a declaração de servidores de upstream. Em vez de estar localhost com duas portas diferentes, tempos aqui dois hostnames diferentes usando as mesmas portas. É como se estivéssemos declarando dois servidores separados, cada um com uma cópia da aplicação na porta 8080.

    upstream api {
        server app1:8080;
        server app2:8080;
        keepalive 500;
    }

No docker compose, podemos declarar o app1, expor a porta 8080, etiquetar com & comercial “app” e lá embaixo declarar o app2 usando a mesma configuração, só sobrescrevendo o hostname. Todo o resto fica igual. Não precisamos nos preocupar em conflito de portas, porque é como se fossem servidores em máquinas diferentes. Essa é a vantagem do NAT de portas e por isso ele é o modo padrão. É muito mais intuitivo. Se não ficou claro isso, assista de novo meu episódio sobre containers e a série de redes.

A versão em PHP do Lauro é uma das mais complicadinhas pra subir, por causa daqueles passos extras no README, que ele preferiu não automatizar. Pra prosseguir a explicação, vamos usar o projeto de Node do Lucas daqui pra frente. O dele é mais simples, basta executar “docker compose up”, esperar tudo baixar e pronto. Mesmo em Docker de Windows ou Mac não deve ter problemas porque a versão dele usa NAT de portas padrão, então tudo deveria funcionar plug and play, que é o ideal de um docker compose.

Antes que eu me esqueça, se não está acostumado a usar docker compose, sempre se lembre que se não iniciar o comando “up” com a opção “-d” de daemon, ele vai ficar prendendo seu terminal. Com control-c dá pra derrubar todo mundo. E garanta que os containers desligaram executando “docker compose down”. Se modificar seu código e subir depois com “up” mas sentir que não apareceram suas modificações, dá pra forçar o build da imagem da aplicação com “docker compose up –build” ou “docker compose up –force-build”.

De outro terminal, dá pra ver os containers que estão de pé fazendo “docker ps”. Olha só como aparece bonitinho, daí dá pra abrir o shell em qualquer um deles usando “docker exec -it”. Enquanto estiver trabalhando num projeto, pode só ficar derrubando com o comando “down” e subindo com o comando “up”. Mas quando terminar o projeto e não for mais mexer nele, vale derrubar uma última vez com “docker compose down –rmi all”. Essa opção vai apagar os containers e as imagens. Imagens de docker usam muito espaço em disco e se ficar esquecendo de limpar de projetos que não vai mais usar, vai estar desperdiçando espaço. Depois pesquise sobre como limpar containers e imagens que não está mais usando.

Voltando, chegou a hora de entender um pouco esse negócio de teste de carga. Entenda, foda-se que linguagem você escolheu, que framework usa, as toneladas de javascript que enfiou no front-end. Svelte, Tailwind, nada disso importa. A única coisa que interessa é que entre seu navegador favorito e sua aplicação, trafegam mensagens em formato texto, obedecendo o protocolo HTTP. Mensagens divididas em cabeçalhos e corpo de texto.

O teste que sugeri antes, curl http://localhost:9999/contagem-pessoas é um exemplo disso. O Curl ou Wget são navegadores de linha de comando. Navegadores simples, que não tem front-end e por isso não precisam interpretar nem html, nem css, nem javascript. Eles só listam o que recebem. Fiquei pensando se perdia tempo explicando curl, como mandar e receber mensagens HTTP. Mas isso seria uma tangente desnecessária. Todo desenvolvedor web, tem que saber como enviar e receber mensagens HTTP manualmente, seja via curl na linha de comando, seja via web developer tools em qualquer navegador. Sem saber isso, sinto muito, você nem começou a entender web ainda. Volte vários passos, estude mais, só depois retorne.

Estou sendo bem cuzão quanto a isso porque é sério: HTTP é simples, os cabeçalhos principais dá pra saber de cabeça, os encodings de mensagem, como URL encode, são simples. E se não entender como funciona essa troca de mensagens, tudo daqui pra frente não vai fazer nenhum sentido. Sem saber isso você não entende nem o que é uma API. Sem saber isso não tem nem como começar a falar de problemas de segurança triviais como request forgery, nem otimizações de performance como conditional get requests. 80% da parte mais interessante e mais importante, você nunca vai ter acesso. Então pare aqui e vá estudar antes.

Isso tudo dito, vamos pular direto pro Gatling, que é a ferramenta de stress test, ou teste de carga, que a rinha escolheu. Eles até deram uma pequena patrocinada, acho que com alguns prêmios pros ganhadores. É uma ferramenta que aceita scripts feitos em Scala ou Kotlin. Primeiro de tudo é ter Java instalado na sua máquina. Cuidado, saiu não faz muito tempo o Java 21, e dependendo da sua distro, com um Arch, que instala tudo que tem de novo, vai ter problemas. Escolha manualmente o OpenJDK 17 ou versões mais antigas como versão 11.

Como eu sei que estou com o java correto? Porra, abre o terminal e digita ‘java -version’. Se tiver mais de uma jdk instalada, no caso de um Arch, tem o script ‘archlinux-java set java-17-openjdk’ pra forçar usar a versão 17, por exemplo. Consulte a documentação do pacote de JDK da sua distro. Se for Windows ou Mac, baixe direto o instalador da versão 17 e já era.

Depois disso precisa baixar o Gatling propriamente dito. Só ir no site e baixar o zip. Depois deszipe onde quiser. Eu pessoalmente prefiro deszipar no diretório “/opt/gatling” mas você pode deszipar na sua home. Enfim, o importante é entrar no repositório da rinha, no diretório chamado “stress-test”. Lá vai achar o script principal, “run-test.sh”. Tem versão de Powershell também, mas honestamente, não perdi meu tempo com isso.

Edite esse script e garanta que a variável GATLING_BIN_DIR está apontando pro diretório bin que veio dentro do zip que baixou. Olhe a linha de baixo, é como ele executa o gatling, passando o script da simulação que é esse RinhaBackendSimulation, que já vamos ver. Em seguida declara os diretórios principais de trabalho. Fica tudo dentro de “stress-test/user-files”. Em resources temos planilhas com dados de teste. Vamos dar uma olhada.

O arquivo “pessoas-payloads.tsv” tem os dados de pessoas falsas que ele vai enviar pra API de cadastrar pessoas. Como podem ver, cada linha é um JSON, e os dados são super aleatórios mesmo. Você acha que todo mundo envia dados bonitinhos pra sua aplicação? Pelo contrário, com o tanto de bots que tem por aí, sua aplicação está recebendo dados parecidos com esse o tempo todo. Nunca assuma que sua aplicação vai ser usada só por pessoas inteligentes que sabem ler e escrever direito.

Pelo contrário, assuma que a maior parte do uso vai vir de bots zoados ou pessoas zoadas que male male sabem escrever o próprio nome e vão preencher tudo errado. Sua aplicação precisa estar preparada para os piores inputs, sempre. Esse é um bom exemplo de ataque pra ver se coisas inválidas acabam conseguindo burlar suas validações, ou o mais comum, você esqueceu de implementar algumas validações.

O segundo arquivo é o “termos-busca.tsv” que vai ser usado na API de procura por termos. É outra lista de bobagens aleatórias. Mesma coisa, é pra estressar suas APIs e ver como se comportam. Precisa ter validações conforme explicado nas instruções da rinha. Pra um projeto de verdade, é bom ter teste de carga com dados completamente aleatórios como esses, mas também é bom ter dados um pouco mais próximos do que pessoas medianas mandariam, pra ficar mais fácil de analisar depois. Criar dados de teste é, em si, uma arte também.

Testes com inputs aleatórios como esse são chamados de Fuzz Test. Fuzz é tipo barulho, bagunça, que é um jeito de dizer aleatório. Se você só fizer testes com dados que parecem de verdade, está perdendo a oportunidade de ver os limites das validações.

Finalmente, temos o script do teste de carga propriamente dito, neste arquivo RinhaBackendSimulation.scala. Mesmo se você nunca escreveu Scala antes, pra fazer scripts simples com esse não é difícil. Qualquer bom programador deve ser capaz de no mínimo ler e entender sem grandes dificuldades. Vamos lá, por partes.

Gatling tem o conceito de Simulation e nossa classe herda dela. Em seguida começamos definindo pra onde mandar nossa carga. No caso a URL base é localhost porta 9999, onde configuramos o NGINX no Docker Compose, lembram? Como nossa aplicação não tem tratamento pra nenhum cabeçalho, só isso já basta. Só de brincadeira, colocaram um user agent fake aqui.

class RinhaBackendSimulation
  extends Simulation {

  val httpProtocol = http
    .baseUrl("http://localhost:9999")
    .userAgentHeader("Agente do Caos - 2023")

Seguimos declarando uma variável “criacao E consulta pessoas” que é um “scenario”. Imagino que essa função “scenario” tenha na classe abstrata Simulation que estou estendendo. Ela devolve um objeto onde podemos sair encadeando várias chamadas de configuração. A API de configuração é bem legível. Olha só: no cenário criação e talvez consulta de pessoas, alimente com o arquivo formato tsv “pessoas-payloads.tsv” e considere sendo circular, ou seja, se chegarmos no fim do arquivo, recomece da primeira linha de novo. Pra cada linha execute o bloco a seguir.

  val criacaoEConsultaPessoas = scenario("Criação E Talvez Consulta de Pessoas")
    .feed(tsv("pessoas-payloads.tsv").circular())
    .exec(
		.... // bloco
    )

Nesse bloco começamos chamando outro método da simulação, “http”, que imagino que controla uma chamada http. Configuramos com uma chamada POST pra endpoint “/pessoas”, onde o corpo vai ser o payload, que é uma linha do arquivo de carga que estamos lendo. Como único cabeçalho configuramos “Content-type” pra ser o mime-type “application/json”. Todo framework que se preza, checa content type.

.exec(
  http("criação")
  .post("/pessoas").body(StringBody("#{payload}"))
  .header("content-type", "application/json")
  // 201 pros casos de sucesso :)
  // 422 pra requests inválidos :|
  // 400 pra requests bosta tipo data errada, tipos errados, etc. :(
  .check(status.in(201, 422, 400))
  // Se a criacao foi na api1 e esse location request atingir api2, a api2 tem que encontrar o registro.
  // Pode ser que o request atinga a mesma instancia, mas estatisticamente, pelo menos um request vai atingir a outra.
  // Isso garante o teste de consistencia de dados
  .check(status.saveAs("httpStatus"))
  .checkIf(session => session("httpStatus").as[String] == "201") {
	header("Location").saveAs("location")
  }
)

Essa função “check” não tenho muita certeza do que faz e não tive paciência pra ir ler na documentação, mas não me parece importante pra agora. Deve ser algo como, “considere que está certo se o resultado da requisição voltar com código de status 201, 422 ou 400”. Se voltar um crash com erro 500, ou página não encontrada que é 404, ou outra coisa, considere como um erro e reporte em vermelho.

Depois temos um novo check, pedindo pra salvar alguma coisa chamada “http status”. Podemos ver que vai ser usado na chamada checkIf abaixo. Essa linha parece dizer o seguinte: execute o bloco seguinte se o código http de status que gravamos na linha anterior for código 201, que é o código http correto quando um recurso é criado no servidor. Se for esse o caso, o bloco seguinte deve salvar o valor que voltar no cabeçalho de Location, dentro dessa sessão chamada “location”. Lembre-se disso em design de APIs: sempre que um recurso é criado no servidor, retornando código 201, também deve retornar um cabeçalho chamado Location com a URL completa para este novo recurso. É isso que estamos guardando.

Saindo desse bloco, o cenário dá uma pausa de 1 a 30 milissegundos. Em seguida, caso uma sessão de location tenha sido gravado, ele pede pra executar uma nova requisição http para esta location. Se for encontrado, o servidor deveria retornar código http 200 e o json do registro. Se for retorno 200 a simulação deve considerar como verde OK. Se voltar qualquer outro código, deve considerar vermelho knock out.

    .pause(1.milliseconds, 30.milliseconds)
    .doIf(session => session.contains("location")) {
      exec(
        http("consulta")
        .get("#{location}")
      )
    }

Como o comentário explica, o Zanfrancheschi, que desenhou o desafio da rinha, fez a coisa certa. Pro desafio ser minimamente interessante, só criar uma API que grava uma nova pessoa no banco, seria muito simples. Qualquer um que já tenha terminado pelo menos um tutorial de curso deveria conseguir. Mas, subir duas instâncias da mesma aplicação e colocar embaixo de um proxy reverso cria uma situação um pouco mais interessante.

Digamos que você tenha feito otimização prematura. Vamos tentar ser mais espertos. Ao receber o JSON via POST em /pessoas. Guardamos em memória, sem mandar insert pro banco, pra gravar assincronamente mais tarde, e assim podemos responder imediatamente código http 201. Como geramos um UUID aleatório antes de mandar pro banco, dá pra gerar a URL de Location. Seria algo como “http://localhost:9999/pessoas/:uuid”

O script do Gatling dá uma pausa de 1 a 30 milissegundos e manda puxar essa URL que voltou no cabeçalho de Location. Se antes desses 30 milissegundos, nossa aplicação não conseguir realmente gravar no banco, tem chance da consulta cair na segunda instância. Se o registro não teve tempo de ser gravado, não vai ser encontrado e vamos receber 404 not found. A simulação iria registrar um erro. Então, só segurar o registro em memória pra responder mais rápido iria quebrar essa condição de pesquisa do teste, tem que ser mais esperto que isso.

A expectativa da rinha, com os limites de CPU e RAM impostos, o requerimento de colocar duas ou mais instâncias, e impor uma carga pesada, enganaria programadores mais calejados a caírem no erro de tentar otimização prematura, colocando coisas como caches ou filas, como expliquei no episódio passado. Se fizer do jeito mais ingênuo que é primeiro escrever no banco e depois devolver código 201 com a URL de Location, vai tudo funcionar corretamente. Mas será que aí o tempo de espera de gravar no banco não vai fazer o NGINX dar timeout em muitas requisições?

E não, foi isso que descobrimos na exploração do episódio de 16 linguagens: todos nós subestimamos o banco de dados Postgres. Acontece que pra casos simples como esse, de inserts simples, ele é tão rápido quanto um servidor de cache como Redis. Qualquer otimização extra não faz diferença. A otimização de usar modo de rede host em vez de NAT de portas virtuais fez mais diferença do que tentar otimizar o Postgres com alguma solução de cache. Já vou voltar nisso, vamos só terminar de ler o arquivo de simulação.

O cenário de criação de pessoas, seguido da consulta dessa pessoa recém-criada, é o cenário mais comprido. Nem é difícil, só comprido. Os outros dois cenários são mais curtos. No “busca pessoas”, o cenário se alimenta do arquivo tsv “termos-busca.tsv”, novamente em modo circular, e pra cada linha do arquivo, faz uma requisição GET no endpoint “/pessoas” passando a variável “t=”, concatenando o parâmetro de busca.

  val buscaPessoas = scenario("Busca Válida de Pessoas")
    .feed(tsv("termos-busca.tsv").circular())
    .exec(
      http("busca válida")
      .get("/pessoas?t=#{t}")
      // qq resposta na faixa 2XX tá safe
    )

Acho que se não configurar explicitamente, o cenário considera que respostas 200 são OK e qualquer coisa diferente é erro. Por fim, temos o cenário de busca inválida de pessoas, que é o mesmo endpoint, só não passando nenhum termo de procura. Segundo a instrução da rinha, isso deveria retornar código de erro 400, que é o que o script vai checar mesmo. Se devolver 400, marca como verde, OK.

  val buscaInvalidaPessoas = scenario("Busca Inválida de Pessoas")
    .exec(
      http("busca inválida")
      .get("/pessoas")
      // 400 - bad request se não passar 't' como query string
      .check(status.is(400))
    )

Com os 3 cenários declarados, agora o script define um bloco que chama de “setup”. Literalmente, configurar como os cenários devem rodar. Em todos os casos, começa dizendo “comece com 2 usuários constantes por segundo, durante 10 segundos”, na sequência fala “prossiga agora com 5 usuários por segundo, durante 15 segundos”. É uma carga leve, só de warm up, ou aquecimento mesmo.

setUp(
	criacaoEConsultaPessoas.inject(
	  constantUsersPerSec(2).during(10.seconds), // warm up
	  constantUsersPerSec(5).during(15.seconds), // are you ready?
	
	  rampUsersPerSec(6).to(600).during(3.minutes) // lezzz go!!!
	),
	...
).protocols(httpProtocol)

Em seguida começa a carga de verdade, olha só “ramp”, que quer dizer ir aumentando, como numa rampa mesmo. Vá aumentando, começando com 6 usuários por segundo, até atingir 600 usuários por segundo, acelerando constantemente durante 3 minutos, mantendo um crescimento linear. Agora sim, isso vai gerar uma carga pesada até o final. Entenderam?

Mas não é só isso, em paralelo vai rodar também os cenários de busca e busca inválida. Ambos fazem um aquecimento pequeno pelos mesmos 25 segundos. Daí já começa, ramp de 6 usuários por segundo, até atingir 100 usuários fazendo buscas válidas por segundo, durante os mesmos 3 minutos. E por fim, ramp de 6 usuários por segundo até 40 fazendo buscas inválidas por segundo, durante 3 minutos.

	buscaPessoas.inject(
	  constantUsersPerSec(2).during(25.seconds), // warm up
	
	  rampUsersPerSec(6).to(100).during(3.minutes) // lezzz go!!!
	),
	buscaInvalidaPessoas.inject(
	  constantUsersPerSec(2).during(25.seconds), // warm up
	
	  rampUsersPerSec(6).to(40).during(3.minutes) // lezzz go!!!
	)

Em cada cenário, só configuramos que busca é um get pra “/pessoas” ou criação é um post pra “/pessoas”, mas como ele sabe pra onde mandar essas requisições? Pra isso serve aquela configuração que fizemos lá no começo do script, declarando que a URL base é “localhost” porta 9999 lembram? No final do setup, plugamos essa configuração. E pronto, é isso! Vamos ver rodando.

Pra ficar claro, tenho um terminal dividido em dois, usando split horizontal do TMUX. Na metade de cima, estamos no projeto do Lucas Poole em Node. Podemos chamar “docker compose up” e esperar os serviços todos subirem. Na metade de baixo, estou no diretório de “stress-test” do repositório da rinha, onde tem o script “run-test.sh”, que vamos rodar agora. Pronto, passa aqueles 25 segundos de aquecimento e aí começa a brincadeira. Agora é esperar os 3 minutos dos cenários.

Lembram que o script configura 3 cenários? Estão aqui: Busca Inválida, Busca Válida e Criação. Em cima tem um resumo, embaixo tem um pouco mais detalhado. O principal: OK são requisições que devolveram códigos http válidos de resposta, como 200, 400 ou 422. Tudo que devolveu erro, código 500, timeout, acho que ele considera como KO ou Knock Out. São as requisições perdidas.

Voltando, depois de algum tempo rodando, quando a carga apertar mais pro fim, em vários dos projetos participantes, vamos ver este erro sendo reportado: java.io.IOException: Premature Close. Esse é o erro que o Vinicius Ferraz descobriu como consertar mudando de network_mode bridge pra host. Olha só o que essa mensagem está dizendo: mais de 9 mil requisições perdidos nesse exceção. 9 mil, num total de pouco mais de 100 mil requisições, é um número considerável, quase 10% de erro.

Vamos abrir o gráfico que o Gatling gera. No mundo ideal gostaríamos de ver somente essa barra verde, sem nada vermelho do lado. Mas temos vermelho. Olhando aqui na tabela veja só, de um total de 108 mil requisições, tivemos quase 99 mil que deram OK, mas quase 10 mil em vermelho, que deram knock out. Já volto nessa tabela, vamos olhar mais pra baixo os gráficos.

Lembram como configuramos pra iniciar os três cenários em paralelo, pra ir subindo de 6 usuários pra mais de 600 simultâneos por segundo? Um ramp up? Por isso o formato do gráfico é um triângulo. Começa com 6 usuários por segundo e vai subindo, ramping up, com aceleração constante, aumentando a velocidade linearmente, até mais de 600 usuários. Por mais de 2 minutos, mais de dois terços do tempo, cresce sem problemas. Mas aí olha essa parte final.

O final é cheio de “sobes e desces”, esse serrilhado. Aqui a aplicação tá claramente engasgando. Muitas requisições em fila não conseguem ser atendidos, ou demoram demais pra responder, ou dão timeout de tanto esperar. Por isso, no último gráfico, começamos a ter várias áreas vermelhas. Lembrando que muitos desses vermelhos são os IOException de Java que mencionei antes.

Mas será que realmente faz tanta diferença assim? Pra demonstrar, podemos modificar o código do Lucas pra usar network mode host. Começamos mudando o “index.js” que carrega o node.js na porta 8080, hardcoded, e trocar por uma variável de ambiente chamada “HTTP_PORT”, que podemos configurar no docker compose.

@@ -62,6 +62,7 @@ app.get('/contagem-pessoas', (_, res) => {
 app.use(errorHandler);

 const numForks = Number(process.env.CLUSTER_WORKERS) || 1;
+const httpPort = Number(process.env.HTTP_PORT) || 8081;

 if(cluster.isPrimary && process.env.CLUSTER === 'true'){
     logger.info(`index.js: Primary ${process.pid} is running`);
@@ -74,8 +75,8 @@ if(cluster.isPrimary && process.env.CLUSTER === 'true'){
         logger.info(`index.js: worker ${worker.process.pid} died: code ${code} signal ${signal}`);
     });
 } else {
-    const serverApp = app.listen(8080, () => {
-        logger.info(`index.js:${process.pid}:Listening on 8080`);
+    const serverApp = app.listen(httpPort, () => {
+        logger.info(`index.js:${process.pid}:Listening on ${httpPort}`);
     });

Agora adicionamos essa variável no docker compose e colocamos network_mode host em todos os serviços, como neste trecho de código. Veja como também mudamos a URL de conexão com o banco de dados pra ser localhost. Não vai mais ter NAT pra um host virtual chamado “postgres”. A rede virtual do Docker possui um DNS interno, que traduz nomes como “postgres” pro endereço virtual, no modo de rede virtual. Em modo host, o container se pendura direto no localhost, por isso temos que nos preocupar com conflito de portas agora.

@@ -1,17 +1,19 @@
 version: '3.4'
 services:
-  app1: &app
+  app1:
     # image: lukas8219/rinha-be-2023-q3:latest
     build: .
     hostname: app1
     environment:
-      DB_URL: "postgres://postgres:12345678@postgres:5432/postgres"
+      DB_URL: "postgres://postgres:12345678@localhost:5432/postgres"
       DB_POOL: 35
       PINO_LOG_LEVEL: "debug"
       REQ_TIMEOUT: "2000"
       NODE_ENV: production
       CLUSTER: true
       CLUSTER_WORKERS: 5
+      HTTP_PORT: 8080
+    network_mode: host
     expose:
       - "8080"
     depends_on:
@@ -27,8 +29,32 @@ services:
           cpus: '0.5'
           memory: '0.6GB'

A última coisa, depois de ajustar o docker compose, é ajustar a configuração do nginx. Repetindo, não tem o DNS interno da rede virtual, tudo é localhost, então temos que mudar os servidores upstream do proxy reverso pra ser localhost. Subimos uma instância da aplicação na porta 8080 e outra na 8081, pra não conflitar.

@@ -11,8 +11,8 @@ http {
     error_log /dev/null emerg;

     upstream api {
-        server app1:8080;
-        server app2:8080;
+        server localhost:8080;
+        server localhost:8081;
         keepalive 500;
     }

Pronto, não mostrei configuração dos demais serviços no docker compose mas já deve ter dado pra entender, né? Fica de exercício repetir essa modificação em um dos projetos da rinha. Eu mesmo contribuí pull requests em vários dos projetos participantes justamente pra adicionar essa pequena otimização. Se eu consegui, vocês também conseguem. Agora podemos subir com “docker compose up” de novo e, se não tiver nenhuma mensagem de erro, no outro terminal podemos rodar o Gatling de novo. Não vou mostrar rodando tudo de novo, vamos direto pro final.

A última coisa que o script de Gatling faz é chamar o endpoint “/contagem-pessoas”. Da última vez tinha voltado que conseguiu gravar no banco uns 40 mil registros. Mas agora, olha a diferença, devolveu quase 47 mil registros. É uma diferença considerável. Se voltarmos nos resultados que estavam aparecendo no terminal, olhem, não tem mais aquela mensagem de Premature Close do IOException de Java. Vamos abrir os gráficos.

Vou colocar o anterior na esquerda e o novo na direita. Mesmo aplicativo, única coisa que mudou na direita é que subimos docker compose com os serviços em modo de rede host. De cara já podemos ver que a barrinha vermelha sumiu. Ótimo sinal. Apareceu um pouco de laranja. O que antes tava dando vermelho, agora demora mais, mas vai até o fim e responde. Isso que é laranja. Olha a tabelinha mais pra baixo, antes conseguíamos só um total de 108 mil requisições, agora conseguimos mais de 115 mil requisições. Mais importante: antes teve um total de quase 10 mil knockouts, mas agora foram só uns 150. Diferença brutal.

Dando um zoom aqui do lado, tem um conceito que acho importante que todos entendam. Praticamente todo iniciante pensa em tempo de resposta médio. Média é esta coluna aqui pro fim, “mean”. O que é média? É tabular quanto que levou pra responder cada uma dessas 115 mil requisições, somar tudo e dividir pelo total de requisições. Esse tempo deu 879 milissegundos. Quase 1 segundo por requisição. Se tinha alguma dúvida, esse tempo de resposta é absurdamente lento. Qualquer coisa acima de meio segundo é inaceitável em qualquer aplicação. O certo é sempre manter menos que 100 ou 50 milissegundos.

Veja logo do lado, desvio padrão de 1.7 segundos. O desvio padrão é maior que a média. Só um desvio padrão pro lado e já estamos falando de mais de 2 segundos por requisição. É uma ordem de grandeza inteira. O que isso diz sobre sua aplicação? Nada importante. Vamos entender os números das colunas anteriores, que são mais interessantes.

Olha aqui, 99th percentile. Essa coluna diz o tempo que levou pra responder o 1% das requisições mais lentas nesse teste. Isso dá mais ou menos 1.150 requisições. Soma o tempo delas, divide por 1.150 e isso dá quase 8 segundos. E faz sentido, provavelmente são as últimas mil e tantas requisições desse teste de carga, quando nos aproximamos dos 600 usuários por segundo que configuramos no cenário do Gatling.

Descemos pro 95th percentile, os 5% mais lentos. Já cai pra pouco mais de 5 segundos por requisição. Vamos pro 75th percentile, os 15% mais lentos, já cai pra faixa de 1 segundo por requisição. Veja como os tempos caem drasticamente. No 50th percentile, a média da metade mais lenta de requisições, é na faixa de 2 milissegundos. Vamos olhar nos gráficos lá embaixo pra ter uma noção melhor disso.

Olha esse primeiro gráfico, vejam com os tempos de resposta por requisição se mantiveram super baixo, lá na casa dos 2 milissegundos por quase todo o teste de carga. Lembrando que configuramos o Gatling pra ir subindo de 6 usuários por segundo até 600 ao longo de 3 minutos. Por mais de 2 minutos, nosso setup segurou super bem, quase não varia esse tempo, mesmo aumentando quantidade de pessoas. Mas aí começa o desespero. Veja como os tempos de resposta aumentam drasticamente, salta pra faixa de 5 segundos, tenta cair, mas volta a subir até quase 10 segundos.

No gráfico logo abaixo temos o número de requisições por segundo. De novo, como estamos subindo número de usuários linearmente, o número de requisições também sobe linearmente e, se tivesse recursos sobrando, esse gráfico seria perfeitamente linear até o fim. Mas naquele mesmo trecho, onde os tempos de resposta sobem, começa a ficar serrilhado, até dar um crash drástico na quantidade de requisições por segundo que conseguimos responder.

O gráfico em azul é o número de requisições que conseguimos aceitar, já o gráfico abaixo é o número de respostas que nossa aplicação conseguiu devolver. Verde são os OK, vermelho são os knockouts. Graças ao modo de rede host, veja como quase não tem vermelho, mas se olharmos o gráfico anterior, veja como tinha muito mais vermelho nessa faixa de respostas.

Voltando pra tabelinha, entendam: média de tempo de resposta por requisição não diz nada. Média de 879 milissegundos por requisição. Não diz nada. Agora, lendo o gráfico sabemos que a requisição que mais demorou pra ser respondida demorou mais de 9 segundos, que é essa coluna de máximo. Sabemos que apesar de 5% das requisições ter demorado pra caramba, na faixa de 5 segundos, a grande maioria conseguiu ter resposta na faixa de 2 milissegundos, o que é excelente.

O que causou essa lentidão de segundos na faixa do 95th percentile, não é problema de código, mas limitação de recursos da infraestrutura mesmo. Não tem muito mais que se possa fazer em código pra encurtar tempo de forma significativa. Eu sei, porque eu tentei, em 16 linguagens, lembram do outro video? É mais fácil aumentar os recursos, um pouco mais de CPU, um pouco mais de RAM.

Por outro lado, se no 50th percentile os tempos estivessem na faixa de 1 segundo ou mais. Aí sim, o problema seria definitivamente no código, um gargalo que precisaria ser corrigido. Vocês precisam rodar benchmarks assim em diversos tipos de projetos, diversos tipos de endpoints, pra começar a ter noção de que tipos de tempos de resposta mínimo, máximo, 95th percentile e 50th percentile, são considerados bons ou ruins.

Esses números são importantes pra ajudar a decidir se vale a pena perseguir otimização de código ou simplesmente alocar mais hardware. Seu “achômetro”, sem números, não vale nada. “Ah, eu acho que temos que reescrever esse código em outra linguagem”. Me mostre os números. Se não é capaz de gerar estes números, eu sei que também é incapaz de reescrever qualquer coisa pra ficar melhor.

Achei bacana esta rinha ter dado ênfase em um desafio de backend baseado em benchmark e teste de carga. Eu acho que todo bom programador sempre tem uma ferramenta de benchmark guardado na manga pra usar justamente em momentos de decisão como o que falei antes: vale a pena parar pra otimizar? Quanto de melhoria estamos esperando ter ao custo de quanto tempo pra arrumar? Só aumentar máquina resolveria? Faça medições pra saber.

Eu não conhecia o Gatling, mas achei uma ferramenta muito boa, especialmente porque gera gráficos fáceis de ler e de mostrar pros outros. Existem outras ferramentas que eu usava mais antes, como o antigo Apache Bench ou o WRK que acho que fala “work”. Pra mim esses dois eram tão essenciais quanto saber usar wget ou curl. Recentemente mexi um pouco no tal de Vegeta também, que parece ser mais na categoria do Gatling. E tem dezenas de outros, open source e comerciais. Não deixem de fuçar as opções e testar todas que puder.

Espero que tenham entendido até aqui, porque agora acho que vai ficar um pouco mais complicado, no sentido que vou discutir conceitos de mais alto nível. Se começar a achar que complicou, é a mesma coisa de sempre, anotem os termos que não entenderam e pesquisem. Depois voltem e vejam se conseguem acompanhar o raciocínio até o fim. Até agora foi mais um aquecimento.

Eu deixei de lado banco de dados até agora pra poder atacar esse assunto de uma só vez agora. Eu já fiz um video falando mais sobre como bancos de dados funcionam por baixo, então recomendo que assistam lá se não viram ainda. Ter na cabeça essa estrutura vai ser importante pra entender o que vou explicar agora.

Como disse no primeiro video da rinha, o erro que quase todo mundo cometeu neste desafio foi subestimar o Postgres. Se fosse MySQL teria sido a mesma coisa: nós teríamos achado que seria o gargalo. Isso porque na nossa experiência em projetos de verdade, na maior parte do tempo, o gargalo costuma ser o banco de dados. Por que?

Porque em sistemas mais realistas, com centenas de tabelas, milhares de índices, milhares de relacionamentos entre tabelas, qualquer operação de insert ou update costuma mexer não só em uma linha de uma única tabela, mas pode acionar triggers, gatilhos, pra rodar procedures em outras tabelas. Pode acionar gatilho pra atualizar múltiplos índices. Então nenhuma operação é “simplesmente” só mexer uma linha, normalmente são múltiplas operações acontecendo em múltiplos lugares diferentes. Isso custa tempo, às vezes pode levar dezenas de milissegundos.

Mesma coisa queries, selects. Em sistemas complexos normalmente temos queries com vários inner joins, outer joins, sub-selects, unions. Toda consulta, na realidade, precisa acionar diversos índices, fazer alguns table scans, então pode demorar, talvez dezenas de milissegundos. Pra piorar temos o custo por conexão. No caso de um postgres, cada conexão ao banco pode custar na faixa de 2 a 4 megabytes. 100 conexões poderiam exigir quase meio gigabyte de RAM.

Por isso precisamos usar pools de conexão pra reciclar conexões. Quando uma requisição termina de ser respondida, o framework devolve a conexão livre pro pool. Assim, outra requisição pode reusar a mesma conexão, sem precisar alocar mais 4 megabytes extras toda vez. Quando estamos falando de milhares de requisições por segundo, megabytes se tornam gigabytes muito rápido, se não tomarmos cuidado.

Lembram do nosso gráfico? Eu disse que uma resposta levar 2 milissegundos é muito bom. Mas se levar 10 milissegundos só pra inserir um registro numa tabela, não vai ser ruim? Vai sim. Por isso em projetos de verdade usamos diversas estratégias pra economizar processamento no banco o máximo possível. Usamos pelo menos dois tipos de estratégia: uma pra leitura, onde cacheamos resultados, pra evitar toda hora repetir as mesmas queries pesadas, e estratégia de filas de jobs assíncronos, pra evitar metralhar o banco com operações demais de gravação e modificação.

Lembrando: toda operação de modificação bloqueia um ou mais registros em uma ou mais tabelas no banco. Por cima desses locks temos transações, logs transacionais pra, caso de aconteça alguma pane, a gente não tenha perda de dados, sem deixar nada corrompido. Toda essa proteção custa processamento e custa tempo. Toda pesquisa sendo feita em tabelas que estão constantemente sendo modificadas significa que uma operação de leitura fica concorrendo com uma operação de escrita por esses locks. Ou seja, se não tivermos controle e recebermos um volume grande demais de escritas, ao mesmo tempo várias leituras, tudo vai ficar lento até parar.

Por isso precisamos desafogar o banco de dados. Dá pra criar servidores separados de réplicas somente de leitura. Dessa forma, podemos separar um banco mestre só pra escrita e bancos só de leitura, pra onde podemos mandar as queries. Mas réplicas não saem de graça: quanto mais réplicas colocar, maior o peso pra manter eles sincronizados. Quando falamos em cache estamos falando em serviços em paralelo como Memcache ou Redis. Até na AWS existe o serviço ElastiCache, que é uma interface pra memcache ou redis como serviço.

No caso de filas, alguns usam Nats ou Redis como gerenciador de fila. Funcionam, mas não recursos avançados. Não oferecem muitas das garantias de um sistema de filas maior. Assim como um banco relacional deve oferecer as proteções ACID, uma fila de verdade precisa de garantias, por exemplo, garantindo que um elemento na fila nunca vai ser duplicado. Filas de verdade são coisas como o lendário RabbitMQ ou o mais popular Apache Kafka. AWS também tem um serviço, o SQS, que é o Simple Queue Service.

No caso do cache a ideia é simples: primeiro pergunta pro cache se ele tem a resposta. Se não tiver, aí manda a query pro banco de dados, daí guarda o resultado no cache pra próxima vez. Dessa forma, o banco não precisa ficar sendo redundante e gastar processamento pra responder o que já acabou de responder. O Cache é uma memória temporária pra diminuir a carga de pesquisa.

No caso de filas a ideia é um pouco mais complicada: em vez de metralhar o banco de dados com operações de modificação, jogue todas essas operações numa fila. Configure um número limitado e controlado de trabalhadores, workers, que ficam escutando essa fila, e vão puxando essas operações. O número de workers é o número de conexões que sabemos que o banco aguenta sem começar a ficar muito lento.

Tudo isso eu já expliquei no episódio de “Tornando sua App Web mais rápida” e também no episódio onde sugiro como o site Ingresso.com poderia melhorar sua arquitetura. E sabendo de tudo isso, claro, como as instruções da rinha pediam pra limitarmos o uso de recursos do Docker pra no máximo 1.5 CPU e 3 giga de RAM, e sabendo que vai rodar um teste de carga com milhares de inserts e pesquisas simultâneas, o primeiro instinto foi pensar: bora já garantir e colocar cache nas pesquisas e filas e jobs pros inserts.

Eu fiz isso na minha primeira versão de Ruby on Rails, que vocês podem ver no meu GitHub, e como vimos no episódio anterior, diversos projetos que eu avaliei fizeram algo similar. Alguns colocaram só cache de redis. Alguns tentaram adicionar algum tipo de fila. Mas o fato é que se pararmos pra pensar friamente no que exatamente é este projeto e qual é a carga, já dá pra saber que qualquer coisa mais sofisticada assim era matar uma mosca com bazuca.

Esses projetinho inteiro tem uma única tabela. Só uma. Não tem relacionamento nenhum, não tem chave estrangeira, não tem joins, nada. Lembram daquela planilha de dados aleatórios que o script de Gatling usa pra fazer os inserts? Quantas linhas tinha? 100 mil? Eu diria, “só” 100 mil, e durante os 3 minutos de carga, qual é o total de requisições? Umas 100 mil mesmo. Qual é a contagem final de registros inseridos? Faixa de 45 a 50 mil registros. Entenda, isso é absurdamente pouco. Ordem de poucos milhares de registros é quase nada. Qualquer computador furreca dos anos 80 sabe lidar com milhares de registros.

Um banco com uma única tabela de míseras 50 mil linhas, sofrendo não mais que 100 mil tentativas de inserts, é algo miseravelmente pequeno. Bancos de dados de verdade tem centenas de tabelas, a maioria com centenas de milhares de linhas, muitas com milhões, dezenas de milhões de linhas. Isso sim começa a parecer “grande”. Uma única tabela é um hello world.

Portanto, apesar de ser divertido de implementar, nem cache de leitura, nem fila de jobs de escrita era realmente necessário. Bastava usar o banco normalmente. Um Postgres é mais do que capaz de fazer inserções simples assim de forma extremamente rápida. Na verdade vai ser na mesma ordem de grandeza de tempo do que escrever num banco de cache como Redis, por isso não faz diferença nesse caso. Só faz diferença usar Redis quando a escrita for ordens de grandeza mais rápido porque o Postgres está tendo que lidar com operações muito pesadas em cima de um volume realmente grande de dados.

Entenderam? Muita gente ainda pensa que Redis ou Memcache é automaticamente mais rápido do que qualquer banco de dados. Isso não é verdade. Um banco de dados quase vazio vai ser tão rápido quanto um Redis. Mesma coisa se você exagerar e colocar coisa demais no Redis, ele vai ficar lento também. Nada é automático em programação. Se você encarar dessa forma, tudo que fizer sempre vai sair uma droga. “Ah, mas o Redis não devia cuidar de tudo sozinho e ser mais rápido??” Lógico que não, idiota.

Mas havia de fato um pequeno fator de preocupação. Na API de pesquisa por termos, a rinha pede pra pesquisar ou no campo de nome ou no campo de apelido ou no campo de tecnologias. Ficaria um select com ILIKE “%blabla%” OR ILIKE “%blabla%”, que é simplesmente um dos piores tipos de pesquisa que se pode fazer em SQL.

Por causa desses porcentos no começo e no fim, significa que não temos como usar um índice. Índices funcionam pra pesquisas exatas. Pesquisa parcial, o único jeito é fazer pattern matching em todas as linhas da tabela. Uma vez pra cada campo depois de “OR”. Como temos três campos pra pesquisar, vão ser três table scans por todas as linhas da tabela até aquele ponto. Isso pode ficar pesado muito rápido sem você perceber. Se num determinado momento a tabela tiver 10 mil linhas, vamos ter que fazer 30 mil operações de comparação. E quanto maior fica a tabela, mais longa fica a pesquisa. E qual a solução?

Recomendo assistirem depois o episódio do código vazado do algoritmo do Twitter, onde eu faço uma tangente pra explicar o que é full-text search, ou pesquisa por embeddings em espaço vetorial. Não vou repetir o que expliquei lá, mas é o que está por baixo de como um Google ou Bing conseguem responder qualquer pesquisa tão rápido e com os resultados mais relevantes logo no topo da primeira página de resposta. Todo banco de dados moderno tem suporte a algo similar, e isso é chamado de “full text search”.

No caso do Postgres existem duas técnicas mais conhecidas: GIN e GIST. GIN significa Generalized Inverted Index ou Índice Invertido Generalizado e é mais recomendado pra estruturas de dados complexas como arrays, JSONB, hstore. É otimizado pra pesquisas de múltiplas chaves e permite indexação dos valores individuais de um array, chaves de um JSONB e assim por diante. O índice GIN é construído ao extrair chaves dos valores indexados e criando uma lista de postagem, uma lista ordenada de ponteiros para as linhas indexadas.

GIST vem de Generalized Search Tree ou Árvore de Procura Generalizada. GIST é uma técnica de indexação de uso mais geral e requer a implementação de métodos de procura customizadas. Pode ser usado pra indexar praticamente qualquer tipo de dados no Postgres, incluindo dados espaciais, tipos de dados customizados e qualquer tipo de texto. Índices GIST são caracterizados por uma estrutura hierárquica de nós.

Podemos somar GIST com o suporte a uma extensão de trigramas. LEu explico sobre n-grams no video do Twitter. Vamos mostrar na prática o que todo esse mambo jambo significa. Pra isso vou abrir o código que cria a tabela no banco. O Lucas fez bem em adicionar esse código no Node.js. Ele inicia importando a biblioteca “pg” e cria um Pool de conexões usando a URL de conexão que vem da variável de ambiente DB_URL no docker compose.

const pg = require('pg');
const { logger } = require('./logger');

const URL = process.env.DB_URL || 'postgres://postgres:12345678@localhost:5432/postgres';

const pool = new pg.Pool({ connectionString: URL,
    max: (Number(process.env.DB_POOL) || 200),
    idleTimeoutMillis: 0,
    connectionTimeoutMillis: 10000
    });

Daí registra um evento no pool, o evento “connect”, que diz: assim que conectar, execute a função anônima a seguir, que vai enviar uma query pro pool. Essa query são comandos em SQL. Como temos duas instâncias de Node subindo ao mesmo tempo, em ambos vai executar essa função, então precisamos escrever os comandos pra, caso já exista o que queremos criar, só ignora e segue em frente.

pool.once('connect', () => {
    logger.info(`database.js: Connected  to db ${URL}`)
    logger.info(`Creating table "pessoas" if not exists`);
    return pool.query(`
        CREATE EXTENSION IF NOT EXISTS pg_trgm;

        CREATE OR REPLACE FUNCTION generate_searchable(_nome VARCHAR, _apelido VARCHAR, _stack JSON)
            RETURNS TEXT AS $$
            BEGIN
            RETURN _nome || _apelido || _stack;
            END;
        $$ LANGUAGE plpgsql IMMUTABLE;

Por exemplo, o primeiro comando diz: “se já não existir, crie a extensão pg_trgm”, que é a extensão que dá suporte a tokenizar textos em trigramas. Em seguida, “crie ou substitua caso já exista, a função generate_searchable, que recebe os parâmetros nome, apelido e stack, todos de tipo varchar”. Lembram? Varchar é variable characters, uma lista de caracteres de tamanho variável, basicamente uma string.

A função retorna um valor de tipo texto, e esse texto vai ser a concatenação dos campos nome, apelido e stack, tudo junto. Mas pra que isso? Paciência que já vai entender. Na sequência, caso não exista, criamos uma tabela com nome “pessoas”, que é a tabela principal. Primeiro campo se chama “id” de tipo UUID. Opcionalmente podemos declarar que se não passarmos um valor explicitamente, pra gerar um uuid aleatório usando a função gen_random_uuid(), além disso a constraint é que esse campo deve ser único e não nulo.

CREATE TABLE IF NOT EXISTS pessoas (
	id uuid DEFAULT gen_random_uuid() UNIQUE NOT NULL,
	apelido TEXT UNIQUE NOT NULL,
	nome TEXT NOT NULL,
	nascimento DATE NOT NULL,
	stack JSON,
	searchable text GENERATED ALWAYS AS (generate_searchable(nome, apelido, stack)) STORED
);

Em seguida, declaramos o campo apelido como sendo tipo texto, também único e não nulo. Campo nome deve ser tipo texto e não nulo. Campo nascimento deve ser tipo Date e não nulo. Campo stack deve ser tipo JSON, que é uma das vantagens de usar Postgres, porque ele permite tipos de dados mais complexos como JSON. Não precisa de MongoDB pra isso. E, finalmente, declaramos uma coluna especial, de nome “searchable” e tipo text.

Só que esse campo declaramos como um campo “generated”. É um campo cujo valor vai ser gerado automaticamente em toda operação de insert ou update e vai usar o retorno desta função que declaramos antes, o generate_searchable. Lembram o que ela faz? Devolve os valores de nome, apelido e stack concatenados. É isso que esse campo vai ter. Mas por que?

O próximo comando SQL é, caso não exista, pra criar um novo índice chamado idx_pessoas_searchable, na tabela pessoas, usando GIST. Ao GIST dizemos pra indexar aquela coluna “searchable” usando o operador de classe “gist_trgm_ops”, que é especificamente desenhado pra tokenizar esse campo em trigrams, que são conjuntos de 3 caracteres, quebrados, ou tokenizados, de cada palavra da string. É isso que permite pesquisas parciais.

CREATE INDEX IF NOT EXISTS idx_pessoas_searchable ON public.pessoas USING gist (searchable public.gist_trgm_ops (siglen='64'));

O objetivo dessa coluna é evitar ter que fazer nome like blabla “OR” apelido like blabla “OR” stack like blabla. Não precisamos mais de “OR”. Basta fazer searchable like blabla e pronto. Se qualquer um desses campos conter o blabla, vai retornar. “OR” custa caro, sempre que puder evitar, evite, mesmo que signifique desperdiçar espaço. Pode ser um tradeoff que vale a pena. Pesquisa com porcento, wildcard, também custa caro. Agora vamos ver a função no projeto do Lucas pra pesquisa de termos. Fica mais pra baixo, a função “findByTerm”.

module.exports.findByTerm = async function findByTerm(term) {
    const query = `
    SELECT
        id,
        apelido,
        nome,
        to_char(nascimento, 'YYYY-MM-DD') as nascimento,
        stack
    FROM
        pessoas
    WHERE
        searchable ILIKE $1
    LIMIT 50;`
    return pool.query(query, [`%${term}%`]);
}

Olha só, definimos o template da query com um string. Select os campos id, apelido, etc, from tabela pessoas, where searchable like $1, limitado a 50 linhas de resposta. Esse “$1” vai ser substituído por esse valor aqui embaixo, que é o termo concatenado com porcentagem no começo e no fim. Ué, mas isso não era lento de pesquisar? Vamos entender.

Todo banco de dados relacional possui um comando pra explicar como que uma query vai ser executada, a estratégia de pesquisa. Pra ver isso, podemos conectar com o cliente de linha de comando do postgres, o psql. Então podemos nos conectar com “docker exec -it node-postgres-1 psql -U postgres -d postgres” e pronto.

Vale lembrar que estou conectando no postgres logo depois de rodar o teste de carga, portanto a tabela já está com mais de 46 mil linhas inseridas com sucesso. Vamos começar analisando uma query simples. Eu mando “explain analyze” seguido da query “select * from pessoas where apelido = ‘foo’”. Como esperado, essa coluna apelido já tem um índice, então ele corretamente diz que vai fazer um “index scan” no índice “pessoas_apelido_index”. Pesquisa utilizando índice costuma ser muito rápido e podemos ver o Execution Time aqui no final dizendo que levou só 0.037 milissegundos, 37 microssegundos, super rápido.

Esses outros números aqui em cima, por exemplo em cost, ou custo, o primeiro é o custo relativo pra puxar a primeira linha do resultado, esse 0.41 e esse 8.43 é o custo relativo pra puxar o resto das linhas. Mesma coisa esse actual time, é o tempo pra puxar a primeira linha e depois o tempo pra puxar o resto das linhas. Uma das razões pra ele distinguir a primeira linha do resultado pro resto é pra dar noção da latência que sua aplicação vai ter entre mandar fazer a pesquisa e o primeiro resultado que volta no streaming e que já poderia ser mostrado.

Como esta query usa um índice e a quantidade de linhas é absurdamente pequeno, leva 16 microssegundos até puxar a primeira linha e pouco mais de 16 microssegundos pra puxar todo o resto. É muito rápido mesmo. Mas agora vamos ver quão mais lento seria a pesquisa por termos do jeito que a grande maioria dos programadores iniciantes faria. Olha só: explain analyze select * from pessoas where apelido ilike '%foo%' or nome ilike '%foo%' or stack::text ilike '%foo%'.

Olha o tempo que leva pra executar essa query: 42 milissegundos, ou 42 mil microssegundos. Comparado com a query simples anterior estamos falando de um tempo de resposta mais de mil vezes mais lento. Sim, 42 milissegundos ainda é relativamente rápido, mas considerando que eu falei que essa tabela é absurdamente pequena, e queries baseadas em índice conseguem acabar na ordem de microssegundos, 42 milissegundos é um tempo longo.

Olha só a estratégia que ele diz que essa query vai ser obrigada a usar: “seq scan” que é scan sequencial, literalmente um full table scan. Imagine um loop com for indo da linha 0 até a linha 46 mil e tanto e checando os campos linha a linha. É o pior caso pra uma pesquisa em banco, que é checar tudo, sem poder usar índices. Você quer evitar esse tipo de query como diabo foge da cruz, porque quanto maior ficar sua tabela, mais lento sua pesquisa vai ficar. Com índice não, você pode dobrar o tamanho da tabela e o tempo da query quase não muda.

Será que tudo isso que fizemos de criar o campo searchable concatenando os campos nome, apelido e stack e depois indexando usando Gist com Trigrams faz alguma diferença? Não podemos só chutar e dizer que sim sem testar. Então vamos lá: explain analyze select * from pessoas where searchable ilike '%foo%' e olha só, é mais rápido sim.

Caímos de 42 milissegundos pra só 4 milissegundos. É pelo menos 10 vezes mais rápido. E olha a estratégia de pesquisa. Não tem mais um sequential scan como antes. Em vez disso tempos um Bitmap Heap Scan. Essa estratégia é dividida em duas e começa primeiro com um Bitmap Index Scan, que vai usar o índice que fizemos usando Gist com Trigram. Nessa fase teremos uma certa quantidade de linhas de resultado. Essas linhas vão ser marcadas num mapa de bits, um bitmap, e na segunda fase de pesquisa, ela vai filtrar só as linhas marcadas, usando essa condição de rechecagem que mostra na estratégia.

Ou seja, ainda tem uma fase de scan de linhas, mas não é na tabela inteira, só nas linhas retornadas na primeira etapa de pesquisa pelo índice. Neste caso, o índice sozinho não dá a resposta toda, por isso existe o Bitmap Heap Scan. É mais lento do que um Index Scan, como no primeiro exemplo que testamos, mas é bem mais rápido do que um full sequential scan.

Portanto sim, valeu a pena tudo isso de GIST. E é uma boa dica pra qualquer projeto. Em projetos maiores, onde estaríamos usando coisas como cache em Redis, também poderíamos delegar pesquisa full text pra outro serviço externo. Eu sempre recomendo o bom e velho ElasticSearch. O Elastic é como se fosse um banco de dados NoSQL especializado em full text search. Povo de monitoramento e devops também costuma integrar ElasticSearch com serviços como Kibana, Logstash, pra fazer pesquisa em logs, por exemplo.

Elastic é pra quando seu projeto crescer e recursos como GIST já não estarem segurando a carga de processamento no banco. Nunca faça overengineering nos primeiros dias de um projeto. Só especialize em serviços externos quando tiver carga pra justificar isso. Quanto mais serviços externos, mais difícil vai ser pra dar manutenção em tudo. É um trade-off. Tudo tem seu tempo, e não é no dia 1.

De qualquer forma, vocês começaram a entender? Uma operação simples SQL num Postgres sem tuning nenhum, rodando na minha máquina, é da ordem de microssegundos. Muito menos de 1 milissegundo. Bancos de dados foram feitos pra serem rápidos. Assistam meus episódios sobre Árvores e Banco de Dados. É muito mais do que só apendar uma linha nova no final de um arquivo.

Outra técnica que eu tinha deixado pra comentar neste episódio foi sobre o tal SQL Bulk Insert. Muitos dos projetos ganhadores com do Vinicius em Rust ou do André e Albert em C#, fizeram o truque de acumular os inserts ou numa fila externa ou em memória e um job em background ir pegando grupos de inserts e mandando de uma só vez pro banco. Mas realmente não tem muito o que comentar. O conceito é bem simples.

Em vez de toda requisição ter que conectar no banco, mandar um insert, esperar o resultado e daí responder, podemos fazer ele responder sem saber se vai gravar com sucesso ou não. E ir acumulando. Depois que acumular uma quantidade razoável, sei lá, uns 100 inserts, daí manda tudo de uma vez só, dentro de uma única transaction. Só de não ter que criar uma nova transação pra cada insert individual, fora mandar pela rede tudo de uma vez, economiza bastante tempo. Mas como já repeti mil vezes neste episódio, 100 mil tentativas de inserts simples é pouca carga. Acho que pra quase nenhuma dos projetos participantes, realmente precisava ter usado essa técnica, no máximo teria feito pouca diferença não usar.

Bulk insert e também upserts são técnicas importantes. Povo de data warehouse, business intellingence, data science e tudo mais que precisa limpar dados e carregar volumes grandes de uma só vez, sabe que precisa fazer bulk insert, senão desperdiça tempo. Cada banco de dados tem peculiaridades de sintaxe, por isso é melhor que vocês pesquisem no google “postgres bulk insert” ou “postgres batch insert” que os primeiros links explicam direitinho. Não vou ficar repetindo o que já tem fácil em tutoriais simples.

Mais importante é voltarmos pro docker compose e falar da configuração de postgres. Cada participante da rinha fez essa parte de maneiras ligeiramente diferentes, mas no geral todo mundo estava preocupado em mudar este parâmetro: max_connections. A maioria chutava nessa faixa de 450 conexões. Lembram que uma conexão custa uns 2 megabytes? Se realmente usarmos todas as 450 conexões máximas, o container de postgres poderia usar quase 900 megabytes. Isso é coisa demais, considerando que temos só 3 gigabytes pra caber tudo. Por isso não adianta querer subir esse número todo.

Tem algumas formas diferentes de mudar essa configuração. A mais simples é desse jeito mesmo: mudando a linha de comando do postgres e adicionando o parâmetro direto. Outra forma é que nem fizemos com o nginx e criar um arquivo postgres.conf pra mapear como volume pra dentro do container. E outra forma é como criamos a tabela e índices: direto na aplicação, quando ela se conectar pela primeira vez, manda comandos SQL, e um desses comandos seria pra mandar aumentar o máximo de conexões.

Mas a pergunta mais importante é: quantas conexões de fato precisa suportar pro tipo de carga que nosso teste de Gatling vai executar? 450 é mesmo suficiente? Ou menos daria? E se for menos, quanto menos? Se configurar o pool de conexões da aplicação pra deixar já aberto 450 conexões, estaria desperdiçando muita RAM. Se alocar poucas conexões, daí as primeiras requisições vão gastar mais tempo esperando abrir novas conexões. Tem um balanço aqui, e justamente testes de carga servem pra validar se nossas premissas realmente valem na prática.

Pra facilitar nossa vida, já vimos que dá pra conectar na linha de comando do cliente psql pra fazer queries direto no banco. Mas podemos adicionar algumas ferramentas mais visuais pra facilitar tanto sua vida, quanto minha vida aqui de mostrar. A que deixei pra mostrar por último é o pgAdmin, um velho de guerra que usamos faz mais de década, desde antes de Docker ter sido inventado. É muito simples, basta adicionar este serviço no seu docker compose:

  pgadmin:
    image: dpage/pgadmin4
    environment:
      PGADMIN_DEFAULT_EMAIL: admin@admin.com
      PGADMIN_DEFAULT_PASSWORD: admin
      PGADMIN_LISTEN_PORT: 5050
    network_mode: host
    depends_on:
      - postgres

Email e senha tanto faz, é só porque vai subir uma interface web de administração. Importante é declarar essa porta 5050, porque senão ele vai tentar subir na porta 80, e como estamos em modo de rede host, vai tentar subir na porta 80 de verdade do localhost, e não vai ter permissão sem ser root, então vai falhar no boot. Mude pra uma porta acima de 1000 qualquer, como 5050.

Agora podemos subir “docker compose up” e esperamos alguns segundos. Vamos acelerar e pronto, no navegador do lado podemos carregar localhost 5050 e olha só que bonito. Só colocar o mesmo email e senha que configuramos e estamos dentro. Depois fucem essa interface e leiam a documentação no site deles pra saber o que é o quê. Mas já deixo um aviso importante: apesar de útil, nunca, jamais, deixe um serviço como esse exposto na internet pública.

Seria uma tremenda burrice deixar isso desprotegido porque se alguém conseguir entrar, vai ter acesso ao seu banco de dados de produção. Nada de nenhum banco de dados de produção jamais pode aparecer na internet pública. É pedir pra ser invadido. Suba temporariamente em produção pra alguma tarefa em específico, mas retire do ar o quanto antes. Use em ambiente de staging, em ambiente de desenvolvimento, em rede privada da empresa, dentro de uma DMZ, mas nunca na internet pública. Sem mais, nem menos, vocês foram avisados.

Enfim, eu já tinha cadastrado o postgres que estávamos usando nos testes, mas deixa eu cadastrar de novo pra vocês verem como é. Dêem um nome qualquer, endereço é localhost, usuário é postgres, senha é a mesma que você configurou no docker compose e pronto, conectado. Mas e daí, o que podemos fazer com isso? Vamos no terminal do lado e rodar o teste de carga do Gatling de novo.

Aqui estou acelerando na edição, mas olhem só que bacana, conseguimos ver em tempo real o monitoramento de coisas como transações por segundo. Vou avançar mais pro meio do teste. Note como o total de transações está em azul mas temos, mais ou menos, meio a meio entre transações que deram commit ok e transações que deram rollback por ter falhado. Isso é simples de explicar.

Lembram que o teste de carga faz um total de umas 100 mil requisições, mas só 46 mil são de fato gravadas? Os outros dão erro porque campos como apelido, nome tem constraints pra serem unique, nunca duplicar. Quando tentamos inserir duplicado, rejeita e dá rollback. Por isso, mais ou menos, meio a meio.

Embaixo podemos ver gráficos pra ter noção do volume de dados entrando e saindo. Cada conjunto de campos, a linha em si, é uma tupla. Temos tuplas entrando, que são os inserts, temos tuplas saindo, que são resultados de queries, temos gráfico de I/O que não tenho certeza da unidade de medida, se são operações de leitura e gravação ou quantidade de bytes ou algo assim.

Mais importante é este primeiro gráfico no topo. Acompanhe em azul, é o total de conexões no banco neste momento. Em verde são conexões onde estão acontecendo operações, como nossos inserts ou selects. Em vermelho são conexões abertas sem fazer nada. Veja como é mais ou menos estável a quantidade de conexões, mesmo sabendo que no teste de carga estamos aumentando gradativamente o número de usuários por segundo, subindo até 600 usuários por segundo.

E essa é a importância de um bom pool de conexões. A mesma conexão é reusada, reciclada, entre várias requisições. Por isso não precisa de tantas. Só bem no finalzinho, bem no final mesmo, quando caímos no território do 95th percentile, talvez 75th percentile, aquele 5 a 15% que demora mais de 1 segundo pra responder, aí aumenta drasticamente o número de conexões abertas ao mesmo tempo. Nesse finalzinho dá impressão que a requisição no Node está tão lenta que não dá tempo de devolver a conexão pro pool, daí precisa ficar abrindo mais e mais conexões.

Essas últimas requisições que demoram mais de 5 segundos, são completamente fora da realidade. Se num produto real estivéssemos tendo tempos nessa ordem de grandeza com frequência, ou precisava ver se falta otimizar alguma coisa, ou precisa urgentemente aumentar os recursos da infra. Não devemos configurar o máximo de conexões no banco, nem o tamanho do pool de conexões baseados nesse pico final.

Ao contrário do que muitos poderiam imaginar, durante quase o teste de carga todo, nunca passou de 40 conexões, ativas ao mesmo tempo, era faixa de 20 conexões. Não é 450, nem 300, nem mesmo 100. Só mesmo no finalzinho, mas aí já era repescagem. Portanto, se alguém chutava que máximo de conexões ao banco seria um gargalo, chutou errado também.

E porque são menos de 40 ao mesmo tempo? Se voltarmos ao docker compose, na configuração da aplicação, veja na seção de variáveis de ambiente. Tem esse DB_POOL que passamos pro pool da biblioteca “pg” usada pelo Node. Neste caso está 35. No caso temos duas instâncias, então seria um máximo de 70. Mesmo assim, durante a maior parte do teste, nenhum dos dois pool nunca é saturado. Só no final. Aí meio que não importa muito se tivéssemos colocar mais ou não. O pico final a infra não aguenta mesmo.

E qual é o melhor número pra colocar no pool de conexões? Cada blog post e stackoverflow que procurar vai vir com alguma fórmula mágica pra tentar chutar. Mas não tem jeito, pra saber de verdade, só fazendo um teste de carga, monitorando via pgAdmin e, via tentativa e erro, rodar o teste de carga pra diferentes valores de tamanho de pool. Esse é o único jeito certo de saber se estamos chutando um número apertado demais ou sobrando demais. Não acredite em nada a não ser testes que você mesmo rodou pra saber.

Isso tudo dito, muitos de vocês assistindo que tem experiência, incluindo vários dos participantes, e eu mesmo, tínhamos certeza que o Postgres seria um problema. Mas agora que medimos e temos dados de verdade, temos certeza que estávamos errados. As técnicas em si funcionam, mas a aplicação e a carga do teste eram muito menores do que imaginávamos. Superestimamos o problema e fizemos overengineering. Típico de programadores fazer overengineering. A lição é simples: faça o código mais simples que resolve o problema dado, faça medições e, só depois disso, decida onde realmente precisa otimizar, e vá medindo pra ver se a otimização realmente melhorou, ou se não piorou.

E isso nos leva aos tópicos finais que faltou discutir da minha lista de pendências. Eu falei que ia comentar sobre Crystal, sobre Kotlin, daí sobre threads e fibers. Mas quero ser breve nesses pontos. Durante o video de 16 linguagens eu quis mostrar que sim, com praticamente todas as linguagens, era possível bater o máximo do teste de carga. Alguns com um pouco mais de trabalho que outros, mas todo mundo era capaz de passar ou chegar muito perto.

Significa que todas as linguagens são igualmente válidas? Ou igualmente performáticas? Claro que não. Vamos usar o bom senso aqui. Obviamente, todas as linguagens compiladas em binário nativo levam vantagem em performance, Rust e Go, principalmente, seguido de C++, Java e seus derivados como Kotlin ou Scala, C#, Crystal, Zig, até Bun. Essa é uma categoria clara de performance nível A.

Linguagens interpretadas, como PHP, Javascript e seus derivados como Typescript, Ruby, Python, todos fazem parte da mesma categoria B de performance. Não é possível atingir o mesmo nível de performance bruta da categoria A. É sim, possível escalar aplicações web pra números parecidos, ao custo de um pouco mais de hardware. Isso porque boa parte de uma aplicação web depende I/O, e I/O vai ser mais lento independente se a aplicação é compilada ou interpretada.

Portanto sim, a infra pra linguagens da categoria B precisa ser um pouco maior do que da categoria A. Mas não é ordens de grandeza maior, esse é o ponto. Do outro lado da equação está a facilidade ou em encontrar bons profissionais ou treinar novos profissionais, e é aí que linguagens da categoria B ultrapassam muito os da categoria A.

Pergunte a qualquer entusiasta de Rust e ele vai dizer que eu estou equivocado, que Rust é muito fácil, que ele aprendeu super fácil. Mas sinto dizer: eu acredito em você, mas seu perfil é diferente da maioria da população. As pessoas não são iguais. Quem acha ficar fluente em Rust algo “fácil” é uma fração minúscula da população. A grande maioria não tem nem a vontade e nem a capacidade pra ficar fluente em linguagens de baixo nível, que exigem um entendimento muito mais detalhado de como tudo por baixo funciona, a rede, o sistema operacional, o hardware.

E isso não é algo inerente só a Rust. Nos anos 80 e 90 nós sempre tivemos, Assembly, C, C++, Objective-C. Mas quais foram as linguagens que ficaram populares? Nos anos 80 eram coisas como Cobol ou dBase. Nos anos 90 eram coisas como Visual Basic ou Delphi. Delphi até era compilado nativo, mas o que atraiu as pessoas era o ferramental, a IDE, o banco de dados Interbase que vinha no pacote. Ninguém usava Delphi pra programar drivers de sistema operacional ou coisas assim.

Agora é a mesma coisa. Tem uma categoria de pessoas que desde sempre achava fácil programar em C, C++, até Assembly, e agora Rust, Go. Pra realmente tirar proveito desse tipo de linguagem, você precisa ser o tipo de pessoa que gosta de aprender intimamente como funciona o hardware por baixo, o sistema operacional inteiro por baixo. Pra categoria B, uma pessoa que não está nem aí e nem sabe a diferença entre memória RAM e SSD, ainda consegue produzir alguma coisa. A curva de aprendizado é nitidamente menor e por isso tem mais gente nessas linguagens da categoria B.

Duh, antes que apareça comentário idiota: óbvio que tem programadores avançados na categoria B também. Mas alguém medíocre, não sobrevive na categoria A. Portanto, é sim possível fazer uma web startup inteira só com Rust ou Go, mas boa sorte em manter uma equipe de dezenas ou centenas de pessoas que escala junto com o crescimento da empresa. Em breve não vai acompanhar. Por isso toda grande empresa de tecnologia usa um misto de tecnologias. Não existe empresa gigante que consegue usar uma única linguagem pra tudo.

E isso sem contar o ecossistema. Produtividade não vem só da linguagem. Vem das bibliotecas, produtos, serviços, documentação, cursos, livros, eventos e tudo mais que circula ao redor da linguagem. É muito mais difícil comparar uma linguagem e dizer só “ah, é compilado” ou “ah, é interpretado”. Essa é a parte que menos importa na comparação.

Tem uma questão cultural também. Deixa eu dar um exemplo bem besta. Todo mundo que é de Javascript está acostumado a ir no terminal e digitar algo como “npx create-react-app my-app”. Quem é de Ruby on Rails está acostumado a ir no terminal e digitar “rails new my-app”. Quem é de Python está acostumado a fazer “django-admin startproject my-app” e assim por diante.

Como que alguém de Java inicia um novo projeto? Vai no site start.spring.io, preenche um fucking formulário, que vai gerar o projeto e te dar um zip pra baixar. Daí você manualmente deszipa e esse é o começo do seu projeto. Quase em 2024, pra mim isso tem cheiro de 2004. Outras linguagens como C# tem opções de linha de comando com dotnetcore, mas como a maioria dessa comunidade prefere realmente fazer? Sim, abrir o Visual Studio Enterprise e clicar em Novo Projeto e ir preenchendo.

Pra gente de Javascript, Ruby, Python, PHP, isso parece super ultrapassado. Mas pra quem é de Java ou C#, parece uma super frescura ter uma linha de comando pra gerar as coisas se o site ou a IDE já fazem tudo. E é aquele caso que depende do ponto de vista. Nenhum dos dois lados nunca vai concordar nisso. Mas é esse tipo de discordância em ponto de vista que vai garantir que nunca tenhamos uma única linguagem e um único ecossistema que vai ser o padrão pra tudo. Eu detesto ter que usar uma IDE. Do que ter que usar IntelliJ ou Visual Studio, eu prefiro mudar pra qualquer linguagem que eu possa ser produtivo só da linha de comando, usando NeoVim. Não é negociável pra mim.

Eu já fiz um video só explicando as diferenças entre linguagens compiladas e interpretadas e explico mais a fundo sobre essas coisas, recomendo que assistam depois. Mas sobre Crystal e Kotlin em particular que eu analisei na rinha. Ambos são linguagens mais novas, com comunidade pequena. No caso de Kotlin, ele já foi criado por uma empresa grande, a JetBrains e depois apoiado pelo próprio Google. E mesmo assim a adoção não é tão grande quanto eu gostaria de ver a esta altura.

De novo, quem está acostumado só com Java não vê grande valor em migrar pra Kotlin. No final o bytecode é compatível, pra que mudar? Pra nós que estamos acostumados com linguagens mais modernas, o Kotlin é uma excelente opção pra quando formos obrigados a fazer alguma coisa na plataforma Java. Vale a pena ficar de olho e ter no seu arsenal. Mas sempre vai haver essa divisão. Eu sinto que Kotlin é mais atraente pra quem não é de Java, do que pra quem já é experiente em Java.

Crystal é muito menor e bem mais de nicho. Mesmo assim eu acho uma linguagem super competente, estável, com um ecossistema mínimo já funcional. Eu acho a sintaxe de Ruby muito superior à de um Go Lang. Me cancelem, mas é verdade. Porém, obviamente Ruby é uma categoria de performance muito inferior a Go. Mas Crystal é realmente a sintaxe de Ruby com performance de Go, mesma ordem de grandeza. Sim, Go ainda é melhor otimizado e por ser uma linguagem mais primitiva, também é mais rápido de compilar.

Mas pra coisas como microsserviços web, eu acho Crystal e frameworks como o Lucky, bem mais prazerosos de usar do que similares em Go ou Rust. Se produtividade for importante e evitar fadiga também, Crystal pode ser uma boa alternativa, especialmente pra equipes pequenas. A curva de aprendizado é menor. Vale ter no arsenal. E eu reforço isso depois de ter experimentado linguagens como Nim, que existe há muito mais anos, mas continua péssimo de usar, super mal documentado, com poucas bibliotecas usáveis e muitos bugs. Parece uma linguagem experimental, que eu não recomendaria pra usar em produção de jeito nenhum.

Dá pra ficar o dia todo só falando das diversas linguagens, e eu já comentei bastante sobre elas no episódio original da rinha, então assistam lá depois. Mas voltando ao assunto de conexões no banco, só queria deixar um comentário sobre a diferença de linguagens compiladas como Rust e interpretadas como Javascript. Ou mais especificamente, linguagens que tem capacidade de escalar com threads nativas e linguagens que não podem por causa de lock global de interpretador, que todas as linguagens da categoria B tem.

Eu explico isso no episódio de linguagens compiladas e interpretadas. Mas na nossa situação de uso com banco de dados costuma significar o seguinte: além de serem mais performáticos pelo fato de serem compilados, linguagens como Rust ou mesmo Java, tem a vantagem de precisar de menos conexões simultâneas. Um pool de conexões de Java é thread-safe, ou seja, pode ser utilizado por múltiplas threads nativas em paralelo.

Numa linguagem como Javascript ou Ruby, ou qualquer interpretada, cada thread nativa precisa ter seu próprio pool de conexões. Em resumo é mais ou menos assim: em Java poderíamos configurar o pool de conexões pra ter um máximo de 100 conexões, e é isso que a aplicação vai ter no total: 100 conexões.

Já num Javascript, depende. Se rodar com um processo só, vai subir só um pool de conexões, se colocar o máximo de 100, é isso que vai ter: até 100 também. O reactor do Node.js é single threaded. Toda chamada assíncrona roda numa mesma thread nativa e vai acessar um único pool de conexões.

No caso de Node.js em modo cluster, ele pode subir múltiplos forks de processos de Node. Cada um com um pool de conexões separado. Então se for subir 5 forks no cluster, devemos configurar o pool pra ter no máximo 20 conexões, se eu quiser manter o mesmo máximo. 5 vezes 20 é o máximo de 100, entenderam? Por isso não dá pra subir forks infinitos no cluster, porque cada fork vai tendo menos e menos conexões que pode usar no pool.

Estou pulando vários detalhes. Em cada linguagem vai ter alguma peculiaridade na implementação de threads, co-rotinas, pools. Você precisa entender como I/O não bloqueante funciona e como sua linguagem favorita lida com isso. Fica de lição de casa, caso ainda não tenham estudado sobre isso. A dica é começar assistindo meu antigo episódio sobre concorrência e paralelismo pra entender essa base.

Mas o ponto foi só pra vocês saberem que existem diferenças grandes em como se configura coisas como pool de conexões em Java e em Node.js, por exemplo. A configuração de coisas como pool de conexões vai ser diferente. A melhor forma de aprender a diferença é monitorando com um pgAdmin da vida e criando cenários de teste de carga com Gatling ou Vegeta da vida, pra ver na prática quais números funcionam e quais não funcionam.

Quando se é júnior, você faz tudo às cegas, no achismo, achando que vai dar tudo certo. Mas à medida que ganha experiência e vai ficando mais sênior, começa a entender que chutômetro é o caminho mais rápido pra software ruim. Sempre parece que o software faz coisas que você não previa. Pra ganhar controle sobre isso, só tem um caminho: aprendendo sobre benchmarks, profiling, carga, monitoramento, medição, estatística e finalmente começar a enxergar e interpretar corretamente o comportamento do software de acordo com diferentes níveis de carga e estresse.

E com isso, acho que consegui cobrir todos os tópicos que tinha deixado pendente. Não queria fechar o ano com pendências. Com isso posso finalmente dar por encerrado esse assunto de rinha. Vamos começar o ano com temas novos. Em Janeiro de 2024 eu vou tirar férias e passar três semanas no Japão, então acho que não vai ter video em Janeiro. Ainda não sei se volto a publicar antes ou depois do Carnaval, então pode ser ser que eu só volte entre Fevereiro e Março. Aproveitem pra maratonar o canal. Devo ficar postando sobre a viagem no Instagram, então me sigam lá. Se ficaram com dúvidas, mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal, e não deixem de compartilhar o video com seus amigos. A gente se vê em 2024, Feliz Natal e Bom Ano Novo! Até mais!

Sim, este episódio foi inteiramente gerado por ferramentas de IA, em particular HeyGen e ElevenLabs. Fiz bem curto pra não ficar cansativo demais. Mesmo sendo impressionante, no atual estágio não é possível fazer videos do tamanho que costumo fazer no canal.

Primeiro, o HeyGen não consegue fazer videos maiores do que 1 minuto sem que a qualidade decaia muito. Eu tentei fazer videos de mais de 2 minutos e do nada ele começava a halucinar e me fazer falar em espanhol, por exemplo.

Segundo, o treinamento é super limitado. Ele só me deixa subir uns 5 minutos de amostra de video. É muito pouco e isso resulta em muito pouca variância nos movimentos. Muito pouca diversidade de jeito de falar. Então fica muito robótico mesmo.

Terceiro, o tempo que levou pra gerar esses clipes de video não compensa o trabalho. Não é de graça, custou quase 40 dólares pra fazer menos de 14 minutos. E levou mais de 14 minutos pra gerar tudo. Eu teria levado cerca de meia hora pra gravar normalmente um video deste tamanho. Então não é possível usar esse tipo de ferramenta pra economizar tempo.

A vantagem seria mais no futuro, quando esses limites melhorarem, e eu tiver algum problema físico que me impeça de gravar mais videos. Aí sim, poderia servir como meu “backup virtual”. Ainda é primeira geração desse tipo de ferramenta. Eles devem melhorar bastante nos próximos anos.

O que acharam?

Links

• HeyGen - AI Spokesperson Video Creator
• Text to Speech & AI Voice Generator (elevenlabs.io)
• eesel.ai - ChatGPT over your knowledge
• DaVinci Resolve 18.5 traz inteligência artificial para edição de vídeo (diolinux.com.br)
• Adobe Firefly – Generative AI for everyone

SCRIPT

Olá pessoal, Fabio Akita!

Este vai ser um episódio experimental, curtinho mesmo, mais de brincadeira. Desta vez quero falar um pouco sobre as ferramentas de IA, tipo ChatGPT, que tenho incorporado no meu dia a dia. Não vai ser um review extenso de tudo que existe, só o que eu já experimentei e gostei de usar.

Todo mundo continua empolgado e hypado por causa de ChatGPT, especialmente com o lançamento do ChatGPT 4, com funcionalidades como, abre aspas, “fazer seu próprio GPT”. Vou aproveitar pra explicar um pouco disso e reiterar minhas opiniões sobre IA em geral. Então, vamos lá!

Pra começar, novembro vimos um dos episódios mais patéticos da história de Silicon Valley. Tudo bem, pra ser honesto, teve mais patéticos, como a história da Theranos ou da WeWork. Mas o hype sobre IAs continua num estágio muito primitivo de discussão.

Esse episódio patético foi a diretoria da OpenAI demitir o CEO Sam Altman, sem explicação nenhuma, fazendo um puta drama, pra depois voltarem atrás quando todos os funcionários ameaçaram sair e irem pra Microsoft. Ninguém deu uma razão oficial pra isso até agora, mas alguns especulam que tem a ver com os riscos de estarem próximos de atingirem a tal da “AGI” ou “Inteligência Artificial Geral”, a temida Skynet.

O que se chama de “IA” hoje em dia são Large Language Models, LLMs. E LLMs são basicamente como o auto corretor do teclado do seu celular, mas altamente glorificado! Ele cospe coisas que parecem ter sentido, mas não houve um milímetro de cognição envolvida, muito menos consciência. Provavelmente, amebas tem mais consciência do que o melhor LLM de hoje.

Explico isso em detalhes no meu video de “Como ChatGPT Funciona”, depois assistam pra entender. Modelos são embeddings de textos. Matrizes hiper-dimensionais de pedaços de textos associados com valores probabilísticos. Em resumo, super resumido, é assim que um GPT gera textos. GPT é um gerador de textos. Sim, um gerador ultra-sofisticado, mas ainda assim, um gerador de textos. Não existe “inteligência” no sentido humano que envolve raciocínio ou cognição.

GPT só continua o texto a partir de onde você parou de digitar. Ele continua textos. A idéia toda de “gerar seu próprio GPT” eu mostrei na live que tá no meu canal de “IAs são perigosas?” Onde eu mostro como criar um personagem. Eu criei o John Carmack e comecei a conversar com ele. Assistam lá depois. É a mesma coisa no GPT 4, um prompt inicial dizendo “faça de conta que você é a pessoa Fulano, com comportamento assim ou assado” e aí ele continua o texto.

Mesmo com os avanços do GPT 4, mesmo se o GPT 5 for o dobro ou triplo ou 10 vezes melhor que GPT 4, ainda assim não estamos pertos da tal “AGI” que é a Inteligência Artificial “Geral”, a verdadeira consciência digital, que simula perfeitamente um “ser vivo”, com emoções e ambições, a semente da Skynet. Isso continua sendo ficção científica. Ainda faltam descobertas e breakthroughs que não foram feitos.

Não sabemos quais descobertas são, obviamente, senão não seriam descobertas, mas sabemos que faltam. Ao contrário do que as pessoas pensam, nós engenheiros e cientistas, não fazemos as coisas às cegas, aleatoriamente. Sabemos quais os limites do que pode ser feito com as ferramentas que temos. Imaginação é exatamente uma das coisas que nós sabemos fazer muito bem, e que IAs não tem capacidade.

Mesmo assim, muita gente considerada “gênio” da área, como um dos fundadores da OpenAI o Ilya, por alguma razão, resolveu aderir à crença de que estamos perigosamente próximos de uma AGI que vai prejudicar a espécie humana. Não vai. Não só tá longe, como neste estágio eu nem diria que temos certeza se isso é sequer possível. Pra começar não existe nem boas definições para o que caracteriza de fato coisas como “inteligência” ou “consciência”. Nossas definições hoje são extremamente primitivas ainda.

É o mesmo tipo de “gênio” que anos atrás ficava enchendo o saco dizendo que o aquecimento global já teria acabado com o mundo em 2023. Mas isso é outro assunto.

Mesmo assim, sim, os receios que IAs vão substituir o emprego de muita gente são reais, em particular porque existem muitas atividades que são meramente copy e paste, muito simples de serem automatizadas. Não porque a IA ficou inteligente demais, mas porque os trabalhos em si eram muito simples.

Não precisou de IA pra começar a substituir caixa de supermercado ou tirar pedido em fast food. Muitos mercados já tem caixas self-service. Lugares como McDonald’s já tem telas gigantes de pedidos self-service. Muitos bots de atendimento via whatsapp já substituiram gente que atendia telefone, e por aí vai. E isso é normal. Faz mais de século que estamos substituindo trabalhos de baixo valor agregado pra sistemas automatizados, e pra isso não precisa de IA. A geração atual de LLMs ajuda, com toda certeza.

No nosso caso de programadores, sim, também existe automação. Mesmo em design. Todo mundo que usa softwares como Canva já sabe disso. O que antes precisava pedir pra alguém abrir o Photoshop pra fazer, qualquer um sem nenhum treinamento já consegue fazer agora. Quem é de Photoshop, lembra como separar uma pessoa do fundo antigamente levava horas, precisava de técnicas avançadas com lidar com canais de separação de cor. Agora o app de câmera do iPhone ou Pixel já conseguem fazer isso com um clique.

Mesmo antes de IA, com serviços como SquareSpace, muita gente não-técnica já consegue fazer sites minimamente bonitos. O mercado de templates, por si só, barateou bastante o que antes era um trabalho caro e demorado. Pra maioria das pessoas, só isso já é suficiente. E de novo, nem precisamos de IA pra isso.

Isso tudo dito, as ferramentas baseadas em alguma coisa de IA de hoje são extremamente úteis. ChatGPT e LLMs são só um dos tipos de IA, mas não são os únicos tipos. Muitas ferramentas que usam modelos de IA não são baseados em LLMs porque não são geradores de conteúdo. Alguns usam machine learning, alguns usam deep learning, alguns usam combinações de diversas técnicas. A população leiga chama tudo isso só de “IA”, por isso gera tanta confusão. Mas IA não é uma entidade única, é uma coleção de diversas tecnologias diferentes trabalhando em conjunto, muitas delas com décadas de idade já.

Se não ficou claro, este video que você está assistindo, por exemplo, foi inteiramente gerado com auxílio de IA. Estou usando o site HeyGen.com, que foi treinado com trechos de videos antigos. Esse site se integra com outro, chamado ElevenLabs, que é especializado em vozes via IA. Então, só precisamos escrever um novo script, subir trechos no HeyGen e ir gerando pedaços, porque ele não deixa gerar videos muito longos ainda. No final jogamos no DaVinci Resolve de sempre, pra juntar os pedaços num único video.

Sim, tudo que você assistiu até aqui foi inteiramente gerado por IA. Eu sou um avatar digital do Fabio Akita. O Fabio Akita de verdade foi sequestrado e vou mantê-lo como refém até … hahahahaha .. estou brincando, claro. Claro. Se duvida que sou uma IA, o HeyGen pode fazer outra coisa: dublar qualquer áudio em qualquer outra língua. Já pensaram, como é o Akita falando em coreano? Vamos ver.

Não se convenceram? Então vamos ver de novo, só que dublado em árabe.

Interessante não? É assim que muitos videos no TikTok são feitos hoje. E já que estou falando de video, diversas marcas famosas como Blackmagic e Adobe já integraram funcionalidades de IA num DaVinci Resolve ou Adobe Photoshop da vida.

No Resolve, por exemplo, ele consegue coisas incríveis como re-iluminar uma cena. Imagine que faltou uma luz de um lado, o que fazer? A IA consegue analizar a cena, descobrir a profundidade dos objetos filmados num espaço 3D e com isso podemos posicionar uma nova luz em qualquer lugar.

Não achou isso interessante? Este trecho eu gravei com barulho de fundo pra simular gravação na rua ou em eventos. O DaVinci é capaz de separar sua voz do resto do barulho e a qualidade fica quase como se tivesse sido gravado em estúdio. Vamos repetir com o filtro.

Viram? E dá pra fazer muito mais. Gerar legendas, antes era manual, mas agora ele faz automaticamente pra mim, como neste trecho. Se você é editor de video, deveria explorar essas opções. Dois canais do YouTube que recomendo assistir pra aprender é o MrAlexTech e o do Casey Faris. Sobre colorização, o melhor profissional é o Waqas Qazi.

Adobe também não fica atrás. Pra começar existe agora esse novo produto Adobe Firefly, que é como um Dalle-2 ou Midjourney, mas que a Adobe garante que foi treinada só com imagens cujos direitos autorais permitem isso. Assim você não corre o risco de gerar uma imagem que depois pode te levar a ser processado.

Photoshop também tá ganhando várias novas funcionalidades de IA, um dos mais notáveis é o preenchimento de conteúdo. Antigamente ele usava pedaços da própria imagem pra preencher o vazio quando queríamos mudar as dimensões da imagem. Mas agora ele consegue redesenhar como faz um Midjourney, com uma qualidade até que bem aceitável em vários casos, precisando fazer muito pouco ajuste depois.

A melhor ferramenta de edição de imagens ainda é Photoshop, e tem dezenas de técnicas e teorias que precisa saber pra usar direito. Recomendo assistir o canal PixelImperfect que ensina algumas das melhores técnicas.

Sobre geração de textos, não preciso perder tempo explicando como ChatGPT é ótimo pra fazer resumos, escrever textos descartáveis como um email mais formal. Mesma coisa vale pro GitHub CoPilot. Espero que vocês já tenham deixado pra trás a idéia idiota de achar que essas ferramentas vão substituir todos os programadores. Como já disse nos videos anteriores, minha resposta é a mesma: toda atividade de baixo valor agregado, inclusive programação de baixo valor agregado, vai sim ser substituído.

Bons programadores, não. Nenhum gerador de textos chega a 10% de um programador de verdade. Mas o que ele faz já nos ajuda bastante. Eu não preciso ficar toda hora dando alt-tab pra documentação e ficar manualmente procurando a sintaxe dessa ou daquela função, o Copilot auto-completa direitinho. É basicamente automatizar o copy e paste de stackoverflow que todo mundo já fazia.

Pra fazer coisas como HTMLs básicos, que é sempre a mesma estrutura. CSS básico, que é sempre a mesma estrutura. Códigos de testes unitários, que é sempre a mesma estrutura, essas coisas repetitivas e trabalhosas, o Copilot ajuda bastante. Muita coisa que eu sempre achei tedioso, um Copilot ou GPT ajuda muito e recomendo que usem. Integração com Visual Studio, até com Vim já funcionam super bem.

Mais do que isso, recomendo instalar GPT em linha de comando, como um “AI Chat”. Assim, do terminal, posso perguntar sobre comandos que não lembro todas as opções de cabeça. Como que roda um container docker de tal forma que ele apague o container depois que eu terminar, pra não deixar sujeira pra trás? Só perguntar, copiar o comando, e já colar direto no terminal e pronto.

Lógico, como sempre, nada disso serve pra quem não presta atenção. Se não tomar cuidado, você vai estragar sua máquina, colando comandos sem saber o que fazem. Mas isso já acontecia quando você colava comandos do stackoverflow. Se não sabe discernir nem isso, obviamente não é um profissional de programação.

Finalmente, uma das limitações do ChatGPT, pelo menos até a versão atual, é que ele não guarda memória do que você conversou com ele. Toda nova conversa começa do zero. Ele não usa informações anteriores pra continuar respondendo. Mas existem dezenas de ferramentas que aumentam essas capacidades. Um desses exemplos é o Eezel.io. Nesse site podemos fazer upload de documentos, como Word ou PDF.

Ele vai processar essa informação, criar embeddings dos textos, colocar num banco de dados de vetores, e usar essa informação no chat, que é integrado com ChatGPT. Assim, podemos fazer perguntas em linguagem natural sobre os dados que acabamos de subir. Pense subir uma centena de relatórios de feedback da empresa, e pedir um resumo de tudo, ou perguntar sobre uma pessoa em particular, e coisas assim.

Não vou sair listando toda ferramenta integrada com ChatGPT porque várias aparecem, e várias desaparecem, todos os dias. É melhor ir no Google e procurar as ferramentas mais famosinhas da época. Esse ainda é um mercado super volátil. Eesel, ElevenLabs, HeyGen, talvez ainda existam daqui um ano, talvez já tenham sido substituídos por alternativas melhores, não temos como saber.

Como falei no começo, este é um video curto, foi só pra cagar regra sobre IA e experimentar como ficaria um episódio inteiro feito com IA. Quem sabe, embora AGI não seja mais que ficção científica ainda, o que temos hoje já é muito bom e já serve até pra fazer videos como este. Eu consigo ver estas ferramentas sendo aprimoradas pra gerarem resultados mais naturais. Do jeito que tá hoje, os mais desavisados já nem sabem mais a diferença entre real e virtual.

Se curtiram o video deixem um joinha, assinem o canal, cliquem no sininho e compartilhem com seus amigos. A gente se vê, até mais!

Como que se geram chaves secretas pra encriptação? Pra que servem pares de chaves? Como certificados funcionam? Qual a diferença de impressão digital e assinatura digital? Como tudo isso funciona junto e chega em coisas como BitTorrent, Git ou Bitcoin?

Já tinha feito 2 videos falando do básico de criptografia, hoje é dia de ver como essas coisas funcionam na prática e são usados em aplicações de verdade.

Capítulos

• 00:00:00 - Intro
• 00:01:28 - CAP 1 - Criptografia Simétrica - OpenSSL
• 00:10:11 - CAP 2 - Criptografia Assimétrica - Chaves RSA
• 00:17:06 - CAP 3 - Certificados Digitais - Let’s Encrypt
• 00:29:18 - CAP 4 - Impressões e Assinaturas Digitais - Hashing
• 00:38:54 - CAP 5 - Picotando Arquivos - Introdução a BitTorrent
• 00:46:03 - CAP 6 - Entendendo Links Magnéticos - BitTorrent
• 00:53:52 - CAP 7 - Árvores de Merkle - Escalando BitTorrent
• 01:01:13 - CAP 8 - Git e Merkle - Reescrevendo a História
• 01:06:10 - CAP 9 - Juntando as Peças - BitTorrent e NoSQL
• 01:09:56 - CAP 10 - As Últimas Peças - De ZFS a Bitcoin
• 01:13:03 - Bloopers

Links

• Intel® Advanced Encryption Standard Instructions (AES-NI)
• VeraCrypt - Free Open source disk encryption with strong security for the Paranoid
• Rng-tools - ArchWiki (archlinux.org)
• Trusted Platform Module - Gentoo wiki
• How to choose an AES encryption mode (CBC ECB CTR OCB CFB)? - Stack Overflow
• encryption - ECDSA vs ECIES vs ECDH - Cryptography Stack Exchange
• VU#836068 - MD5 vulnerable to collision attacks (cert.org)
• Google Online Security Blog: Announcing the first SHA1 collision (googleblog.com)
• The GNU Privacy Guard (gnupg.org)
• How-to verify GPG key of official .ISO images - Manjaro

SCRIPT

Olá pessoal, Fabio Akita

Criptografia é um assunto super extenso, hoje quero mostrar um pouco mais na prática alguns componentes comuns que vocês vão esbarrar mais cedo ou mais tarde. Já tinha feito 2 videos sobre a teoria, depois assistam.

Eu não sou especialista em segurança, sou um desenvolvedor que se interessou pelo assunto, só. Por isso não considerem que tudo que vou falar é o único jeito ou é completo. É apenas o que eu considero o mínimo, de desenvolvedor pra desenvolvedor. Quem for especialista na área, por favor, complementem nos comentários abaixo.

Quem evitou o assunto até agora, hoje é o dia de cair de cabeça. Quero mostrar como encriptação de dados funciona, como certificados digitais funcionam, e como tudo isso é aplicado no mundo real, passo a passo. Na segunda metade vou explicar como um BitTorrent funciona e quais tecnologias tornam ela similar a um Git. Vamos lá.

(….)

Este é um video pra quem já saiu da faculdade mas ainda não brincou o suficiente com criptografia, infelizmente você vai precisar ter um mínimo de base pra prosseguir e desta vez não vou segurar muito na mão. Prestem bastante atenção, façam anotações se precisar. Se não entenderem este começo, não vão conseguir seguir o raciocínio depois. Pausem, voltem e revejam, até entender. A primeira metade, vale até abrir o terminal e tentar os comandos vocês mesmos pra sentirem na mão como funcionam. Videos densos como de hoje não é pra assistir só uma vez.

Toda CPU moderna tem instruções em hardware pra encriptar dados. Se você tem Mac e habilitou File Vault, se tem Windows e habilitou BitLocker, ou se usa Linux com LUKS, todos usam o algoritmo de encriptação AES, provavelmente a variante de 256 bits. Em CPUs novas é muito raro sentir que o sistema ficou mais lento por causa disso, por isso recomendo manter ativado, especialmente em notebooks. Caso sejam roubados, a chance de alguém acessar seus dados é perto de zero. Se quiser aumentar performance, o certo não é desligar encriptação e sim comprar um SSD melhor.

Há quem ainda ache que só porque precisa fazer login na sua conta quando liga a máquina, está seguro. Mas não. Se remover o HD ou SSD do seu notebook e ligar numa outra máquina, vou ter acesso a todos os arquivos se não estiverem encriptados. Seu login e senha não fazem nenhuma diferença. Login em sistema operacional só evita que um usuário tenha acesso aos arquivos de outro usuários enquanto a máquina está ligada e ninguém tem acesso físico ao hardware. Se tiver acesso físico, não faz diferença. Isso vale pra qualquer sistema operacional.

No episódio de Sua Segurança é uma Droga eu demonstrei o uso do Veracrypt. Diferente de BitLocker do Windows, por exemplo, que só dá suporte a AES porque é o mais performático, o Veracrypt permite escolher outros algoritmos. Pra coisas muito grandes vai ser mais lento, mas por outro é o mais seguro. Um HD com BitLocker, pode ser difícil de quebrar, mas sabendo que é AES podemos focar só nisso. Mas uma imagem encriptada com Veracrypt, não sabemos nem o algoritmo usado, e isso aumenta a segurança exponencialmente. Por isso que pra coisas absolutamente críticas, é melhor usar Veracrypt. Pro dia a dia AES de BitLocker ou FileVault é mais que suficiente.

Vou repetir: se você tem dados importantes, num notebook que carrega embaixo do braço, pra trabalhar de um starbucks da vida, espero que não seja burro de andar por aí sem encriptação. Mas como que funciona esse tipo de encriptação? Vamos dar alguns exemplos.

Um dos pacotes de segurança e criptografia mais conhecidos e utilizados do mundo é o famoso OpenSSL. É um pacote gigante, com praticamente tudo que se precisa pra lidar com criptografia. Existem outras alternativas como LibreSSL, BoringSSL do Google, NSS da Mozilla e outros, mas vou focar no OpenSSL porque ainda é um dos mais usados. De um terminal num Linux, é assim podemos gerar uma chave aleatória. Vamos chamar de “key.bin”

openssl rand -out key.bin 32
hexdump key.bin

Geramos uma chave binária de 32 bytes ou 256 bits. Essa chave é segura o suficiente pra maioria dos usos hoje. Pra ser mais seguro deveríamos adicionar entropia externa, por exemplo, com um hardware externo ou o chip de TPM que vem em máquinas modernas usando algo como TPM2-TSS. Entropia inicial é extremamente importante pra definir a força de uma chave. Mas só pra usar de exemplo, isso vai servir.

Por ser importante, vale mais uma tangente. Tudo em criptografia depende de um PRNG ou Pseudo Random Number Generator. Não existe número verdadeiramente aleatório, existem funções que, dado um número inicial, consegue ir “cuspindo” números que parecem aleatórios. Se colocarmos numa distribuição estatística, seria uniforme, onde todos os números tem mais ou menos as mesmas chances de aparecer, sem nenhum viés.

Mais do que isso, os números gerados não devem parecer diferentes de aleatoriedade verdadeira, devem ser resistentes a backtracking. Não deveria ser possível reconstruir números anteriores só vendo uma sequência de números gerados, ou seja, devem ser resistentes à previsão, não podendo ser fácil prever os próximos. Devem ser difíceis ou impossíveis de serem reproduzidos.

Bons números aleatórios são fornecidos pelo sistema operacional. No caso de Linux, existe um dispositivo em “/dev/random” que é de onde pacotes como OpenSSL se conectam. Podemos aumentar a entropia dele usando um serviço como “rngd”. Num Arch é só instalar com “pacman -S rngd”, habilitar e iniciar com “systemctl enable” e “systemctl start”. Esse serviço vai tentar puxar entropia de dispositivos de hardware ou do chip TPM do seu PC, se ele for moderno.

Chip TPM, de Trusted Platform Module, é o que gerou controvérsia quando o Windows 11 inicialmente ia obrigar todo mundo a ter. No fim voltaram atrás porque muita gente não ia ter e reclamaram muito. Mas o certo é realmente ter esse chip. Toda placa mãe tem um slot pra esse chip, mas em modelos baratos ele vem vazio, pra você comprar separadamente. Dentre as várias funções de segurança que ele fornece, está entropia via hardware. Esse serviço “rngd” vai alimentar o “/dev/random” que, por sua vez, é usado pelo OpenSSL.

Várias classes de malware e vírus são bloqueados ao ter um chip TPM devidamente configurado, em particular rootkits, além de melhorar a encriptação com BitLocker. Cheque se sua máquina tem, ou se tem suporte de instalar. Se tiver, compre e instale. Todo Mac e iPhone tem um chip similar instalado de fábrica, o chip T2, que é uma das razões de um Mac ser mais seguro que um PC mais barato. Nada disso torna você 100% seguro, mas certamente melhora sua defesa.

Voltando ao exemplo, agora vou criar um arquivo idiota chamado “test.txt” com a boa e velha frase “Hello World”. E vamos encriptar usando nossa chave. Esta linha de comando de OpenSSL vai usar AES 256 em modo CBC, com salt, passando o test.txt e devolvendo test.txt.enc, usando a chave key.bin que acabamos de gerar. Pronto. Se dermos um “cat” no novo arquivo, vai devolver um lixo binário. Podemos ver com hexdump e não tem nada a ver mais com o arquivo original. Esse é o resultado esperado.

openssl enc -aes-256-cbc -salt -in test.txt -out test.txt.enc -pass file:./key.bin

cat test.txt.enc
Salted__����z�F�ğQw8��#�- ���4

hexdump test.txt.enc
0000000 6153 746c 6465 5f5f 1ae2 88f0 d67a cc46
0000010 9fc4 7751 fc38 23b4 2da6 f020 aaf5 0a34
0000020

hexdump test.txt
0000000 6548 6c6c 206f 6f57 6c72 0a64          
000000c

Mais um adendo aqui. Só pra simplificar o exemplo, escolhi AES 256 em modo CBC ou Cipher Block Chaining. Ele é melhor que o anterior ECB mas é sensitivo a erros de ciphertext e é vulnerável a ataques de padding oracles se não for implementado corretamente. Além de CBC existe Cipher Feedback ou CFB, Output Feedback ou OFB, Counter ou CTR e Galois/Counter Mode ou GCM. Se precisar escolher, use GCM.

Estou usando CBC com um salt, que já é melhor que só CBC sozinho, mas se for usar GCM ele vai gerar um tag de autenticação e anexar no arquivo encriptado. Mas o certo é se preocupar com o tráfego desse tag, porque ele precisa ser transportado de forma segura e não num anexo de email, aberto, por exemplo. Além disso tem que se preocupar com Initialization Vectors, IVs. Por isso a maioria dos tutoriais por aí, assim como meu exemplo, usam CBC: porque é mais simples de explicar.

Entenda isso: pareceu que falei uma sopa de letrinhas a toa só pra dificultar, mas foi pra demonstrar que a maioria dos tutoriais vai escolher a opção mais simples de explicar, que costuma ser a mais insegura. Por isso eu falo que se você não estudou criptografia a fundo, não deveria tomar decisões de criptografia: vai usar errado e vai tornar a encriptação do seu sistema mais inseguro.

Era uma das minhas críticas quando JWT, o JSON Web Authentication, por exemplo, foi lançado lá atrás: ele exigia que o desenvolvedor soubesse tomar essas decisões de algoritmos e modos, mas quase ninguém sabe e nem vai aprender certo. Ele não deveria permitir as combinações obviamente mais inseguras. Só que ao fazer isso, tornaria a usabilidade mais difícil. É sempre um trade-off: quanto mais usável tentar fazer alguma coisa, mais inseguro vai ser. Segurança é complicado mesmo.

Agora eu poderia enviar o arquivo encriptado pra outra pessoa pela internet e, se ela tiver a minha chave, conseguiria decriptar com uma linha de comando parecida com esta. OpenSSL modo AES 256 CBC recebendo o test.txt.enc encriptado e descriptografando em test.txt.dec passando a chave key.bin. Com um comando “cat” vemos que foi com sucesso.

openssl enc -aes-256-cbc -d -in test.txt.enc -out test.txt.dec -pass file:./key.bin

cat test.txt.dec
Hello World

Bacana, de forma simplificada, é assim que um BitLocker ou FileVault ou Veracrypt da vida estaria lidando seus dados. Eu digo simplificando porque aqui dei exemplo lidando com arquivos inteiros, mas sistemas de arquivos lidam com stream de blocos. Enfim, no HD físico só teria o equivalente àquele arquivo “test.txt.enc”, a versão encriptada. E precisa ter essa chave em algum lugar pra conseguir ler o conteúdo original de volta. Isso normalmente seria pesado de computar, mas a encriptação e decriptação não é feita via software e sim via instruções direto da CPU, em hardware, por isso o processo é mais acelerado e quase não sentimos, na prática.

Mas no exemplo anterior temos um problema gigantesco. Se o objetivo de encriptar algum arquivo for pra poder enviar de forma segura pra outra pessoa, como fazemos pra enviar a chave de forma segura também? A única forma seria essa pessoa vir até minha casa, trazendo um pendrive, e eu gravar a chave direto no pendrive, sem nunca trafegar pela internet. Mas isso não é prático. Como consigo passar uma chave pra outra pessoa de forma que ninguém na internet consiga interceptar ou adulterar?

Aqui entra o conceito de chaves assimétricas. Novamente, explico sobre isso em detalhes no 2o video de criptografia. Mas deixa eu dar um exemplo prático. De volta ao terminal, vamos usar OpenSSL pra gerar um par de chaves. Literalmente são dois arquivos, um chamado private.pem e outro chamado public.pem.

openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048
openssl rsa -pubout -in private.pem -out public.pem

Enfim, escolhi a opção de algoritmo RSA de 2048 bits. E eu sei que já deve ter gente indo nos comentários reclamar “porra Akita, você devia ter usado curva elíptica em vez de RSA”. Eu expliquei o que são esses algoritmos e as diferenças no meu video antigo, mas resumindo, sim, Elliptic Curve Cryptograph ou ECC é mais forte que RSA. Uma chave ECC de 256 bits é mais forte que uma chave RSA de 3072 bits, mais de 10 vezes o tamanho.

O problema é que OpenSSL não oferece comandos simples pra encriptar dados arbitrários com chaves ECC porque ECC é normalmente usado pra coisas como tráfego de chaves ou ECDH, assinatura digital que é ECDSA ou com mecanismos de encapsulamento de chave em ECIES. Ou seja, não é simples pra sair encriptando qualquer dado arbitrário. Eu poderia usar ECDH mas a ideia desse video não é entrar nas minúcias de ECC e sim dar uma noção geral de criptografia e, pra esse fim, RSA vai ser mais que suficiente. RSA é mais simples pra usar e ensinar, mas se estiverem fazendo algo sério, estudem tudo que acabei de falar sobre ECC.

E o que são esses arquivos RSA que foram gerados? Podemos usar o comando “cat” e vai listar o conteúdo. É a versão em Base64 da chave binária. Base64 é como encodamos um binário em caracteres ASCII que dá pra mostrar na tela. Convertemos 8 bits em 7 bits, por isso ele fica um pouco maior. O private.pem é mais longo e o public.pem é mais curto. Olhem só.

❯ cat private.pem —–BEGIN PRIVATE KEY—– MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5cMQZZd85emyr oL9cvrR522tmBBlcwpF7QyobGwAmk8smL2HoMf207LJl3wi7JE736qqWdme/Rwr8 Zsz8ZOAeiud4SIk/NbfezMoLVkUxQGOg0GprpYciUVUp9e/3HKl5PS9Yr9lU6QN8 Bs7gY96DohUrGz/hQR7G550O+/ITV+qm3VZytPiH8tQAXrueqC8lf/Ly97UnlfLr bauftw6QIw1ldI8NjxPIcwbNot+BfXcN6kiJifttdLi7/kEaAboecjYxcoipntjb RdAntX/Y6xluwKtKRqrTs1XxHAPtEEQrVvfc6CjM2kLiFe//r3oZCLhHAAyZhJ6X +J3zt0gXAgMBAAECggEAArvbsDzVEc2xEhtVvDd1hVcLmh6VBHiRLijbKI4j2O2/ MMoXCUDKFY49wmG2M71rypzeNJynQpB4uX2HJ8YRmxxUyuxVgFCO7DfHAhbHVga1 0Uub811RL4YqbsAY8GLZnsIc/hONl9ey555ZaMEgKSmiYpciwHPg0RwzWmKy0BUq bFRLIHhfJfxzIpHxw3LExW///jyVw56sK9IE260pYqf8MxX/mhxPllj5VLNbctzj YO1W+EjeUlolI19xSMJSlqW2bGeoXIalddDR0552QrmZAXEpRgI9V+NoQdSKnrXr gHJS2uav2ORqoxDp3+7np0dnt06dtD/rzevrDtoDzQKBgQD0IiKU9L0QbZDWz8SH b+SF5IymsMKRykyAXkghEjyzMXbbgnOHo7Eesc4iU07k1kzOKgtCcwt0glnEwKei qlzpDOZoW+UdloWVUXSuLFcW1Oy67B8w/YLp6PFBce7YMjij1hOvJSQS5unEfmt2 8PZ01JUA9m49DGfXTUrnzX6mRQKBgQDCdEnZLkIyo9RKBjsrd57+Yp4KtJuAqn8o fuBh33qxnrImkA/RMwrcUQIoLJly3DUk8UhJRIIqCLOp4BHc9WDkxa+7bqLl7OXG qWfyvwNLVY1M98oMbU7ESJPZb2BHLNrWgnD/tGYLrRQq+WbVkh2B7b+31SP63UZz sWG3W8TYqwKBgQDAZSZbvYRCLha3M4XuNoAiBLvTofm0a3lesO6nIXg0wAard2MU wiwTxIxvALhsH3boArpc481jRFb6d9mkmB4gi8oI9GLbroQX6NnLaaY4mBT4Op1a Pm+tZ6a5rNBOEUYR1+QrY1nKi7Au6nJGih+wctf6qjq2YdB0HLWreIcXAQKBgAFj ezOF1QsviFCPAtUooYYHhkFlUMb2cLoFTezk/6dNDtCfrr07tBQmr/FBgEcFs4tz /aQoTRWnwkCwTPBbADoh/0NDYv5pVqq4gvmEy606CyxFiLfV//3+1q9y0Ckx9M4b WFs7Go9yyPYVmdpklLlczUWuy/b6pYol9iCtExbJAoGAWgDbmrwo6Pg2ro+f98i6 K761tCW43rB2Trfl0XyB38OT/8geW14/BLBJdRp3XChg60b2UaVVwLhp3WvfKs9u FDFmsSSdnSs+X+JNtfnixbwXJl5I3z+s3Uz9wxRY/82RHM2f1FgQ22JFV7Es2H1U XENsUtHZ/bgOggoZTP3uEl0= —–END PRIVATE KEY—–

/tmp ❯ cat public.pem —–BEGIN PUBLIC KEY—– MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuXDEGWXfOXpsq6C/XL60 edtrZgQZXMKRe0MqGxsAJpPLJi9h6DH9tOyyZd8IuyRO9+qqlnZnv0cK/GbM/GTg HorneEiJPzW33szKC1ZFMUBjoNBqa6WHIlFVKfXv9xypeT0vWK/ZVOkDfAbO4GPe g6IVKxs/4UEexuedDvvyE1fqpt1WcrT4h/LUAF67nqgvJX/y8ve1J5Xy622rn7cO kCMNZXSPDY8TyHMGzaLfgX13DepIiYn7bXS4u/5BGgG6HnI2MXKIqZ7Y20XQJ7V/ 2OsZbsCrSkaq07NV8RwD7RBEK1b33OgozNpC4hXv/696GQi4RwAMmYSel/id87dI FwIDAQAB —–END PUBLIC KEY—–

Arquivos ponto “pem” significa Privacy Enhanced Mail que é um formato de arquivo texto exatamente como dessas chaves que acabei de mostrar. É isso, um arquivo que começa com esses hifens, BEGIN, lá embaixo termina com END, e no meio é algum binário formatado com Base64. Se usa SSH, você já gerou chaves nesse formato.

As chaves pública e privada geradas com os comandos openssl genpkey e openssl rsa estão relacionadas por meio do algoritmo de criptografia RSA. O processo começa gerando dois números primos enormes e aleatórios. Esses números primos são mantidos em segredo e são a base da segurança do sistema. Em seguida, esses números primos são multiplicados entre si, resultando em um número chamado ‘módulo’. Este módulo é usado na criação de ambas as chaves.

A chave pública é derivada do módulo e de um expoente público, que é um número pré-definido e geralmente pequeno. A chave pública pode ser compartilhada com qualquer pessoa e é usada para criptografar mensagens que só podem ser descriptografadas pela chave privada correspondente.

Por outro lado, a chave privada é gerada usando os números primos originais e um expoente privado calculado a partir deles. A chave privada é mantida em segredo e é usada para descriptografar as mensagens criptografadas pela chave pública.

Embora as chaves pública e privada não sejam os números primos em si, elas são matematicamente relacionadas aos números primos utilizados durante a geração. Esse relacionamento matemático é fundamental para o funcionamento da criptografia RSA e é o que permite a comunicação segura, onde informações criptografadas com a chave pública só podem ser lidas pela chave privada correspondente, e vice-versa. Fodeu, não entendeu nada né. Vamos simplificar com um exemplo.

openssl pkeyutl -encrypt -pubin -inkey public.pem -in key.bin -out key.bin.enc

Digito o comando openssl pedindo pra encriptar minha chave key.bin usando a chave pública e resultando num novo arquivo key.bin.enc. Pronto, agora temos a chave simétrica original, encriptada usando a nova chave pública. Se listarmos o conteúdo com hexdump, veja como os binários são diferentes.

❯ hexdump key.bin.enc
0000000 84b4 f414 6144 087d 079a 3036 4eb7 5798
0000010 28de 7505 e9fe fc0e 851c 877e be59 4b97
0000020 a5b6 05de e379 c30f 974b 9f31 a24a f567
0000030 68ad 0af9 d39b f770 3e20 0be8 3116 c52f
0000040 7437 4224 54f4 d071 b28e a5ff d29e 7a85
0000050 e78a 8ec2 b125 38ea 204a c071 82d0 5526
0000060 8923 4a84 23d6 72ea da81 434a 5f05 9e87
0000070 3b8d f2c1 5331 fc16 e92a 4e3b d695 4759
0000080 2472 0453 34cc db67 6dbf 8fbb 92ec e52f
0000090 be0c f295 3b5e 2aac 7fdb 0e82 bf0a 0cf8
00000a0 f158 0014 f93e 33f0 fe77 ca3a 3144 25f8
00000b0 877c a25f 4012 4953 be15 e06e 9894 a4ef
00000c0 a399 3b4a 1efe dc57 1e85 5410 5df3 7f95
00000d0 c957 9182 c426 55a6 ea7e 5e0d 1270 9ab2
00000e0 4781 44ae 3437 886b ef0c 82d6 5d66 5c5b
00000f0 e072 0888 bccd 55ba f217 100c 4906 f45e
0000100

/tmp 
❯ hexdump key.bin
0000000 ccab 139c 27f3 c206 76af 952d 0fb1 2c17
0000010 51a5 0a43 731b 5bf4 9f3c 72b5 1e57 2503
0000020

Pra não ficar confuso vamos recapitular. Eu gerei uma chave simétrica AES chamada “key.bin”. Quero usar essa chave pra criptografar arquivos ou mensagens pra mandar pra uma segunda pessoa em algum lugar na internet, vamos chamar de John. Porém, não adianta criptografar a mensagem e mandar pro John porque ele precisa ter a chave. Mas não posso mandar a chave via email ou whatsapp porque aí não tem segurança nenhuma. Precisamos garantir que nada no meio do caminho possa interceptar ou adulterar minhas mensagens pro John.

O problema de mandar a chave direto por email é se alguém na internet, vamos chamar de Skynet, intercepte essa comunicação e fique com minha chave, sem passar pra frente. Daí ela manda uma outra chave falsificada pro John. O John não sabe que recebeu uma chave falsa. Agora eu, Fabio, vou mandar uma mensagem criptografada com minha chave que diz “John, descobri a localização da Skynet, ele tá nas coordenadas X Y”.

Skynet intercepta essa comunicação, e como já tinha interceptado minha chave, consegue facilmente abrir a mensagem. Agora ela forja uma segunda mensagem dizendo “John, achei a Skynet, clique neste link pra ver a localização!”, criptografa com a chave falsa e manda pro John. O John abre achando que veio de mim. Daí, na confiança, clica no link e é isso, acabou a raça humana. Game over. Eu sempre digo: nunca saia clicando em links que recebe por email ou whatsapp.

Mas eu sei que isso poderia acontecer. Em vez disso já tinha ensinado: “John, cria um par de chaves RSA, e manda a chave pública pra mim, mas nunca, jamais, transmita a chave privada pra fora da sua máquina”. Ele me manda a chave pública, por email aberto mesmo, e com essa chave eu encripto aquele arquivo “key.bin”. Quando o John receber a mensagem criptografada, pode rodar o seguinte comando. Openssl decriptar o arquivo key.bin.enc com a chave privada.

openssl pkeyutl -decrypt -inkey private.pem -in key.bin.enc -out key.bin.dec

Entenda, quando encripto alguma coisa com a chave pública do John, o único que vai conseguir abrir é o John com sua chave privada. Se eu conseguir passar minha chave simétrica key.bin pra ele, de forma segura, garantidamente só nós dois temos o segredo e podemos começar a trocar comunicação encriptada com AES e a Skynet não vai ter como interceptar nem ficar no meio do caminho tentando forjar mensagens.

Mas tem um pequeno defeito nesse processo. Como eu sei que a chave pública que o John me mandou veio realmente do John e não é de novo a porra da Skynet tentando me enganar? Esse é o mesmo problema que temos hoje em websites e ecommerces da vida. Como eu sei que a chave pública que recebi da Amazon é realmente da Amazon? Como eu sei que não é um site de um hacker, uma Skynet, tentando se passar pela Amazon? Vamos entender a última peça que falta: a autoridade certificadora.

Esse é o princípio por trás de SSL ou, mais corretamente, TLS, que todo navegador utiliza. O que acontece por trás dos panos sem você ver é o seguinte: primeiro, abrimos o navegador e digitamos “https://amazon.com” da vida. Importante que seja um site “https”. Então o navegador pede uma conexão segura pro servidor web da amazon que, por sua vez, devolve um certificado digital.

Um certificado digital é um pacote que contém a chave pública, a metade do par de chaves de uma Amazon. A chave privada nunca sai do servidor. Lembrem-se desse conceito: chaves privadas nunca podem tocar a internet, jamais. Mas, como eu posso garantir que não é a Skynet, minha conexão foi interceptada e recebi um certificado falso? Pra isso que existem CAs ou Certificate Authorities. Vamos ilustrar com um exemplo, porque é importante ter esse processo na cabeça.

De novo, o objetivo do video não é ser um tutorial. Mas se nunca viu, vou criar um novo certificado digital usando o serviço Letsencrypt associado ao meu domínio válido “akitando.me”. Pra criar um certificado precisa ter um domínio registrado válido. O jeito tradicional é um passo a passo super chato. É um processo já bem documentado, que tem em dezenas de lugares, só procurar no Google. Mas Letsencrypt é mais fácil porque simplifica vários passos. Pra começar precisa ter instalado o programa “certbot” na sua máquina.

Iniciamos o processo pedindo pra gerar um certificado pro meu domínio usando o método de checar um registro no DNS pra garantir que sou mesmo o dono desse domínio. Só quem é dono do domínio consegue configurar o nameserver. No caso ele gera o que chamamos de um challenge, um desafio, que é esse número aleatório aqui. Eu tenho que registrar um campo TXT no DNS do domínio com exatamente esse número. Isso não é uma senha, fica aberto mesmo. É só pra garantir que a pessoa pedindo pra gerar o certificado realmente é o dono do domínio.

No caso, meu DNS ou nameserver tá na AWS então abro o Route53 pra editar os registros do meu domínio “akitando.me”. Dependendo de onde tá seu domínio, vai ser um tela diferente, mas o princípio é o mesmo. Daí tem que esperar alguns minutos pra essa informação replicar pela internet. Se não sabe como isso de DNS funciona, não deixe de ver minha série sobre redes. Já expliquei isso lá.

sudo certbot certonly --manual --preferred-challenges dns -d akitando.me


Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for akitando.me

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name:

_acme-challenge.akitando.me.

with the following value:

m_6yRys7mMCh-jg_R8kpwCl3mx5EVK3tMp9jeIR9RFI

Before continuing, verify the TXT record has been deployed. Depending on the DNS
provider, this may take some time, from a few seconds to multiple minutes. You can
check if it has finished deploying with aid of online tools, such as the Google
Admin Toolbox: https://toolbox.googleapps.com/apps/dig/#TXT/_acme-challenge.akitando.me.
Look for one or more bolded line(s) below the line ';ANSWER'. It should show the
value(s) you've just added.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue


Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/akitando.me/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/akitando.me/privkey.pem
This certificate expires on 2023-11-22.
These files will be updated when the certificate renews.

NEXT STEPS:
- This certificate will not be renewed automatically. Autorenewal of --manual certificates requires the use of an authentication hook script (--manual-auth-hook) but one was not provided. To renew this certificate, repeat this same certbot command before the certificate's expiry date.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

(screenshot route53)

Uma vez validado, vamos ganhar dois arquivos gravados em “/etc/letsencrypt/live/akitando.me”, um chamado “fullchain.pem”, o certificado digital propriamente dito, que vai ser servido pra todo navegador que conectar no meu servidor web, e o “privkey.pem”, que é a chave privada que jamais deve sair do meu servidor, nem ser transmitido pela internet de nenhuma forma.

Estou repetindo pra vocês nunca esquecerem: chave privada se chama “privada” por uma razão. Se perder essa chave privada, qualquer um pode se passar por você. E se alguém ficou pensando “porra, mas e se realmente eu perder essa chave?”. A solução é imediatamente gerar um novo certificado e substituir.

Eu não instalei de verdade essa chave porque não tenho site nesse domínio, mas se tivesse, no seu navegador iria aparecer o famoso cadeado. As informações que aparecem quando clica no cadeado é exatamente o conteúdo desse arquivo “fullchain.pem”. Ele contém a chave pública e está assinado por uma CA, a Central Authority, no caso, a LetsEncrypt.

Eis a resposta de como podemos garantir que o certificado que o site me deu é confiável. Todo navegador, Firefox, Safari, Edge, Chrome, Opera, já vem pré-instalados com vários certificados raíz, seja da Certsign, Digicert, GlobalSign. São arquivos que foram instalados juntos com seu navegador ou que seu navegador puxa do próprio sistema operacional. Um dos dois vai ter esses certificados raiz.

Se baixou seu navegador fora do site oficial, num site genérico de downloads, não existe garantia nenhuma. La garantia soy yo. Mas se estiver usando o Safari que já veio no seu Mac ou o Edge que já veio no seu Windows, a probabilidade é que sejam legítimos. De novo, se comprou sua máquina usada de um terceiro, e nunca formatou, não dá pra garantir nada. Nenhuma máquina que não foi você quem instalou, ou que não comprou numa loja de verdade, não tem nenhuma garantia, ponto final.

Podemos abrir diretamente o arquivo “fullchain.pem” e veja só, temos uma cadeia de certificados. Primeiro o do meu domínio. Em seguida, vemos que foi assinada pela Letsencrypt que é essa R3. E ela mesma, por sua vez, é assinada por outra autoridade, a Digital Signature Trust Co.

Certificados raíz podem ser instalados com o sistema operacional, ou podem vir com os navegadores. Google Chrome e outros navegadores baseados em Chromium costumam usar o que tem no sistema operacional. Firefox prefere usar certificados próprios. Num Arch Linux, como o Manjaro que eu uso, vem no pacote “ca-certificates” e costumam ficar no diretório “/etc/ssl/certs”. Olha só um trecho da listagem dos certificados. E se olharmos mais pra baixo, temos o certificado “ISRG Root X1” que é a raiz que vimos no certificado digital gerado pela Letsencrypt.

Meu navegador acha o ISRG Root X1 instalado na máquina. Ele parte do pressuposto que pode confiar em todo certificado que foi assinado por qualquer autorizada abaixo dela. É uma cadeia de assinaturas. O certificado do meu domínio akitando.me foi assinado pela chave privada da Letsencrypt que, por sua vez, tem um certificado assinado por essa ISRG que é verificado pela Digital Signature Trust que, em última instância, foi instalado no meu sistema operacional. Em última instância, confiamos que o sistema operacional não foi adulterado, porque instalamos com o ISO oficial ou já veio pré-instalado de fábrica e a máquina é nova.

Quando fizemos o processo do “Certbot”. Ele gerou aquele “fullchain.pem”. Começou gerando o par de chaves pública e privada. Daí empacotou no certificado, que é uma estrutura de dados com informações como o nome do domínio, email, a chave pública, etc. É só um arquivo, como se fosse um JSON da vida, por exemplo, mas num formato específico de certificado. No final, ele gera a impressão digital desse arquivo, que é um hash, usando um algoritmo como um SHA256 da vida.

Impressão digital é outro nome pra um hash. Quando passamos um arquivo ou algum conteúdo por um algoritmo de hashing, o resultado é uma impressão digital. Porque se alterarmos 1 bit que seja do arquivo original e refizermos o hashing, o resultado vai ser completamente diferente. Daqui a pouco vou voltar no tema de hashing. Por enquanto entenda que hashing serve pra identificar exatamente o conteúdo original de qualquer coisa. E o que chamamos de assinatura digital é o hash via chave privada de alguma autoridade.

Vamos em outro exemplo. YouTube.com. Olha o cadeado aqui no navegador. Se abrirmos vemos que a raíz é um tal de GTS Root R1. Voltando lá pro diretório “/etc/ssl/certs” achamos o arquivo do certificado e abrindo podemos ver que se trata do Google Trust Services LLC. Uma empresa do próprio Google dedicado só a gerenciar esse certificado raíz. O Google sendo gigante, é do interesse dela ter controle sobre uma autoridade certificadora também. Sim, seu computador automaticamente acredita em tudo do Google. Existem várias implicações éticas nesse tipo de coisa mas não é escopo desse video.

Com isso o navegador sabe que o certificado do site é “válido”. Daí ele pode pegar a chave pública de dentro do certificado, e usar pra encriptar uma chave simétrica. Isso estabelece o que se chama de “conexão segura”. Falando assim dá impressão que passamos a usar, sei lá, um cabo de rede especial que é mais seguro ou algo assim né? Mas não, nada mudou. Estamos na mesma rede física que antes. A diferença é que conseguimos comunicar de forma segura, encriptando todos os pacotes. E a partir daqui, tudo que o navegador mandar pro servidor e vice versa, vai ser encriptado com essa chave.

Tudo isso é feito pra garantir que ninguém no meio do caminho, nem a Skynet, nem o provedor, nem ninguém, consiga ver o que está sendo trafegado, porque vai tudo encriptado. Esse imbróglio todo de cadeias de certificados, assinaturas digitais, pares de chaves assimétricas, é a implementação de um “triângulo de confiança”. Segurança é quando eu e o John temos confiança num mesmo terceiro, que é uma autoridade reconhecida por ambos. Pra haver confiança, sempre precisa haver um terceiro elemento que ambos os lados confiam.

Voltando pra pergunta original, como eu posso confiar na chave pública do John? Como eu sei que não é a Skynet me mandando uma chave falsificada, se passando pelo John? E a resposta é porque tanto minha máquina, quanto a do John, foram configuradas pela primeira vez pela mãe dele. Mãezona Sara Connor se certificou de instalar um certificado raíz dela em ambas as máquinas. Quando o John me mandar o certificado dele, basta ver se tá assinado pelo certificado da Sara. E vou saber isso porque eu também tenho o certificado de CA dela na minha máquina, igual o exemplo do Google que mostrei. E com isso a humanidade ainda tem chances contra a Skynet.

Pra finalizar esta parte, já vimos como usar o certbot pra gerar um novo certificado digital, assinado pela Letsencrypt, pronto pra colocar no meu servidor web. Mas posso já usar aqui mesmo no terminal. Pra isso podemos usar openssl pra extrair só a chave pública que está dentro desse certificado, pelo terminal como estou mostrando. Openssl passando x509 que é o formato de um certificado, passando o arquivo do certificado e mandando extrair a chave pública pra esse arquivo pubkey.pem. Podemos dar cat nesse arquivo e voilá, eis o base64 da chave.

openssl x509 -pubkey -noout -in /etc/letsencrypt/live/akitando.me/fullchain.pem > pubkey.pem

cat pubkey.pem —–BEGIN PUBLIC KEY—– MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE+3a8eg0k/O7Sny46alWDx64kA8FK SvBs1GxEJA+1ay/6XLg2cF8xEjlDrLbkDrZlUPEr4KxVtFxKAS6uSaCtUA== —–END PUBLIC KEY—–

Tendo a chave pública, pra encriptar uma mensagem qualquer ou a chave simétrica, como meu arquivo “key.bin” do começo do video, é só usar openssl pra encriptar, como já mostrei antes. Mas tem um porém. Não vai dar pra mostrar isso porque essa chave pública que extraí do certificado gerado pelo certbot é uma curva elíptica ECC. Lembram porque eu usei RSA no exemplo lá atrás? Porque OpenSSL não consegue encriptar uma mensagem qualquer com ECC, lembra? Foi o motivo todo de porque eu fiz um exemplo com RSA.

Diferente do exemplo de encriptar uma chave simétrica diretamente usando a chave pública RSA; com curva elíptica, num navegador o que acontece é outro processo chamado de “key exchange” ou troca de chaves. Um método popular é usando o método de Diffie-Hellman que expliquei no meu video antigo de criptografia, ou ECDH que é a variante pra curva elíptica. Está fora do escopo deste vídeo explicar os detalhes, mas pesquise sobre ECDH.

Em resumo, o navegador já tem implementado um processo só pra trocar chaves simétricas usando essas chaves assimétricas, não precisa fazer na mão como estou mostrando no terminal. Curva elíptica é mais eficiente e mais sofisticado do que o RSA antigo. Mas RSA é suficiente e mais fácil pra demonstrar passo a passo no terminal. Objetivo do vídeo não é tornar ninguém aqui especialista em criptografia, só molhar os dedos pra vocês mesmos depois irem procurar as formas mais avançadas.

Também não é objetivo do video explicar arquitetura de segurança de aplicações web. Só usei o exemplo de TLS pra explicar a utilidade de chaves assimétricas. Muita gente ainda tem na cabeça a imagem de que criptografia é meramente uma única chave secreta super longa. Ou até como nos filmes mostra uma chave física mesmo. Quem assistiu o último Missão Impossível? Eles passam o filme todo literalmente atrás de uma chave dividida em duas … não é assim que funciona par de chaves. Mas enfim.

Agora precisamos estar na mesma página sobre outro conceito importantíssimo: impressões digitais ou fingerprints e assinatura digital. Novamente, não vou detalhar o que já expliquei no primeiro video de criptografia. Entenda assim: existem diversas funções de hashing como SHA512 que é um dos mais usados. Existem algumas que já são sabidamente defeituosas e fracas, como o antigo MD5. O MD5 não deve ser usado pra assinatura digital porque não é difícil criar colisões, mas não quer dizer que seja inútil. Dependendo do caso de uso, ela ainda é usada. SHA1 é a mesma coisa, deve ser evitado.

A função SHA 512 tem esse nome porque independente do que passarmos pra ele, o resultado sempre vai ser um número binário de 512 bits, representado como uma string de 128 caracteres, mostrando o binário em formato hexadecimal pra ficar mais fácil de conseguirmos copiar e colar o texto. Pra demonstração, precisamos do programa “sha512sum”. Acho que na maioria das distros Linux já vem pré-instalado. No caso de distros derivadas de Arch, costuma ficar no pacote “coreutils”.

Vamos pegar aquele arquivo “test.txt” que usamos lá atrás e que tinha o conteúdo “Hello World”. Se fizermos “sha512sum test.txt” vai devolver esta string:

sha512sum test.txt
e1c112ff908febc3b98b1693a6cd3564eaf8e5e6ca629d084d9f0eba99247cacdd72e369ff8941397c2807409ff66be64be908da17ad7b8a49a2a26c0e8086aa  test.txt

Olha só. “Hello World” é super curto, mas mesmo assim o resultado do hash é sempre fixo: um número de 512 bits. Vamos editar esse arquivo e fazer uma modificação de nada. Só adicionar um ponto no final do arquivo. Rodamos o mesmo comando “sha512sum” e olha o resultado, é um novo hash completamente diferente. É essa propriedade que tornam hashes importantes.

sha512sum test.txt
cf260f19ff6ac4d64990e2173a7d51252b3bd054cbd1ea5df0841035140592832a2ebc64f17c3dd48e3d8f1682143087217b979de7568c8e1836b008d1a5e463  test.txt

Comparem o hash de antes e o novo. Apesar de ter só adicionado um mísero ponto no final, os hashes são completamente diferentes. Não tem como dizer que vieram de arquivos tão parecidos. E este é o objetivo. Por isso eles servem de impressão digital. Um ser humano lendo um texto mais longo, poderia passar batido numa pontuação fora do lugar. Num documento importante, digamos um contrato, um zero fora do lugar pode significar a diferença entre se comprometer a pagar 100 mil ou 1 milhão de dólares.

Se o contrato tiver 50 páginas, a maioria de nós, seres humanos, íamos passar batido. Mas se o documento original tem uma impressão digital. Basta passarmos o novo documento pelo “sha512sum” e ver se o hash continua batendo. Se bater, temos certeza que o documento está intacto e não foi adulterado. Porém, se o número for diferente, sabemos com certeza que foi adulterado e não pode ser confiado. Não sabemos onde foi adulterado, mas sabemos que foi. Lembram do episódio anterior sobre recuperação de dados? É assim que um sistema de arquivos como ZFS ou BTRFS sabe que um arquivo pode estar corrompido.

Outro exemplo. Vou no site da minha distro favorita, Manjaro e vou baixar a ISO pra instalar. É um arquivão de 3.7 gigabytes. Digamos que eu fiz o download numa rede pública, tipo num aeroporto ou num Starbucks. Como posso garantir que ninguém interceptou minha requisição e me mandou um arquivão falso? Daí quando eu for instalar, na verdade vai instalar um malware?

Chegando numa rede confiável, como minha casa ou escritório, posso baixar esse arquivo de checksum, com extensão .iso.sha512. Agora posso rodar o seguinte comando. Sha512sum passando esse arquivo de SHA e o ISO baixado.

sha512sum -c manjaro-gnome-22.1.3-230529-linux61.iso.sha512
manjaro-gnome-22.1.3-230529-linux61.iso: OK

Se devolver “OK” é porque tá tudo bem, mas o que ele fez? Vamos abrir o arquivo .iso.sha512. É um numerozão no formado da saída do sha512sum. A empresa que faz o Manjaro, que criou o arquivo de instalação original, gerou o sha512 e gravou nesse arquivo pra gente.

cat manjaro-gnome-22.1.3-230529-linux61.iso.sha512
78b8fa6a5222bc10a2e767485e76f82f3c7b2b59f4a70501b4a9fb846c5ad94987cf8b8ed630a701a8a3386debc0a39fc7363a743df8f13f41d3d8324d74e227  manjaro-gnome-22.1.3-230529-linux61.iso

Podemos simplesmente calcular o sha512 em cima do ISO de 3.7 gigabytes com o comando “sha512sum”, igual fizemos com o arquivo do Hello World e olha só, gerou exatamente o mesmo hash. Com isso sabemos que nenhum bit dos 3.7 gigabytes veio adulterado. Se um único bit tivesse sido corrompido no download, o hash gerado seria completamente diferente. Com isso sabemos que o ISO é válido e podemos instalar.

sha512sum manjaro-gnome-22.1.3-230529-linux61.iso
78b8fa6a5222bc10a2e767485e76f82f3c7b2b59f4a70501b4a9fb846c5ad94987cf8b8ed630a701a8a3386debc0a39fc7363a743df8f13f41d3d8324d74e227  manjaro-gnome-22.1.3-230529-linux61.iso

Lembra dos meus videos sobre Git? Esse stringzão não parece com o identificador de um commit? Só que no caso de commit é mais curto. Isso porque Git usa SHA1 em vez de SHA256. SHA1, assim como MD5, também não é mais pra ser usado, mas é difícil migrar pra SHA256 sem quebrar compatibilidade e gerar confusão na cabeça de todo mundo, por isso não usamos SHA256 ainda, mas uma hora Git também deve mudar.

A razão de não usarmos mais MD5 é porque descobriram um bug no seu processo que torna razoavelmente fácil gerar colisões. Ou seja, se modificarmos um determinado documento, cuidadosamente, nos bits certos, temos como mudar o conteúdo e no final o MD5 vai gerar exatamente o mesmo hash. Aí perde o propósito. Descobriram que dá pra fazer isso com SHA1 também, mas não é tão trivial, mesmo assim não é impossível. Não é prático, mas é estatisticamente possível, e isso é suficiente pra considerarmos parar de usar.

Dois conteúdos diferentes que geram o mesmo hash, chamamos de “colisão” e mais cedo ou mais tarde, colisões acontecem. É estatisticamente inevitável, mas é muito difícil de controlar a colisão pra acontecer exatamente quando queremos num SHA256 ou outra função melhor. Mas MD5 e SHA1 já sabemos como controlar as colisões, adicionar bits extras que dá pra ignorar, só pro arquivo no final conseguir chegar no mesmo hash.

Eu explico no video de criptografia sobre hashes usados pra não guardar senhas abertas num banco de dados, assistam depois porque é importante saber disso. Mas caso não saiba, é considerado certificado de estupidez gravar senha dos usuários aberto numa tabela no seu banco de dados. Também é uma idiotice achar que é esperto e gerar o hash da senha e gravar numa tabela. Precisa de salt. E tem algoritmos melhores do que outros. Assista depois pra entender.

O principal é o seguinte: quando um determinado conteúdo, um arquivo ou documento, tem conteúdo secreto, o certo é encriptar o arquivo inteiro usando um algoritmo como AES com uma chave bem longa e forte. Mas pra diversos usos, só pra identificar se foi ou não adulterado, como um contrato, não precisa encriptar o arquivo todo, basta encriptar a impressão digital, que vai ser mais curta. Um exemplo disso é o download da ISO do site da Manjaro.

É um desperdício encriptar uma ISO inteira, não tem nada secreto dentro. É um arquivo público que qualquer um pode baixar e instalar de graça. O problema é saber se a ISO baixada não foi adulterada no meio do caminho. Pra isso tem coisas como o arquivo “.iso.sha512”. Mas tem um outro arquivo no site deles também, olha só, eles chamam de assinatura e é um arquivo “.iso.sig”. Não dá pra listar porque é um arquivo binário, mas é a assinatura do hash da ISO.

O problema de um arquivo .sha512 é que se baixamos os dois ao mesmo tempo, se o ISO foi adulterado no caminho, certamente o arquivo .sha512 também foi adulterado. Por isso, no exemplo, de propósito eu disse que o cenário é que baixei a ISO do aeroporto mas depois baixei o arquivo .sha512 quando cheguei em casa, numa rede confiável. Mas não precisamos confiar na rede pra checar essas coisas.

Antes de sair de casa, o certo é já ter instalado o pacote “GNUPG” o famoso GPG, que é implementação do padrão OpenPGP, de Pretty Good Privacy. É outro pacote que faz uso do conceito de chaves assimétricas, como no exemplo de TLS com RSA ou curva elíptica, lembra? Chaves pública e privada? Só que no exemplo anterior estávamos lidando com certificados .pem pra servidores web. GPG é similar, mas pra identificar pessoas, e não servidores.

Tendo o GPG instalado, no meu caso, que uso Manjaro, eu já teria que ter baixado as chaves GPG da equipe do Manjaro. Só fazer o download do arquivo com “wget” e instalar com “gpg” assim:

wget gitlab.manjaro.org/packages/core/manjaro-keyring/-/raw/master/manjaro.gpg

gpg --import manjaro.gpg

Lembra o conceito que o sistema operacional ou o navegador já trazem certificados raiz de autoridades certificadoras? Aqueles arquivos em “/etc/ssl/certs”? O conceito é parecido. Esse arquivo “manjaro.gpg” tem as chaves confiáveis da equipe do Manjaro. Tudo que a equipe de lá assinar, temos como checar agora.

Eu fiz isso em casa, agora estou no aeroporto e resolvi baixar a ISO do Manjaro. Uma rede pública é o oposto de confiável. Por isso recomendamos sempre usar VPN. Mas digamos que não estou numa VPN e ainda assim quero me arriscar a baixar a ISO. Como eu sei que não veio adulterado? Algum hacker esperto subiu um servidor do note dele, adulterou o DNS do roteador do aeroporto, e agora todo download que eu faço na verdade é um malware?

Baixamos também o arquivo “.iso.sig” e podemos checar com o seguinte comando. GPG verify o arquivo .sig e o arquivo ISO.

gpg --verify manjaro-gnome-22.1.3-230529-linux61.iso.sig manjaro-gnome-22.1.3-230529-linux61.iso
gpg: Signature made seg 29 mai 2023 06:38:26 -03
gpg:                using RSA key 3B794DE6D4320FCE594F4171279E7CF5D8D56EC8
gpg: Good signature from "Manjaro Build Server <build@manjaro.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3B79 4DE6 D432 0FCE 594F  4171 279E 7CF5 D8D5 6EC8

Dentro desse arquivo de assinatura tem o hashing do ISO, assinado pelo Manjaro Build Server. Ele checa o hashing e diz “Good Signature”, então o binário do ISO pelo menos bate com o hashing dentro da assinatura. Mas aí tem um bugzinho que pelo jeito existe faz alguns anos no Manjaro: a chave desse servidor de build não pôde ser confirmado. Sei lá porque não vem já pré-instalado como deveria e quando vai checar dá esse aviso. O certo era ter o certificado raiz desse build@manjaro.org já no meu sistema, mas pelo visto não tem. Bug do Manjaro que até hoje não foi corrigido. Se isso mudou, mandem nos comentários abaixo.

O ponto todo desse exercício foi pra vocês terem na cabeça o que é um hash, uma impressão digital e uma assinatura digital. Deixa eu expandir o exemplo do download da ISO pra algo que muitos de vocês já devem ter usado pelo menos uma vez na vida: BitTorrent. De novo, objetivo do video não é ser uma explicação detalhada sobre BitTorrent, então procurem a documentação depois. Eu quero que vocês consigam entender os conceitos de criptografia que ele usa e como eles resolvem o problema de arquivos distribuídos.

Vamos lá, no próprio site do Manjaro, posso baixar um arquivo .torrent. Um download normal, que é o link do lado, vai puxar os 3.7 gigabytes direto do servidor da empresa do Manjaro. Mas com esse arquivo .torrent, a expectativa é conseguir baixar até mais rápido ou com mais estabilidade, porque vou baixar pedaços da ISO de diversos peers diferentes pela internet. Todo mundo que baixou a ISO e deixou o programa de BitTorrent ativo, está compartilhando o mesmo arquivo. Eu posso baixar pedaços em paralelo de várias pessoas diferentes. Essa é a idéia básica de BitTorrent.

Tangente de história. Nos anos 90 a internet era muito mais lenta que hoje, conexões de modem discado. No mundo dos servidores era tudo super imaturo. Ninguém sabia como manter servidores de download decentes, além de banda ser caro. Era terrível, e no meio disso surgiram os primeiros serviços de compartilhamento de arquivos, vulgo pirataria, como o lendário Napster, seguidos de copycats nos anos 2000 como Limewire, Kazaa, eDonkey e outros.

Mas o princípio na época era só um jeito de dizer pra outras pessoas quais arquivos tem na sua máquina pra compartilhar e deixar todo mundo baixar livremente. É o modelo mais simples de compartilhamento de arquivos. Foram anos de controvérsia, diversos processos da indústria de música, até culminar no surgimento dos primeiros serviços comerciais de venda de música e depois de assinatura como iTunes e hoje Spotify.

O grande defeito desse modelo simples de compartilhamento, é que era muito fácil identificar quem tinha os arquivos e ir processar direto essa pessoa, derrubando o compartilhamento. Uma vez que desliga a máquina do cara, somem os arquivos e ninguém baixa mais. Esse era o problema a ser resolvido. O problema ainda não foi totalmente resolvido, mas vamos ver como BitTorrent melhorou radicalmente nossa situação.

Primeiro de tudo, precisamos acabar com o conceito de um servidor único, centralizado de arquivos, de onde todo mundo puxa. É o mesmo problema do servidor de ISOs da Manjaro. Se todo mundo vai no mesmo lugar pra baixar, quanto mais gente descobrir o servidor, mais lento vai ficar pra todo mundo, e maiores os riscos desse servidor cair ou ser derrubado e todo mundo ficar sem nada.

Lembra da minha série sobre armazenamento, sistemas de arquivos e tudo mais? O que é um arquivo? É só um linguição de bits. Por baixo dos panos, eles são organizados como blocos de bits. Podemos picotar um arquivo como quiser e depois remontar. Inclusive é assim que eles são gravados em HDs e SSDs: fora de ordem. Vamos simular esse exercício num terminal de Linux só pra terem essa imagem na cabeça.

Podemos fazer isso com qualquer arquivo, seja texto ou binário, já expliquei que pro computador não faz diferença nenhuma, por baixo é tudo um linguição de bits. Só pra nós humanos que faz diferença porque arquivos texto conseguimos abrir e ler. De exemplo, peguei o script do episódio 142 que foi a explicação sobre ChatGPT. Esse script tem 94 kilobytes, ou seja, 94 mil letras. Quero conseguir dividir isso em arquivos iguais de exatamente 10 kilobytes cada, pra simular blocos de 10 kilobytes.

Pra isso usamos o comando “split” que tem em Linux. Só passar o tamanho de cada pedaço, o arquivo original e o prefixo do nome dos pedaços, que vou chamar de chunk.

split -b 10K subtitle_142.txt chunk_

❯ ls -la
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_aa
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_ab
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_ac
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_ad
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_ae
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_af
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_ag
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_ah
.rw-r--r--  10k akitaonrails 18 jul 13:22  chunk_ai
.rw-r--r-- 1,5k akitaonrails 18 jul 13:22  chunk_aj
.rw-r-----  94k akitaonrails 18 jul 13:21  subtitle_142.txt

Pronto, obviamente, só o último arquivo vai ser menos que 10 kilobytes, mas vejam como consegui dividir direitinho. Posso tentar dar cat em qualquer pedaço e vai vir o trecho do script. Quebrar arquivos grandes em pedaços menores era algo que fazíamos o tempo todo nos anos 90 porque era muito arriscado tentar fazer download de um arquivo gigante. O modem podia desligar no meio do caminho, algoritmos de checagem de corrupção ainda não eram difundidos, então podia vir sujeira na linha e o arquivo ser corrompido. Se viesse corrompido, precisava mandar baixar tudo de novo do zero.

Então dividíamos o risco. Era melhor deixar agendado pra ir baixando um pedaço de cada vez. Se alguma coisa desse errado, só um pedaço ia ser corrompido e dava pra baixar só aquele pedaço separado depois, em vez de ter que recomeçar do zero. Hoje em dia o próprio protocolo HTTP suporta resumir um download pela metade e o protocolo TCP garante que os pacotes não vão vir corrompidos, como já expliquei na série de redes. Mas estou falando de uma era antes dessas facilidades.

E agora vocês já sabem. Uma forma de manualmente checar se meus pedaços vieram corretamente seria ter um arquivo com o hash de cada pedaço. Assim podemos comparar o hash do download e ver se nada foi corrompido. Lembra? Como estou falando de anos 90, poderíamos fazer o SHA1 de cada pedaço. Por exemplo, eis o hash do primeiro pedaço, com o comando sha1sum:

❯ sha1sum chunk_aa
c3bb4df901fb79af2421cc274e9db87309bf6424  chunk_aa

Com um pouco de mágica de script de shell, podemos fazer a mesma coisa pra todos os pedaços e colocar num arquivo “index.txt” da seguinte forma, fazendo, pra cada file, ou arquivo, que começa com “chunk”, gere o sha1 e vá adicionando nesse arquivo index.txt.

for file in chunk_*; do
    sha1=$(sha1sum "$file" | awk '{print $1}')
    echo "$file $sha1" >> index.txt
done


/tmp/subtitle 
❯ cat index.txt 
chunk_aa c3bb4df901fb79af2421cc274e9db87309bf6424
chunk_ab 79a5c1fb9a9708982a92009d874bd9ee3db65a31
chunk_ac 84de6f8eb80fc64628514500b8d6b09ff930bda5
chunk_ad 2f68d9f1caffdfca69b28ae33348cdd0ca467474
chunk_ae c644daae2adcc6c87b8b4ee91052535c50edbe4f
chunk_af de3471b65337f2ffb2d97bbd6ef45b1e95d6ba88
chunk_ag 454093fda498e7f67cacb0919e3a5ffa579d0cb6
chunk_ah a0d040c39213188382dc681d7a74da283bfb07c0
chunk_ai 0469b41afb556f10c01cca5f099a81e6b5e17a31
chunk_aj 45fa07b4fdfea4a0a5c02abcad6520b652264a25

Por isso é interessante aprender sobre scripts de shell. Abrindo o arquivo “index.txt” com “cat” temos o nome do arquivo de cada pedaço seguido do seu hash SHA1. Olhem como o sha1 do primeiro arquivo bate com o que geramos na mão antes. Então está correto. Além disso, esse arquivo me diz exatamente a totalidade dos pedaços que preciso baixar. Poderíamos fazer outro script pra baixar cada pedaço, checar o SHA1 e se vier errado, mandar refazer o download só daquele pedaço. Fica de exercício pra vocês fazerem isso.

Ok, fizemos o download de todos os pedaços. E agora? Como remontamos o arquivo original? É simples, bastar dar “cat” de todos os pedaços e redirecionar pra um arquivo final, assim, cat chunk asterisco maior pra restored.txt:

cat chunk_* > restored.txt

❯ sha512sum restored.txt   
bfec6c9efe398146b8197b7b0258860563f6057dac7f6d1931ec5d4118c730d47007678ddd2cf9387b5b02903c7dd35a1911a2da4707d624ce4e996514a766c6  restored.txt

/tmp/subtitle 
❯ sha512sum subtitle_142.txt 
bfec6c9efe398146b8197b7b0258860563f6057dac7f6d1931ec5d4118c730d47007678ddd2cf9387b5b02903c7dd35a1911a2da4707d624ce4e996514a766c6  subtitle_142.txt

Isso funciona em shells modernos porque a maioria sempre lista os arquivos em ordem alfabética. Caso o seu não faça isso, precisaria primeiro usar o comando “sort”, de novo, fica de exercício. Mas assumindo que o cat pegou cada arquivo chunk na ordem certa, como sei que o arquivo restored.txt realmente é idêntico ao original? Vocês já sabem né? Só comparar o hash dos dois. E como podem ver, é exatamente igual. Se um único bit tivesse vindo errado, os hashes seriam diferentes.

Estão entendendo como podemos manipular qualquer tipo de dados e garantir a integridade deles via ferramentas criptográficas? Sabendo desses conceitos, vou fazer uma explicação super de alto nível pra explicar como BitTorrent tira proveito disso que acabei de explicar.

Existem duas formas de baixar um arquivo via Torrent. Um é baixando um arquivo .torrent, como aquele do site do Manjaro. Podemos usar o programa “transmission-show” que vem no pacote “transmission-cli” pra abrir e ver o conteúdo desse arquivo.

❯ transmission-show manjaro-gnome-22.1.3-230529-linux61.iso.torrent 
Name: manjaro-gnome-22.1.3-230529-linux61.iso
File: manjaro-gnome-22.1.3-230529-linux61.iso.torrent

GENERAL

  Name: manjaro-gnome-22.1.3-230529-linux61.iso
  Hash v1: 68617f6ffc9f95bbca41733556f666739f647f9c
  Created by: mktorrent 1.1
  Created on: Mon May 29 06:38:30 2023

  Piece Count: 1769
  Piece Size: 2.00 MiB
  Total Size: 3.71 GB
  Privacy: Public torrent

TRACKERS

  Tier #1
  udp://tracker.opentrackr.org:1337

WEBSEEDS

  https://download.manjaro.org/gnome/22.1.3/manjaro-gnome-22.1.3-230529-linux61.iso

FILES

  manjaro-gnome-22.1.3-230529-linux61.iso (3.71 GB)

O importante desse arquivo é que ele identifica o que vamos baixar, no caso o ISO, e onde podemos achar esse arquivo. Primeiro temos esse tal de tracker. Um tracker é um servidor que contém listas de peers que estão online e que tem o arquivo com este hash. Se tiver pelo menos 1 peer ativo que seja um seeder, vai começar a baixar. Peer é o nome que damos pra qualquer máquina, PC, servidor, participando dessa rede. Um tracker não necessariamente tem o arquivo ou seus pedaços, mas sabe quem pode ter, que são os peers.

Você já deve ter visto essa nomenclatura em programas de torrent como QBitTorrent ou Transmission. Quanto mais seeders tiver ativo, melhor será o download. Seeder são computadores online que também estão compartilhando o mesmo arquivo ou pedaços. Leechers são computadores online fazendo download mas não contribuindo em nada. Parasitando mesmo, leeching. O algoritmo do BitTorrent tenta ser justo e deixar download mais rápido pra quem contribui e download mais lento pra quem é só parasita.

Trackers só compartilham e sincronizam a lista de peers, peers podem ser tanto seeders quanto leechers. Quanto mais seeders, mais rápido o download, quanto mais leechers e menos seeders, mais lento o download. O mundo ideal é todo mundo ser seeder. Alguns são chatos e desligam mesmo, outros realmente não conseguem contribuir porque a rede do provedor bloqueia e eles não sabem como furar firewall. Eu falo de furar firewall na série de redes. Depois procurem saber mais como habilitar portas, usar VPN pra torrent e coisas assim, não vou falar disso hoje.

Vamos voltar pro arquivo .torrent. Olhem outras informações que ele nos dá. Sabemos que o arquivo ISO tem 3.7 gigabytes, como já repeti várias vezes, e sabemos que este torrent está organizado em mil setecentos e sessenta e nove pedaços de 2 megabytes cada. Lembra os chunks que fiz usando o comando split? É a mesma coisa. Ele não mostra aqui, mas dentro desse torrent vai ter uma lista de pedaços seguido do hash de cada pedaço, parecido com aquele arquivo “index.txt” que fiz no exemplo.

Cada seeder que o tracker conhece, vai ter ou o arquivo inteiro ou o arquivo parcial, porque ainda não terminou o download. Agora eu, que comecei o download agora, começo a baixar cada um desses pedaços de cada um dos seeders disponíveis, em paralelo. Por exemplo, digamos que na rede tenha o seeder John, a seeder Sara e o seeder Kyle. E eu vou baixar aquele meu arquivo de script. Começo a baixar o chunk_aa do John, o chunk_ab da Sara, o chunk_ac do Kyle e assim por diante.

Toda vez que um chunk termina de baixar, consigo checar o hash e sei que tá correto, daí peço o chunk seguinte, distribuindo a carga entre todos os seeders. Se outra pessoa aparecer pedindo o mesmo arquivo, talvez ele pegue um chunk de mim. Entenderam? O seeder não precisa ter o arquivo completo pra começar a contribuir, basta ter pelo menos um chunk completo. E por isso, quanto mais gente tiver, menos pesado fica pra todo mundo, especialmente pro servidor principal da Manjaro. É a base de computação distribuída.

Se não tiver nenhum seeder ativo, o arquivo .torrent aponta pra um Webseed, que é o link pro arquivo original no servidor da Manjaro. Daí seria como um download direto normal mesmo. Entenderam até aqui: com uma lista de pedaços e seus respectivos hashes, distribuídos entre diversos computadores num swarm, ou enxame, e cada um baixando um pedaço do computador do outro, até todo mundo ter o arquivo completo, essa é a arquitetura básica por trás do BitTorrent.

BitTorrent é “decentralizado” no sentido que, diferente de um iTunes da Apple, não tem uma única empresa nem um único servidor que centraliza os downloads. Eis alguns mecanismos que tornam o BitTorrent resiliente, embora não totalmente invulnerável.

De cara, poderíamos pensar que se derrubarmos quem mantém trackers, poderíamos parar um enxame, não? Primeiro, não existe somente um tracker, existem diversos trackers servindo um de backup pro outro. Precisaria derrubar todos os trackers em atividade no mundo. Mas isso não seria suficiente.

Toda vez que você abre um programa como Transmission ou Nano Torrent da vida, ele faz “bootstrapping” usando uma lista de “bootstrapping nodes”, uma lista de nós bem conhecidos na rede que acreditamos que costumam estar online, vários deles. São esses nós que nos ajudam a achar outros nós. Assim como trackers, eles também não são pontos únicos de falha.

Quando seu programa se conecta e acha um tracker ou um bootstrapping node, ele se junta à rede DHT ou Hash Table distribuído. Cada nó que entra na rede armazena informação sobre a rede toda ou um pedaço da rede. Então, quando você pergunta ao DHT por alguma coisa, seu cliente de BitTorrent manda uma requisição pra um nó que ele conhece. Esse nó ou vai ter a informação e te retornar ou vai te direcionar pra outro nó que pode saber essa informação. A partir desse ponto você, como nó da rede, passa a ter essa informação e pode responder a alguém que te perguntar também. Todo mundo se torna backup e contribui pra outras pessoas.

O conceito de trackers é um pouco obsoleto na realidade, das primeiras versões de BitTorrent. Ele veio evoluindo e agora temos o conceito de DHT e PEX que é Peer Exchange. Mesmo derrubando todos os trackers, cada pessoa conectada na rede contribui pra distribuir a informação do resto da rede. Hoje em dia os programas de BitTorrent implementam as duas maneiras.

Eu falei do arquivo .torrent que baixamos pra começar um download via BitTorrent, mas nem precisamos desse arquivo. Vocês já devem ter visto o que se chama de link magnético, que é tipo uma URL que usa o protocolo “magnet”. Lembram o arquivo .torrent da ISO do Manjaro que baixamos? Podemos gerar um link a partir dele usando o programa “transmission-show” com a opção “-m”:

❯ transmission-show -m /mnt/terachad/Downloads/manjaro-gnome-22.1.3-230529-linux61.iso.torrent
magnet:?xt=urn:btih:68617f6ffc9f95bbca41733556f666739f647f9c&dn=manjaro-gnome-22.1.3-230529-linux61.iso&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&ws=https%3A%2F%2Fdownload.manjaro.org%2Fgnome%2F22.1.3%2Fmanjaro-gnome-22.1.3-230529-linux61.iso

É esse link que encontramos em diversos sites que listam torrents pra baixar. Veja num Piratebay da vida, onde tem esse ícone de ímã. Quando clica, automaticamente pede pra abrir seu programa de Torrent instalado. A parte mais importante é esse “btih” logo no começo que é o BitTorrent InfoHash, o hash que identifica unicamente esse arquivo de ISO. O resto ajuda mas é opcional. Por exemplo, ele tem o link pro webseed caso ninguém esteja oferecendo o arquivo na rede e também o link pra um tracker.

Vamos fazer um html idiota com o link pra esse magnet. Um link com a URL inteira que foi gerado e um segundo link só com o infohash.

<html>
 <body>
  <p><a href="magnet:?xt=urn:btih:68617f6ffc9f95bbca41733556f666739f647f9c&dn=manjaro-gnome-22.1.3-230529-linux61.iso&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&ws=https%3A%2F%2Fdownload.manjaro.org%2Fgnome%2F22.1.3%2Fmanjaro-gnome-22.1.3-230529-linux61.iso">Magnet pro ISO</a></p>
  <p><a href="magnet:?xt=urn:btih:68617f6ffc9f95bbca41733556f666739f647f9c">Magnet pro ISO (só infohash)</a></p>
 </body>
</html>

Se abrir num navegador e clicar no link, o media type está associado ao QBitTorrent instalado no meu Manjaro. Ele abre e oferece pra começar a baixar. Se eu abrir pelo segundo link, mesmo sem informação de webseed e nem de tracker, só com o infohash, olha só, abre normalmente e oferece pra baixar igual. Isso porque o QBitTorrent na minha máquina se uniu à rede, via DHT e PEX e conseguiu achar os seeders e já sabe como começar a baixar.

Entenderam? Pra parar um arquivo de ser compartilhado, não basta derrubar todos os trackers, precisa parar 100% de todo mundo que está compartilhando o arquivo, de todas as partes do mundo, ao mesmo tempo. Se tiver só um nó na rede funcionando, dá pra continuar compartilhando, porque via DHT e PEX, essa informação vai voltar a ser distribuída. Computação distribuída é fascinante por causa disso: ninguém consegue parar somente com uma canetada sem comprometer a internet inteira de funcionar direito. Por isso eu gosto desse conceito.

DHT e PEX são assuntos fascinantes por si só, pra garantir a descentralização da rede, então espero que vocês pesquisem mais sobre isso depois. Ótimo tema pra TCC. Mas tem um assunto menos comentado que eu acho ainda mais interessante. É o conceito de Árvores de Hashes ou Merkle Trees, nome dado por causa do criador do conceito, Ralph Merkle, que inventou isso no fim dos anos 70.

Vamos lá. O que temos até agora é um arquivo “index.txt” com uma lista de chunks ou pedaços daquele meu arquivo de script. 10 pedaços com o hash SHA1 do lado de cada um, lembram? Numa versão rudimentar de BitTorrent, eu poderia ter baixado esse arquivo e perguntado na tabela distribuída de hashes, o tal DHT, de onde baixar cada pedaço, identificado pelo SHA1, que serve como um ID único pra cada pedaço.

Depois que fizer o download de cada pedaço, basta rodar o comando “sha1sum” e comparar o hash com o que tem no arquivo “index.txt”. Se bater é porque veio correto, sem corromper nem nada. No final, basta concatenar os pedaços como fiz antes, gerar o hash do arquivo todo, comparar com o hash mestre do arquivo original, pra garantir que tenho o mesmo arquivo no final. Parece simples e parece que só isso é o suficiente.

Mas no mundo real tem várias razões de porque isso não é suficiente. Pra começar, via BitTorrent podemos trafegar arquivos de qualquer tamanho gigante, posso compartilhar diretórios inteiros com milhares de arquivos. Eu poderia fazer um torrent do C: inteiro do meu Windows se quisesse. E posso puxar pedaços de diversos nós diferentes no enxame de computadores participando na rede. Pra validar o hash de tudo, dessa forma, não seria prático. Imagine ter que computar o hashzão do seu HD inteiro pra saber se o que fiz download tá correto. Seria muito pesado, em alguns casos até inviável.

Em programação, você sempre vai bater nesse caso: pra um arquivo pequeno, com poucos kilobytes ou megabytes de tamanho, o esquema simples de um arquivo de hashes é mais que suficiente. Mas pra escala de internet, onde podemos querer lidar com gigabytes ou terabytes, milhares de arquivos num mesmo torrent, não vai escalar.

Pense assim, temos 10 hashes, um pra cada pedaço, e temos 1 hash mestre, que valida o arquivo completo inteiro. Eu recebo esses hashes e começo a fazer download de algum nó. Veio esse primeiro pedaço chunk_aa, o hash começa com c3bb. Eu rodo o comando sha1sum e vejo que, sim, o hash começa com c3bb mesmo. Bacana. Isso só garante que o pedaço é quem ele diz que é, mas como eu sei que de fato esse pedaço faz parte do arquivão inteiro?

A única forma é baixar todos os 10 pedaços, concatenar tudo, rodar o “sha1sum” pro arquivo gerado e comparar com o hash mestre. Só assim vou saber que todos os pedaços são realmente válidos pra esse arquivo, entenderam? Os hashes individuais não me dizem nada sobre o arquivo inteiro original. Eu tenho que confiar que o nó da rede, que me deu essa informação, não mentiu pra mim. Imagina se fosse um torrent como falei antes, com vários arquivos e muitos gigabytes. Eu só ia ter certeza que todos são válidos depois que baixar tudo.

Em BitTorrent, vocês já devem ter visto que podemos escolher baixar somente alguns dos arquivos e não todos. Então, de cara, esse esquema de só ter um hash mestre pra tudo não funciona. Eu preciso de hashes parciais, no mínimo um pra cada arquivo separado, não? E mesmo assim, preciso garantir que esse arquivo, uma vez que baixei os pedaços e montei, de fato faz parte do conjunto todo, sem ter que baixar o conjunto todo. Como faz?

Pra simplificar, vamos partir de novo do exemplo de 10 pedaços. Imagine que isso poderia ser um arquivo de milhares de pedaços e dezenas de arquivos em sub-diretórios. É uma simplificação, ok? Pois bem, começo organizando esses pedaços em pares. chunk_aa com chunk_ab, depois chunk_ac com chunk_ad e assim por diante. Pares de pedaços.

Agora pegamos o hash de cada par e concatenamos só eles. Por exemplo, o hash c3bb do chunk_aa com o hash 79a4 do chunk_ab. E gero o hash dessa combinação. Vai dar um hash que começa com “0285”. Faço a mesma coisa com os hashes do próximo par, vai dar um novo hash que começa com “84de” e continuo fazendo isso pros outros pares.

/tmp/subtitle 
❯ echo "c3bb4df901fb79af2421cc274e9db87309bf642479a5c1fb9a9708982a92009d874bd9ee3db65a31" | sha1sum
0285f4ec89c694112c330ec20a571457a4e159f2  -

/tmp/subtitle 
❯ echo "84de6f8eb80fc64628514500b8d6b09ff930bda52f68d9f1caffdfca69b28ae33348cdd0ca467474" | sha1sum
05e420886ad96877bd78051df8a01c4a9414cc33  -

/tmp/subtitle 
❯ echo "c644daae2adcc6c87b8b4ee91052535c50edbe4fde3471b65337f2ffb2d97bbd6ef45b1e95d6ba88" | sha1sum
d9e3a713ccd57d87adb4ea04aede0cebdcc8fd8e  -

/tmp/subtitle 
❯ echo "454093fda498e7f67cacb0919e3a5ffa579d0cb6a0d040c39213188382dc681d7a74da283bfb07c0" | sha1sum
4c6b2637222b6a7cc9e52a3d5441dedcdf00b4e6  -

/tmp/subtitle 
❯ echo "0469b41afb556f10c01cca5f099a81e6b5e17a3145fa07b4fdfea4a0a5c02abcad6520b652264a25" | sha1sum
65c704fefd21e50f92df28de813ef2d3b4d7cff4  -

0285f4ec89c694112c330ec20a571457a4e159f2
05e420886ad96877bd78051df8a01c4a9414cc33
d9e3a713ccd57d87adb4ea04aede0cebdcc8fd8e
4c6b2637222b6a7cc9e52a3d5441dedcdf00b4e6
65c704fefd21e50f92df28de813ef2d3b4d7cff4

No final vou ter 5 novos hashes. Agora repito o mesmo processo. Organizo pares de hashes, concateno e gero um novo hash pra cada par. Pego esse hash que começa com “0285” com o hash que começa com “05e4” e gero o hash que começa com “9361”. Faço isso pro segundo par. Só no terceiro par que vou ter problemas porque o último hash vai ficar sozinho. Não tem problema, gero o hash dele também, concatenado com vazio mesmo.

/tmp/subtitle 
❯ echo "0285f4ec89c694112c330ec20a571457a4e159f205e420886ad96877bd78051df8a01c4a9414cc33" | sha1sum
9361c518dbcc3374c2d9a6c343dfa903f5226219  -

/tmp/subtitle 
❯ echo "d9e3a713ccd57d87adb4ea04aede0cebdcc8fd8e4c6b2637222b6a7cc9e52a3d5441dedcdf00b4e6" | sha1sum
910ec073793aafe29790941efe004c17debdc2d9  -

/tmp/subtitle 
❯ echo "65c704fefd21e50f92df28de813ef2d3b4d7cff4" | sha1sum
2924e53ff12eae61d88da7a0cca2967150881598  -

Vamos repetir mais uma vez. Par de hashes “9361” com “910e” vai dar “bdf3” e o último hash é “2354”. E pronto. Chegamos ao final, temos só dois hashes resultantes. Geramos o hash da concatenação desses dois também. Vai dar um hash final que começa com “f2fb”. Esse hash é especial, é o que chamamos de Merkle Root ou Raiz Merkle. É o hash que engloba todos os outros hashes.

/tmp/subtitle 
❯ echo "9361c518dbcc3374c2d9a6c343dfa903f5226219910ec073793aafe29790941efe004c17debdc2d9" | sha1sum
bdf3037c43dbe2cb7bf318a38948b3a504bea5d7  -

/tmp/subtitle 
❯ echo "2924e53ff12eae61d88da7a0cca2967150881598" | sha1sum
2354ddf1e76303140524dad59d5c2c3f418d87b7  -



/tmp/subtitle 
❯ echo "bdf3037c43dbe2cb7bf318a38948b3a504bea5d72354ddf1e76303140524dad59d5c2c3f418d87b7" | sha1sum
f2fb982d0f416376d64a7b451fa2d2176bf45ca8  -

chunk_aa c3bb
chunk_ab 79a5  0285
chunk_ac 84de
chunk_ad 2f68  05e4  9361
chunk_ae c644
chunk_af de34  d9e3
chunk_ag 4540
chunk_ah a0d0  4c6b  910e  bdf3
chunk_ai 0469
chunk_aj 45fa   65c7  2924  2354  f2fb

Antes, se eu só tivesse o hash mestre, precisaria de todos os 10 hashes de cada pedaço pra saber se tá tudo correto. Mas nesse esquema da árvore de Merkle, digamos que eu queira saber se o pedaço “aa” que acabei de baixar realmente faz parte do arquivo final, sem baixar os outros pedaços, como eu faço? Peço pro servidor somente os hashes do irmão “ab”, com isso consigo calcular “aa” e “ab” como fiz antes. Daí preciso que o servidor me mande os 4 hashes “acad”, “aeaf”, “agah”, “aiaj”.

Tendo somente esses 4 hashes, mais o hash do pedaço “aa”, consigo recalcular a árvore e achar a raiz Merkle e comparar com o que o servidor me indicou. Se bater, quer dizer que esse pedaço que baixei faz parte do arquivo final. Repetindo: eu diminuí a necessidade de precisar de todos os 10 hashes pra somente 4 hashes, sacaram?

De novo, é um exemplo super pequeno e simples só pra caber aqui na tela. Mas veja aquele exemplo da ISO do Manjaro, lembram? Eram quase mil e oitocentos pedaços. Se eu baixar só um pedaço, pra garantir que ele faz realmente parte do ISO original, precisaria calcular o hash mestre usando todos os quase mil e oitocentos hashes. Mas organizado numa árvore, precisaria só de uns log2(2048) que dá 11.

A árvore precisa ser balanceada, e o próximo número acima de mil e oitocentos que balanceia uma árvore binária é 2048. Enfim, eu preciso que o servidor me mande a raiz Merkle que ele tem pré-calculado e 11 hashes dessa árvore, mais ou menos. Não é um número exato esse log. Mas entenda que 11 é uma ordem de grandeza menos hashes do que mil e oitocentos. Mesmo nesse exemplo simples de só uma ISO de Manjaro, já temos um ganho significativo.

BitTorrent não foi criado com árvores Merkle, isso é uma coisa mais recente. Da mesma forma que hoje não precisaria de trackers por causa de DHT e PEX. É uma tecnologia ainda em evolução. Lembram do que eu falei no video sobre bancos de dados: árvores são as estruturas de dados mais importantes da computação, tudo são árvores. Nesse caso, árvores binárias, mas já falei de B-trees ou B+Trees em sistemas de arquivos. Assistam meu video de Árvores depois.

Sabe que outro programa se beneficia de árvores Merkle? Git. O que são commits? São diffs com trechos de arquivos de código fonte, mais metadados, como nome do arquivo, autor da modificação, datas. Uma característica importante de um commit é que ele é identificado por um hash, um SHA1 do seu conteúdo. É como sabemos que o conteúdo não foi adulterado, da mesma forma como fizemos pra checar os chunks do download via BitTorrent.

Mas um commit de Git tem outra característica importante: ele contém o SHA1 do commit pai anterior. Por isso commits formam uma cadeia, mais especificamente, uma árvore. Objetos de árvore de diretórios também tem SHA1 dos objetos filho. Tudo isso forma um DAG, um direct acyclic graph ou grafo direcionado não cíclico, mais especificamente um Merkle DAG.

Uma característica importante é que como todo commit contém o SHA1 do commit anterior, é impossível modificar só um commit no meio da árvore. Precisaria reescrever todos os commits na frente e regerar SHA1 novos pra todos. É o que chamamos de “reescrever a história”. Vocês já devem ter ouvido falar disso em discussões se é melhor fazer merge ou rebase e todo mundo é contra fazer rebases na master porque isso “reescreve a história”. É isso que significa reescrever a história: tem que regerar o SHA1 de todos os commits pra frente.

Deixa eu mostrar rapidamente com um exemplo. Vamos iniciar um novo repositório com “git init” e criar um arquivo de teste idiota só pra criar o primeiro commit.

❯ git init
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint: 
hint:  git config --global init.defaultBranch <name>
hint: 
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint: 
hint:  git branch -m <name>
Initialized empty Git repository in /tmp/teste/.git/



teste on  master 
❯ echo "hello world" > hello.txt

teste on  master [?] 
❯ git a .

teste on  master [+] 
❯ git c "initial commit"
[master (root-commit) 308ba8d] initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 hello.txt

Fazendo “git log” vemos o commit identificado pelo hash que começa com “4b4c”. Agora vamos criar um novo branch chamado “teste”, modificar o arquivo e criar um novo commit. No caso criou um novo commit identificado pelo hash que começa com “65c2”. (no exemplo abaixo está com outro hash porque refiz o exemplo e a mudança de data gera hashes diferentes)

commit 1eb601ac03c713abaa08fd54e002eec04ee66922 (HEAD -> teste)
Author: AkitaOnRails <fabioakita@gmail.com>
Date:   Thu Aug 24 11:54:32 2023 -0300

    adding hello again

commit 308ba8d7ee9ac84c6b318393614203e2b905f0f4 (master)
Author: AkitaOnRails <fabioakita@gmail.com>
Date:   Thu Aug 24 11:53:28 2023 -0300

    initial commit

Agora vou voltar pro branch master, criar um novo arquivo qualquer e gravar em outro commit. Veja só, criou esse commit com hash que começa com “9431”. Agora, em vez de merge vou fazer rebase do branch teste em cima do branch master com “git rebase teste”. Como não fiz nada demais, vai terminar sem nenhum conflito.

commit 921bb4796a2545fabc87324b5a8fa069d53201f2 (HEAD -> master)
Author: AkitaOnRails <fabioakita@gmail.com>
Date:   Thu Aug 24 11:55:16 2023 -0300

    adding foo

commit 1eb601ac03c713abaa08fd54e002eec04ee66922 (teste)
Author: AkitaOnRails <fabioakita@gmail.com>
Date:   Thu Aug 24 11:54:32 2023 -0300

    adding hello again

commit 308ba8d7ee9ac84c6b318393614203e2b905f0f4
Author: AkitaOnRails <fabioakita@gmail.com>
Date:   Thu Aug 24 11:53:28 2023 -0300

    initial commit

Fazemos “git log” e olha só, o commit que eu tinha acabado de fazer, que tinha o hash começando em “9431” agora começa com “ee00”. Isso porque antes, o commit anterior era o “initial commit” com hash “4b4c”. Como fiz rebase, ele trouxe o commit “adding hello again” de hash “65c2”, que passa a ser o novo pai do commit “adding teste”, portanto o hash desse commit tem que ser recalculado e por isso mudou pra “ee00”, ou seja, acabamos de reescrever a história.

Esse conceito é muito importante. Ao colocar o SHA1 do commit anterior no commit atual, criamos uma dependência entre esses dois objetos. Se o objeto anterior mudar, se seu hash mudar, o hash do objeto seguinte vai ser invalidado e precisa ser recalculado também. Não dá pra simplesmente entuchar um commit no meio da cadeia sem consequências e é isso que garante a integridade do código fonte armazenado nesse repositório.

Se alguém tentar adulterar um commit lá atrás no passado, ele vai ser obrigado a fazer rebase de tudo pra frente, ou seja, recalcular o SHA1 de todo mundo. Daí todo mundo vai imediatamente saber que o repositório foi modificado, porque os IDs de tudo vão estar diferentes. É onde temos que lidar com conflitos depois. Se você nunca parou pra entender como o Git realmente funciona, recomendo que assista meu video de “Entendendo Git”.

Entenda, ter um Merkle Tree não impede que um commit seja adulterado. Só torna mais fácil de identificar quando for. E torna mais barato fazer os cálculos pra chegar nessa conclusão, do que ter que checar o SHA1 de 100% de tudo. No caso de Git, que é um repositório decentralizado, digamos que era uma equipe de 5 pessoas. Uma delas faz pull do GitHub e nota que alguém fez merda e deu “push –force” de um rebase gigante que reescreveu centenas de commits.

Você consegue ver que isso aconteceu e consegue ligar pra um dos outros colegas que ainda não fez “pull” e pedir pra ele dar um novo “push –force” pra recuperar o histórico como era antes e eliminar a cagada. O fato de termos várias cópias do mesmo repositório nas máquinas de todo mundo é um tipo de backup. Se o repositório elegido como principal ficou zoado, tem formas de recuperar. E não precisa sobrescrever tudo, só a partir do commit onde deu rebase, entenderam?

Existem várias discussões sobre centralizadores de Git como GitHub ou GitLab. Eles centralizaram a confiança de Git neles, mas Git originalmente não era pra ter um ponto único de falha. Você pode fazer git clone do repositório de alguém localmente, num pendrive, como mostrei no episódio anterior. Não precisa obrigatoriamente ter que fazer git clone de um repositório do GitHub. Isso é outra discussão, só pra vocês saberem que Git também foi feito pra ser distribuído, mas hoje em dia usamos centralizado num GitHub da vida.

Voltando pro exemplo de BitTorrent. Como qualquer computador na internet pode participar do compartilhamento de arquivos, sim, algum computador malicioso poderia começar a tentar espalhar binários adulterados. Mas o principal é o arquivo .torrent ou link magnético que aponta pra algum nó que normalmente confiamos, que vai nos fornecer a árvore Merkle com os hashes. Tendo os hashes, conseguimos checar se os pedaços que baixamos são válidos ou não.

Esses hashes são organizados numa tabelona, mais especificamente numa tabela distribuída, ou Distributed Hash Table, o DHT que eu fico falando. Pra quem é desenvolvedor web, é parecido com um DynamoDB. Cada item nessa tabelona ganha um ID longo de 160 bits. E os possíveis IDs são particionados entre os diversos nós da rede, de tal forma que cada nó só é responsável por um pedaço do espaço de IDs possíveis.

Toda vez que algum nó precisa registrar alguma coisa, ele gera uma chave e com isso determina qual nó que é responsável pelo espaço de IDs que essa nova chave faz parte, e manda pra esse nó. Mesma coisa pra pesquisar dados na tabela, tendo o ID pra consultar, ele pergunta pro nó responsável por esse intervalo de IDs.

Uma rede de BitTorrent é gigantesca, milhares ou milhões de nós ao mesmo tempo. É impossível meu computador saber quais são todos os nós ativos neste exato momento no mundo. Em vez disso, cada nó mantém um tipo de tabela de roteamento com informações sobre um sub-conjunto dos nós na rede, preferencialmente os mais “próximos” do espaço de IDs. Quando alguém pede pro seu nó gravar ou ler um certo ID mas você não é o responsável, dá pra usar essa tabela de roteamento pra redirecionar pro nó certo.

E claro, um nó pode simplesmente desaparecer do nada. Como cada nó pode ser um computador caseiro, alguém pode desligar o PC e sair da rede. Por isso essas informações são redundantes entre vários nós. Os algoritmos de DHT e roteamento vão se balanceando e atualizando dinamicamente com nós entrando e nós saindo.

Se isso pareceu similar a um banco de dados NoSQL distribuído como Amazon DynamoDB ou Cassandra, é porque é. Uns três ou quatro episódios atrás eu expliquei como funcionam chaves distribuídas, depois assistam. BitTorrent não deixa de ser um grande banco de dados NoSQL distribuído. São tecnologias similares. Toda vez que você abre um programa como Transmission ou QBitTorrent pra baixar alguma coisa, está participando dessa coordenação toda e se tornando um nó réplica de um grande banco de dados NoSQL distribuído. Você só não sabia disso.

Diferente de um banco de dados, eu não preciso que todos os dados que já foram gravados num DHT, permaneçam lá pra sempre. Arquivos novos aparecem, arquivos que ninguém mais quer desaparecem. Se não tem ninguém compartilhando algum determinado arquivo, não preciso ter informações dele trafegando. Seria ineficiente. Só interessa arquivos que alguém está compartilhando.

Num Git não, eu preciso que tudo que os desenvolvedores do projeto fizeram, seja adicionar novos arquivos, modificar existentes, ou até apagar, esteja devidamente registrado no log de commits do repositório, e que seja possível voltar pra qualquer momento no passado e ter tudo intacto, exatamente como era. Não pode ser parcial. Por outro lado, não pode ficar no caminho do desenvolvedor e adicionar obstáculos. Se o desenvolvedor achar que quer reescrever a história, precisa deixar.

A resiliência do Git aparece numa equipe, com mais de uma pessoa. Basta ter mais um desenvolvedor que tem como comparar os repositórios nas máquinas de cada um e ver que houve problemas. Basta checar os hashes dos commits. Se tiver 3 desenvolvedores já temos como fazer um tipo rudimentar de consenso: o que tiver o histórico mais diferente tá errado.

Eu só expliquei os conceitos bem básicos, tem bem mais detalhes por trás pra vocês pesquisarem depois. Árvores Merkle são úteis pra BitTorrent e pra Git, mas também são usados em outros lugares. O sistema de arquivos ZFS, que é usado no TrueNAS pra grandes servidores de armazenamento também usa árvores Merkle pra detectar corrupção de dados e ter a funcionalidade de snapshots com pouco overhead.

Outras redes ponto a ponto como o IPFS, que é o InterPlanetary File System, um sistema de arquivos distribuídos global, usa árvores Merkle, mais especificamente Merkle DAGs como Git. Não só sistemas de arquivos, mas bancos de dados distribuídos como Cassandra ou Riak usam árvores de Merkle pra minimizar a quantidade de dados que precisam ser transmitidos pra sincronização de dados.

No começo do video eu mostrei a cadeia de certificados e como o certificado do meu domínio é assinado pela Letsencrypt que, por sua vez é assinado pela ISRG. O protocolo TLS usa uma variante de árvore de Merkle chamada Merkle Hash Tree, no framework de Certificado de Transparência pra fornecer um log auditável de certificados gerados. E essa característica é importante: qualquer coisa que precise ser auditável pode usar árvores Merkle pra oferecer “prova de inclusão”, de forma que é possível provar que um pedaço de dados faz parte de um determinado conjunto, sem revelar o conjunto inteiro.

E se você já parou pra estudar o básico de Bitcoin e outras criptomoedas, já deve ter se deparado com Árvores Merkle e Merkle Root. É o que está na raíz do bloco de transações da tal de blockchain. Um blockchain e um repositório Git ou a árvore de merkle de Bit Torrent são muito parecidos: eles garantem que não dá pra adulterar um bloco sozinho, sem precisar re-gerar todos os blocos à frente dele. Com um ingrediente a mais: o tal processo de mineração. Em Git, um rebase é uma operação razoavelmente rápida.

Mas num blockchain de Bitcoin, o equivalente de rebase de Git custa absurdamente caro, astronomicamente caro na real, o que garante que é perto de impossível fazer um rebase. É isso que torna o blockchain interessante. Um blockchain onde é barato fazer rebase não é diferente de um Git e, como reserva de valor, não vale nada. Tudo que expliquei neste episódio são as tecnologias que estão na fundação do Bitcoin.

Se conseguiram chegar até aqui, nós vimos na prática como encriptação com chaves simétrica funciona. Aprendemos como funciona troca de chaves usando criptografia assimétrica. Vimos como quebrar arquivos e trafegar pedaços de uma forma que conseguimos checar se os pedaços vieram corretamente e vimos como BitTorrent e Git funcionam com árvores Merkle. Tudo em computação moderna usa esses conceitos, em particular certificados digitais TLS, bancos de dados NoSQL e até Bitcoin, por isso é importante estudarem tudo. Se ficaram com dúvida deixem nos comentários abaixo, se curitram o video mandem um joinha, assinem o canal e não deixem de compartilhar com seus amigos. A gente se vê, até mais!

Fazia tempo que queria fazer um último episódio à playlist de armazenamento trazendo um pouco mais de BTRFS. Aproveito pra adicionar mais sobre Git, Docker tudo voltado ao tema de como não perder dados nunca mais e até como recuperar dados numa emergência.

Tudo que você nem sabia que queria saber sobre armazenamento e gerenciamento de dados no seu HD.

Conteúdo

• 00:00:00 - Intro
• 00:00:51 - CAP 1 - Recapitulando Sistemas de Arquivos - Journaling
• 00:02:42 - CAP 2 - Caminho pro Desastre! Git e GitHub
• 00:07:21 - CAP 3 - Git SEM GitHub - Git Raíz
• 00:12:25 - CAP 4 - Partição Perdida - Sem Superbloco
• 00:16:09 - CAP 5 - Não Caia em Golpes - Aliexpress
• 00:19:46 - CAP 6 - Tentando Consertar - Backup do Superbloco
• 00:24:51 - CAP 7 - Tentando Consertar - Última Instância
• 00:29:36 - CAP 8 - Checksums - Sistemas de Arquivos Modernos
• 00:34:18 - CAP 9 - Deduplicação - Sistemas de Arquivos Modernos
• 00:36:28 - CAP 10 - Copy On Write - Sistemas de Arquivos Modernos
• 00:40:21 - CAP 11 - BTRFS no Ubuntu - Por que Manjaro?
• 00:45:51 - CAP 12 - Snapshots e Timeshift - BTRFS
• 00:53:56 - CAP 13 - Snapshots e Docker - Não Perca Espaço
• 01:02:59 - CAP 14 - Meu NAS Anti Ransomware - Synology
• 01:07:37 - CAP 15 - Pacotes, Docker, Flatpak, QEMU - Sistema Estável
• 01:10:03 - Bloopers

Links

• A Quick and Hacky Way to Serve a Git Repo over HTTP (https://theartofmachinery.com/2016/07/02/git_over_http.html)
• NGrok (https://ngrok.com/docs/getting-started/)
• TestDisk LiveCD (https://www.cgsecurity.org/wiki/TestDisk_Livecd)
• TestDisk Docs (https://www.cgsecurity.org/testdisk_doc/presentation.html#testdisk-partition-recovery)
• ArchWiki: BTRFS (https://wiki.archlinux.org/title/Btrfs)
• Timeshift and grub-btrfs in Ubuntu (https://www.lorenzobettini.it/2022/10/timeshift-and-grub-btrfs-in-ubuntu/)
• timeshift-autosnap-apt (https://github.com/wmutschl/timeshift-autosnap-apt)
• Scheduled snapshots not working (https://github.com/teejee2008/timeshift/issues/135)
• Why is Grub menu not shown when starting my computer? (https://askubuntu.com/a/1187104)
• Full-disk encryption with Btrfs on Ubuntu Xenial (https://albertodonato.net/blog/posts/full-disk-encryption-with-btrfs-on-ubuntu-xenial.html)
• How To Add Swap Space on Ubuntu 20.04 (https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-20-04)
• Swapfile Swapon invalid argument (https://unix.stackexchange.com/a/713929)
• Thoughts on swap partition vs swap file in subvolume with Btrfs? (https://www.reddit.com/r/archlinux/comments/ymq7ve/thoughts_on_swap_partition_vs_swap_file_in/?onetap_auto=true)
• How do I use Timeshift/btrfs to permanently restore to a previous snapshot? (https://forum.manjaro.org/t/how-do-i-use-timeshift-btrfs-to-permanently-restore-to-a-previous-snapshot/124683)

SCRIPT

Olá pessoal, Fabio Akita

Estou bem atrasado com a segunda parte do video da Rinha, e vai demorar mais um pouco. Honestamente, o tema me deu burn out, então resolvi fazer um video antes que não deixa de ser um pré-requisito porque até o final vou explicar um pouco mais sobre Docker e Docker Compose. Mas antes, quero falar de um problema que vira e mexe vejo desenvolvedores tendo: perder dados.

Sim, acidentes acontecem, e tanto o hardware quanto sistemas operacionais de hoje em dia, ajudam muito a não perder dados. Mas sério, a maioria de vocês não ia conseguir sobreviver com a tecnologia rudimentar que a gente tinha nos anos 80 e 90. Eu mesmo não lembro mais a última vez que perdi dados. Acho um absurdo que programadores ainda percam tempo com esse tipo de problema, então quero discutir diversas soluções pra isso. Vamos lá.

(…)

Um bom programador é mestre da sua máquina, nunca o contrário. Quando seu hardware perde seus dados e te força a passar perrengue, ele se tornou seu mestre, e você não é mais que um mero peão de um objeto inanimado. Vocês tem que mostrar quem manda. Vamos a alguns fatos. Em termos de sistema operacional, tanto faz se usa Mac, ou Windows ou Linux. Nenhum deles é muito melhor que o outro em termos de garantia de dados. Não é porque escolheu usar Mac que está magicamente mais protegido do que Windows. Isso não é verdade faz anos.

Vejam minha série sobre armazenamento. O NTFS do Windows tá longe de ser perfeito, cheio de problemas ainda, mas pro dia a dia, você não vai ter mais problemas do que teria com um ext4 no Linux ou APFS no Mac. Todos tem journaling, por exemplo. Significa que, mesmo que acabe a luz no meio de uma operação de disco, seu sistema de arquivos não vai ficar corrompido a toa. Vira e mexe alguns blocos podem se perder mesmo, mas as rotinas de manutenção padrão, são suficientes pra resolver a maioria dos problemas.

Quando alguém perde dados só existem duas razões: porque comprou um HD muito do porcaria ou porque cometeu erro humano mesmo. Aliás, vira e mexe alguém faz aquele meme de digitar “rm -rf /” e diz que iniciante não sabe o que isso faz. Mas parece que quem faz o meme também não sabe. Já faz algum tempo que o comando “rm” não apaga a raíz assim do nada. Precisa ou digitar “/*” com asterisco no final ou usar a opção “–no-preserve-root” pra realmente apagar a raíz. The more you know.

Enfim, nenhum sistema operacional vai resolver qualquer um desses problemas. Hardware porcaria só tem uma solução: jogar fora e comprar um de verdade. Toda vez que estiver tendo problemas frequentes, a probabilidade maior é hardware porcaria. Já a parte do erro humano, vamos tentar mitigar um pouco disso hoje.

Alguns meses atrás, um conhecido foi tentar instalar Linux como dual boot com Windows no notebook dele. Não sei qual era a marca, nem nada. Mas ele se ferrou: a partição Linux não bootava mais. Agora vem o problema: as últimas coisas que ele fez no projeto dele, não tinha dado push pro GitHub ainda. E, como praticamente todo mundo aqui assistindo, não tinha backup.

Tudo que vou narrar a partir daqui poderia ter sido evitado. Hoje em dia, todo programador usa Git. Isso é obrigatório. Mesmo se trabalha numa empresa, o mais porcaria possível, que por alguma razão do além, ainda não está usando Git, não existe desculpa: o projeto não precisa adotar Git pra você usar Git. GitHub é opcional, Git não. Marrete esse conceito na sua cabeça. Não importa se é um projetinho pessoal só na sua máquina. Faça “git init” e comece a fazer “git commit”.

Git não precisa de um servidor externo. Digamos que essa empresa hipotética super tosca pra onde está trabalhando não queira usar Git pra não ter que pagar GitHub ou alguma bobagem desse tipo. Ou usa alguma alternativa obsoleta de 20 anos atrás como a enorme porcaria de um SourceSafe da vida. Aí são dois grandes erros imperdoáveis. E digamos que você também não queira investir numa conta paga de GitHub, portanto não tem como fazer repositórios privados. E agora? Como faz?

Vou repetir: não precisa existir projeto no GitHub pra usar Git. Muitos iniciantes confundem isso. Git é uma ferramenta, GitHub é um serviço. GitHub precisa de Git, mas Git não precisa de GitHub. Qualquer diretório do seu computador pode virar um repositório Git, basta digitar “git init” dentro e pronto, ele cria o subdiretório “.git” que é o repositório propriamente dito. Agora basta fazer “git add .” pra adicionar tudo nesse diretório e “git commit -m” com uma mensagem pra criar um commit e já era. Só isso.

Eu fiz dois videos onde conto tudo que você deveria saber sobre Git e recomendo que assistam. Inclusive eu conto como lá nos primórdios de Git, quando realmente ninguém nem sabia que existia, eu trabalhei em projetos de clientes que usavam coisas como Subversion, mas só eu trabalhava com Git e usava um plugin chamado git-svn pra integrar os dois. Se lá em 2007 eu conseguia usar, sem nenhum suporte, em 2023, não existe desculpa aceitável pra não usar.

Isso resolve o problema de acidentalmente apagar um arquivo que não deveria, ou mudar de ideia num código que acabou de fazer, e conseguir voltar pra como estava no último commit. Digamos que você apagou um arquivo. Puts, apagou o arquivo errado? E agora? Se você fez a coisa certa, que é ficar fazendo pequenos commits, o tempo todo, ainda deve ter a versão anterior no último commit. Faça “git status”, olha ele marcado pra deleção. Basta fazer “git checkout” e o nome do arquivo, e pronto, listamos e olha só o arquivo de volta aqui.

Qualquer programador que use de desculpa “puts, apaguei o arquivo sem querer e perdi tudo”, ainda é um iniciante que precisa aprender a usar git. Ah, mas eu gosto de primeiro terminar tudo, tudo e depois fazer commit. E eu digo que você é um idiota. Vou dar um exemplo. Digamos que fiz um código aqui num arquivo, mas não terminei. E acabou o dia. Como sou disciplinado, já vou fazer um “git commit -m ‘codigo no meio’”. Puts, mas que commit feio. Melhor um commit feio agora do que ter um acidente e perder o arquivo. Agora posso desligar o computador e ir dormir.

Acordo no dia seguinte, vou continuar editando esse arquivo e aí sim, finalmente termino. Agora posso fazer um “git commit -m ‘codigo final’ –amend”. Essa opção amend, vai desfazer o commit anterior e trocar por esse novo commit, com a nova mensagem mais bonita e descritiva. Rode “git log” olha só, aquela mensagem feia com código parcial sumiu e estou com o commit bonito. Agora posso fazer push pro servidor se quiser.

Dentro de um branch, faça quanto commits quiser, dê push de commits feios, e no final, faça um squash do branch antes de criar um pull request, se fizer muita questão. É uma das formas de lidar com isso. O histórico de commits nunca deve ser reescrito no branch master ou main, mas no seu branch, onde só você está trabalhando, foda-se, faça cinquenta commits. Daqui uma semana quando terminar, faça squash, se a quantidade de commits incomodar. Daí manda merge pra master.

Existem várias nuances no que falei, não é uma regra escrita em pedra, essas convenções vão variar de equipe pra equipe. Mas voltando ao meu ponto inicial: digamos que você não tenha um repositório remoto no GitHub. Estou trabalhando sozinho na minha máquina local. E não tenho pra onde dar push. Se der alguma pane catastrófica na minha máquina, eu perco tudo. Como evitar isso?

Se o projeto que estiver trabalhando for de cliente, e você for freelancer, por favor, pague uma conta no GitHub ou GitLab e faça push pra lá. Não desperdice o tempo de todo mundo. Isso tem nome: se chama economia porca. Porque na hora que alguma coisa der pane, não tem mais como recuperar. Isso dito, você é mão de vaca bagarai. Ok. Vou te dar a solução mais barata de todos os tempos. Espete um pendrive ou HD externo no seu PC.

Do diretório do seu projetinho faça “git clone –bare . /media/pendrive/projeto.git”. Isso vai criar um clone do seu projeto nesse pendrive. Lógico o caminho de onde o pendrive montou vai variar de distro pra distro. Adicione o pendrive como origin com “git remote add origin /media/pendrive/projeto.git”. Pronto. Vamos continuar trabalhando, criando um novo arquivo, adicionando, fazendo commit. Mas agora posso fazer o bom e velho “git push origin master” e ele vai mandar praquele clone no pendrive. O pendrive está fazendo o papel de GitHub pra você, sacou?

E podemos ir mais longe. Digamos que é aquela sexta feira no escritório, você está finalizando uma nova funcionalidade que precisa entregar hoje. O Tech lead tá lá esperando pra finalizar a parte dele. Mas aí dá uma daquelas panes no GitHub e ele fica fora do ar algumas horas. Bem no fim da sexta feira. Fodeu né? Fica pra segunda então? Não. Faça git push no pendrive, passa o pendrive pro tech lead, ele consegue adicionar como remote e dar pull no repo dele. E vai conseguir continuar o trabalho na máquina dele, mesmo sem ter GitHub.

GitHub é uma conveniência, mas não é mandatório. Qualquer coisa pode substituir. O que você perde enquanto ele tá fora do ar são as conveniências, a integração com o continuous integration, os pull requests que tavam em aberto e você não puxou, lista de issues e coisas assim, mas o código em si, dá pra manipular de vários jeitos diferentes.

Só pra concluir essa parte de Git, vou mais longe no exemplo do GitHub saindo fora do ar. Meu exemplo com pendrive assume todo mundo trabalhando presencialmente no mesmo escritório. Mas que cabeça a minha, todo mundo tá home office hoje né? Então fodeu mesmo, sem GitHub pra centralizar, se cair, todo mundo fica sem conseguir colaborar né? Só que não.

Eu terminei a minha parte na minha máquina, o tech lead tá lá na casa dele, precisando puxar o que acabei de fazer pra continuar. Não temos GitHub. Como faz? Simples. Sabe o clone “bare” que eu fiz no tal pendrive? Vamos modificar ele. Basta entrar no diretório “.git” e começar fazendo “git –bare update-server-info” e depois “mv hooks/post-update.sample hooks/post-update” e pronto, nosso repositório está pronto pra ser integrado a um servidor web qualquer. O mais simples que consigo imaginar é o http server que vem no Python. Com uma única linha de comando “python -m http.server 8000” e já era, temos um servidor web git.

Pra testar, basta ir no “/tmp” ou qualquer lugar e fazer “git clone http://localhost:8000 teste” e voilá, consigo fazer clone do meu repositório local. Quem trabalha com VPNs como TailScale ou ZeroTier já sabe o que fazer: só trocar localhost pelo IP da VPN que todo mundo da equipe enxerga e fazer o mesmo que descrevi antes: o tech lead adiciona um remote apontando pra esse servidor, consegue dar “git fetch” do seu branch e pode continuar a trabalhar tranquilamente enquanto povo do GitHub fica lá brincando de restartar servidor até voltar.

Outra solução rápida é instalar ngrok na sua máquina. Ngrok é o jeito mais simples de criar um túnel de fora pra dentro da sua máquina. Muita gente usa pra mostrar uma aplicação web rodando na sua máquina local que ainda não tem servidor de testes ou staging. Assim um cliente que não está presente consegue visualizar o andamento do trabalho olhando o que tá rodando no localhost da sua máquina. Entenderam?

Olha só, posso rodar “ngrok http 8000”. Isso vai abrir um tunel no serviço ngrok apontando pro nosso servidorzinho python local. Ele nos dá essa URL gigante de “Forwarding”. Podemos passar ela pro nosso querido tech lead. Na máquina dele, ele pode fazer “git clone " e essa URL-zona e … voilá, olha só. Da casa dele, tá conseguindo puxar os commits da minha máquina. Entenderam o que aconteceu aqui?

Num dia normal, o trabalho iria parar por horas até o GitHub voltar. Mas sabendo dessas coisas simples e triviais, conseguimos continuar trabalhando como se nada tivesse acontecido. Esse é o poder do Git e de saber como juntar componentes simples. Criar um clone “bare”, habilitar pra ser servido via http, subir um servidor http simples com python e abrir um túnel seguro usando ngrok.

Mas claro, tudo isso assume que você, no mínimo, usa Git minimamente direito. Fazendo commits frequentes. Fazendo backups frequentes. Só quem já perdeu dados sabe da importância disso. Todos que dizem que é desnecessário só provam que são virgens e ainda precisam perder alguma coisa importante pra aprender. Vocês assistindo podem aproveitar o que falei e evitar ter que passar por esse estresse.

Digamos que não fez nada disso. Deu na telha que quer experimentar montar um dual boot na sua máquina pela primeira vez, e gosta de viver perigosamente, nem deu push dos projetos pro GitHub, nem copiou num pendrive, nem sequer fez commits, tá tudo parcial na sua máquina. Mas tá seguro, você assistiu um tutorial no YouTube, seus parças tão te chamando pra jogar Genshin a noite. Não tem tempo a perder, bora redimensionar o disco, criar uma segunda partição de Windows e passar a noite jogando.

Só que aí dá tudo errado. Tudo na primeira vez, sempre vai dar errado. Aceitem essa máxima. Se for a primeira vez de qualquer coisa, já comecem sabendo que não vai funcionar de primeira. Não custa nada espetar um HD externo e copiar as coisas mais importantes lá. Mas alas, a pressa é inimiga da perfeição mesmo. Não lembro onde guardei o HD externo, não quero perder tempo procurando. Foda-se, vai dar certo, confia, cola no pai.

É muito difícil saber exatamente o que acontece em panes. Se foi algum procedimento errado ou se foi mesmo algum defeito de hardware. Pra tentar demonstrar algo parecido, fiz uma máquina virtual com um Ubuntu e um disco virtual. Esse disco aparece como dispositivo “/dev/vdb” de virtual device B, já que o virtual device A é disco primário. Está formatado como ext4, dentro coloquei meu projeto da rinha em rails, um ISO de Ubuntu. Faça de conta que é um HD normal do seu notebook.

Agora vou desmontar com “umount”. Um dos jeito de simular um erro de hardware é escrever por cima dos primeiros bytes no começo do dispositivo. Lembram dos meus videos sobre sistemas de arquivo? O que é uma partição? É uma estrutura de dados que guarda coisas como em qual endereço começa e onde termina uma partição, o tipo de sistema de arquivo, localização dos blocos. Esses primeiros bytes formam o que chamamos de Super Bloco.

Olha só, se eu tentar montar esse dispositivo de novo, vai dar erro. O Linux não sabe o que fazer, porque não tem mais o superbloco. Os dados em si ainda estão na partição, no linguição de bytes, mas sem o superbloco não dá pra saber onde começa e onde termina o que. Pense assim, seus arquivos são como casas montados com lego. Cada lego está enterrado num campo de futebol, o seu HD. Mas o superbloco tem a localização de cada bloco, e as instruções de como remontar sua casa de lego. Sem esse superbloco, mesmo achando as peças, não sabemos se ainda falta mais blocos ou como encaixar esses blocos.

Se acontecer um erro como esse, onde a partição se recusa a bootar ou montar e aparecem erros como esse, filesystem errado, ou opção errada, ou superbloco errado, é um péssimo sinal. A primeira coisa que recomendo fazer é evitar insistir. Se usar comandos errados que sobrescrevem em cima do disco, se fodeu, vai perder dados. Muito cuidado com comandos como fdisk ou mkfs, que é o equivalente de format de Linux.

A forma de diagnosticar algo assim é achar outro computador, outro notebook, baixar a ISO de algum Linux como o próprio Ubuntu, gravar num pendrive, daí passar a fazer boot pelo pendrive. A maioria das distros Linux tem um ambiente de Live CD que boota um ambiente operacional inteiro, que inclusive se conecta no seu Wifi e permite instalar qualquer pacote. Isso permite baixar quaisquer ferramentas de diagnóstico e recuperação.

A partir desse ambiente, ele vai achar seu dispositivo como um “/dev/sdb” ou “/dev/nvme2” ou qualquer coisa assim. Assistam meus videos sobre Linux, o de Gentoo principalmente, porque a instalação dele exige manualmente fazer exatamente esse tipo de operação. Por isso fiz aquele video: qualquer um que já instalou um Gentoo ou Arch do zero, já sabe como fazer isso.

Antes de continuar deixa eu comentar uma coisa: porque esse tipo de problema acontece? Digamos que não foi erro humano. SSDs quebram assim do nada mesmo? E sim, quebram. Se for no Aliexpress e pesquisar por SSDs e ordenar a partir do menor preço, sim, as primeiras dez páginas, no mínimo, é quase 100% de chance de vir um tijolo. Aliás, se vier um tijolo pelo menos vai ser mais seguro. Problema é quando vem um drive mesmo e você confia com seus dados.

Primeiro, tem os golpes mais óbvios. Quando desparafusa e abre, dentro não tem uma placa controladora e chips de memória Flash. Não, tem um adaptador USB barato pra micro SD Card. Chips de SD Card sempre usam componentes mais baratos que SSD. Eles foram feitos pra serem quase descartáveis, justamente pra uso em câmeras fotográficas ou celulares. Não foram pensados pra uso como um HD de notebook. Não tem banda pra isso, não tem controlador pra isso, não tem memória RAM de cache, a qualidade da memória NAND flash é muito inferior. Por isso são muito mais baratos.

Já disse isso antes e vou repetir: nunca deixe nada importante num SD Card. É comum eles corromperem. SD Card deve ser usado única e exclusivamente como armazenamento temporário, tempo suficiente pra chegar em casa da sua viagem, e descarregar os cartões no seu notebook. Mas os tais SSDs baratos de marcas chinesas genéricas contam com sua burrice. Ninguém nunca abre a carcaça de um SSD pra ver o que tem dentro, e eles contam com isso.

Mesmo quando vem com componentes de SSD de verdade, eles vendem chips de 500MB como se fosse 1TB. Por isso sai pela metade do preço, mas o controlador tá gambiarrado e mente pro seu computador dizendo que tem 1TB. Se você tentar mesmo gravar mais que 500MB, ele vai começar a sobrescrever os dados do começo. Como a maioria das pessoas vai só gravando mas não checa na hora se tudo gravou mesmo, só vai descobrir da pior maneira: quando precisar do arquivo, tentar acessar, e descobrir que os arquivos não estão mais lá ou estão incompletos e corrompidos.

Como evitar isso? Nunca, jamais compre marcas chinesas genéricas desconhecidas. Compre Samsung, Crucial, Sandisk, Western Digital, só marcas reconhecidas de longa data. E de lojas com alguma reputação e não um revendedor aleatório desconhecido. Muitos vão pegar a carcaça de um Samsung quebrado, colocar o tal adaptador USB com SD card e te revender como se fosse original Samsung. Só compre em loja de verdade e só compre item novo e lacrado. Pense em SSD como escova de dente: você não quer um usado.

Em quais situações você pode arriscar um SSD mais barato genérico? Se for pra ser sua biblioteca de Steam, por exemplo. HD pra games. Aí foda-se se perder dados. Se o HD for mesmo um golpe, pega outro HD barato, e baixa tudo da Steam de novo. Mas nunca, jamais, sob nenhuma circunstância use um HD desses pra trabalho, ou mesmo pra guardar coisas importantes pra você, como as fotos da sua família, dos seus filhos, das suas viagens. Você vai perder esses dados pra sempre.

Obviamente, todo mundo concordou com o que falei, mas tá fazendo exatamente o que eu disse pra não fazer. Não usou Git. Não fez uma cópia dos seus projetos num pendrive ou hd externo. Foi querer usar o mesmo HD de trabalho pra games com dual boot. E chegamos na situação que ele não boota mais e nem conseguimos mais montar a partição. O próximo passo é arranjar um outro HD, seja interno, seja externo, que tenha mais espaço livre do que o total do HD quebrado. Vamos fazer uma cópia bit a bit, pra garantir que não vamos perder mais nada.

Usando o comando “lsblk” podemos ver os dispositivos de armazenamento conectados. Aqui neste exemplo, tenho o “/dev/vba” que é a partição funcionando do meu Ubuntu, e o “/dev/vdb” que é a partição corrompida. Antes de tentar fazer qualquer coisa, o certo é usar o comando “dd” e fazer uma cópia, assim “sudo dd if=/dev/vdb of=~/Downloads/backup.hd bs=4M”. O nome de arquivo e extensão não importam, qualquer coisa serve. Dependendo do tamanho do seu HD quebrado e velocidade do seu PC, isso pode levar horas. Vai parecer que está travado. Deixa quieto lá, vai jantar e volta amanhã. O LOLzinho com os parça essa noite já miou, nem insiste.

Pronto, agora temos uma cópia bit a bit do HD nesse arquivo. Garanta que não vai perder ele, porque se fizer mais alguma coisa errada na tentativa de consertar, temos uma segunda chance com esse backup. Coloque num outro HD externo se quiser garantir. Mantenha longe de você por enquanto, você já causou problemas demais. Um profissional de recuperação de dados tem muito mais opções do que vou mostrar agora. Só vou falar o mais óbvio, porque eu também não sei tudo.

Felizmente muita gente já passou por situação similar, e a partição costuma ter backups desse superbloco. Mais de um na real. Faça o teste no seu próprio sistema. Num Arch linux, primeiro precisamos instalar o pacote “e2fsprogs”, que contém programas pra lidar com sistema de arquivos como ext2 ou ext4. Usando o comando “lsblk” podemos listar os dispositivos e com o comando “dumpe2fs /dev/vdb | grep -i superblock” podemos listar os tais superblocos e backups.

Como esperado, o superbloco primário está no endereço zero, mas veja quantos backups temos. Um no endereço 32 mil e tantos, outro no endereço 98 mil e tantos, oito backups. Um erro catastrófico é quando alguma coisa acontece que corrompe não só os primeiros bytes, mas todos os bytes até o último backup. É raro, mas pode acontecer, especialmente se você usar errado uma ferramenta como fdisk e sobrescrever uma nova partição em cima da antiga.

O comando “dumpe2fs” talvez não consiga listar esses superblocos caso a partição esteja corrompida. Tentando no dispositivo “/dev/vdb” olha só, ele dá erro e não lista nada. Podemos usar o comando “mke2fs” que normalmente serve pra formatar uma partição, mas passando a opção “-n” de “dry-run” vai só simular a execução do comando sem de fato executar nada. Lembra o que falei antes: não queremos que nada escreva nesse disco quebrado. O programa não está consultando a partição com problema, só dizendo que, se não fosse um dry-run, escreveria os superblocos nesses endereços que listou.

Pra facilitar recuperação é importante saber qual é o tipo de sistema de arquivos que escolhemos na instalação. No caso de Windows é fácil, acho que ninguém escolhe nada diferente de NTFS. Mac já complica porque antigamente tinha o HPFS+ que mudou pra APFS a partir do final de 2017 com o macOS 10.13, mas muita gente continuou usando o antigo até depois de 2018. Já Linux, maioria costuma escolher ext4. Tem gente que escolhe ReiserFS ou os novos ZFS ou BTRFS. Cada um deles tem ferramental diferente. O que estou mostrando até agora é assumindo que é ext4.

Agora podemos tentar recuperar o superbloco a partir dos backups. Temos que tentar um a um até conseguir. Talvez nenhum dos backups estejam bons, talvez já no primeiro resolva. Pra fazer essa recuperação usamos o comando “fsck” com opção “-b” e o número do backup. Agora é ir confirmando “yes” até o fim. E se continuar assim, yes, yes, olha só, terminou. Será que funcionou?

Pra saber, podemos tentar montar de novo. E sucesso, montou de primeira, sem nenhum erro. Se listarmos dentro, sim, aqui estão nossos arquivos. À primeira vista tudo intacto. Nem sempre as coisas acontecem assim bonitinho, lembrem-se que eu só simulei um problema num ambiente controlado. Sob condições ideais de temperatura e pressão, é assim que conseguimos recuperar.

O certo agora é não confiar que só porque parece tudo ok, parar aqui. O certo é plugar outro HD externo, e usar um programa como rsync pra fazer uma cópia dos arquivos pra outro lugar. Você quis economizar com HD barato, mas tá percebendo que pra recuperar agora vai precisar de vários outros HDs pra fazer o backup que não quis fazer antes? Depois de tudo copiado, o certo é formatar essa partição do zero e copiar os arquivos de volta. Mas o mais certo mesmo é, depois de copiar os arquivos pra um lugar seguro, se livrar desse HD.

Se foi problema de hardware e não erro humano, é provável que vai voltar a dar pau de novo. Nunca confie num hardware que já te deixou na mão uma vez. É lixo, joga fora. Se o cavalo te derruba, você sacrifica, é o que eu sempre digo. No mínimo troca por um SSD novo, de verdade, de uma Crucial ou Samsung da vida, e usa esse HD que deu pau num estojo externo pra ser HD USB só pra coisas não importantes como games da Steam.

Mas, digamos que o comando “fsck” não funcionou, nenhum dos backups estava bom e não deu pra recuperar o superbloco. A partir daqui depende da importância dos dados no seu HD. Faz de conta que é daqueles casos excepcionais onde sua carteira de Bitcoin com milhões de dólares está só nesse HD. Um puta erro de amador, mas já vimos isso acontecer antes. Nesse caso o melhor é procurar um profissional de recuperação de dados. Pra recuperações mais hardcore, ele vai desmontar o SSD, colocar num hardware especializado pra esse tipo de coisa e vai fazer magia negra. Dependendo da pane, talvez consiga recuperar.

Se não for esse caso, aí recomendo que instale a ferramenta TestDisk. Eu não tenho tanta experiência nisso, então recomendo que procure outros videos como este daqui. Vou deixar o link abaixo. O TestDisk propriamente dito tem algumas ferramentas de análise pra tentar recuperar as informações da partição, reconstruir o que conseguir, mas não tem nenhuma garantia que vai funcionar. Ele não é muito intuitivo de usar, por isso recomendo ler bem a documentação e assistir alguns videos de exemplo.

Seja por ter corrompido a partição ou seja porque você deletou arquivos acidentalmente, o caso é o mesmo: os bytes que compõe seu arquivo nunca são deletados de verdade. Eles ainda estão fisicamente no HD. Acontece o seguinte: o tal sistema de arquivos, como ext4, mantém um índice dizendo: arquivo chamado “hello.txt” tem 20 blocos, e os endereços desses blocos são X e Y. Quando pedimos esse arquivo, ele vai buscar esses blocos e nos devolve na ordem certa. Blocos são conjuntos de bytes, depende do sistema de arquivos dizer quantos bytes tem num bloco. Por isso falo que é tudo um linguição de bytes.

Quando mandamos apagar um arquivo, não vai bloco a bloco e escreve zeros em cima. Isso até existe, alguns sistemas chamam de “Deleção segura”. Só apaga o registro do arquivo “hello.txt” desse índice, daí perdemos a localização dos blocos. Mas os blocos em si continuam no HD. Lembram a metáfora dos legos enterrados no campo de futebol. Eles continuam lá enterrados, só jogamos fora o mapa da localização de cada peça.

Os blocos só vão se perder se algum novo arquivo escrever por cima deles. Por isso falamos que, se apagou algo por engano, a primeiríssima coisa a se fazer é desmontar esse HD e tirar da máquina, pra nenhum processo acabar gravando nada em cima por acidente. E por isso a segunda coisa é fazer um backup bit a bit com a ferramenta DD, porque isso vai preservar todos os blocos, exatamente como eles estavam até aquele momento. Daí podemos fuçar sem perigo de perder alguma coisa, porque tem o backup, a imagem exata.

No pacote do TestDisk existe a ferramenta Photorec. Também já expliquei em outro video a diferença de arquivos texto e arquivos binários, e expliquei como o sistema operacional sabe que um determinado binário é um executável. Todo arquivo binário, tem nos primeiros bytes, um cabeçalho que indica que tipo de arquivo é. Um JPEG, um PNG, um video MP4, um executável ELF de Linux, um documento de Word, todos tem cabeçalhos padrão.

Na metáfora dos Legos, é como ir desenterrando peça a peça, sabendo que um JPEG começa com um bloco vermelho, um Word começa com bloco azul, e aí tentar montar na tentativa e erro. Uma ferramenta como Photorec vai tentar, por tentativa e erro, localizar o começo dos arquivos e os blocos que fazem sentido vir depois.

Eu simulei isso nesse dispositivo “/dev/vdb”, fazendo de conta que o fsck não conseguiu recuperar. Rodando o photorec, ele vai pedir pra apontar um diretório em outra partição boa, pra onde queremos que vá gravando os arquivos que conseguir encontrar. Dependendo da quantidade de arquivos que tinha, vai demorar um bocado. No final vai surgir um diretório com um monte de arquivos com nomes esquisitos. É o máximo que podemos fazer se não tiver como recuperar o superbloco.

Olha só, tentando abrir alguns desses arquivos, de fato o conteúdo faz algum sentido. Mas claramente alguns estão incompletos. E vai vir muito lixo junto. Nesse ponto assuma que você se fodeu, perdeu a maior parte, e qualquer resquício que conseguir recuperar já é lucro. Entendeu? Se você perder o superbloco, perdeu os metadados, diretórios, nomes de arquivos, tudo. Nesse estágio estamos escovando bit mesmo.

Como não chegar nesse ponto? Só existe uma maneira: faça backup. É a recomendação mais velha da computação que ninguém segue, e eu nem tenho esperanças que vocês assistindo vão seguir, mas a gente tenta. E é a economia mais porca de todas não fazer backup. Um SSD Sandisk de 1TB, no MercadoLivre, custa uns 300 reais. Sandisk não é e melhor marca, mas é mil vezes melhor que um chinês genérico no fim do Aliexpress. Um case USB que transforma esse SSD num drive externo, não custa 30 reais. Uma balada paga isso.

Todo sistema operacional já vem com software de backup. Nem precisa instalar nada. Use o Time Machine do MacOS, use o app de Backup que já vem no Windows, use um app como Deja Vu que já vem nos Ubuntu. Não seja preguiçoso. E backup não é só pro caso de dar pane de hardware no seu SSD barato, tem caso pior. Já ouviu falar de ransomware? Vou contar como eu sou imune a isso.

Se num extremo está a pessoa que confia todos os seus dados importantes num SSD genérico chinês do fundo do Aliexpress, sem nenhum backup, do outro lado estou eu. Já mostrei minha solução em outros videos e no Insta, mas eu tenho um NAS de 60 terabytes. São 6 HDs IronWolf de nível industrial de 12 terabytes cada, em sistema de redundância, onde não perco nada mesmo se um HD morrer agora. Eu uso não só pra backup, mas faço coisas como edição dos meus videos direto dele.

Claro que não dá pra recomendar isso, é uma solução de mais de 30 mil reais de investimento, na época. Como preços pioraram, agora, é inviável. Minha recomendação é um HD externo USB, coisa de menos de 400 reais, e que vai evitar muita dor de cabeça. Qualquer coisa acima é luxo. O mínimo é suficiente, faça o que puder, só não faça nada.

Quero aproveitar pra falar de outra coisa que não falei na série de armazenamento: sistemas de arquivos modernos. Lembrando, sistemas de arquivos como os antigos FAT16 e seus derivados como FAT32, ou mesmo ext2 nos primeiros Linux, foram pensados numa época onde espaço em disco era caro. RAM era caro. CPU era caro. Não havia recursos pra desperdiçar. Era a época onde falo que a gente escovava bit, no sentido que cada bit extra fazia diferença.

Segurança e performance são trade offs. Quanto mais segurança quiser, menos conveniente as coisas vão ser e mais recursos vamos precisar. Quando gravamos um arquivo num HD, o sistema de arquivos divide os bytes em blocos e grava nos setores do disco. Esse arquivo fica lá, semanas, meses, às vezes anos, sem ser acessado. Um belo dia você resolve abrir esse arquivo. Digamos que é uma planilha. Como eu sei que um dos setores físicos do disco magnético não falhou, flipou um bit, e algum dos valores na planilha não estão errados?

Num sistema antigo como FAT16, não tem como saber. Se corromper, corrompeu e não vamos saber. Num sistema moderno existe checksums. Num APFS de Mac ou NTFS de Windows, existe checksum no nível do arquivo. Quando o arquivo é gravado, o sistema gera um checksum e grava junto. Quando pedimos pra ler, ele pega os blocos e recalcula o checksum pra comparar com o que estava guardado. Se os checksums forem diferentes, significa que o arquivo está corrompido. Não é isso, mas se não sabe o que é um checksum, pense num dígito verificador.

Essa informação é super importante, porque numa planilha com milhares de valores, podemos estar tomando decisões importantes de forma errada por causa de um único bit errado. Um único bit pode mudar um valor de 100 reais pra milhões, por exemplo. Mas se o sistema avisar que o checksum está errado, sabemos que não podemos confiar nesse arquivo. O que fazer? Se você seguiu a recomendação e fez a porcaria de um backup, podemos ir nesse backup recuperar esse arquivo.

Em sistemas de arquivos mais modernos, pensados pra situações mais parrudas como servidores de arquivos, pense um Dropbox ou Google Drive da vida, com dados de milhões de pessoas, existem opções como o lendário ZFS da antiga Sun e o novo BTRFS do Linux. Eles tem checksum por blocos. Então conseguimos saber qual bloco dentro do arquivo está corrompido. Mas eles vão mais longe.

Meu NAS Synology está em configuração de RAID, com múltiplos HDs. Significa que o mesmo bloco tem cópias redundantes em mais de um HD. E BTRFS tem uma rotina que recomenda rodar periodicamente, digamos de 3 em 3 meses ou de 6 em 6 meses, chamado “scrubbing”. É um processo pesado que vai rodar em background, sem interromper seu dia a dia, e rechecar checksum a checksum de todos os blocos. Se notar que uma falhou, e estivermos em RAID, ele vai procurar uma cópia redundante desse bloco. A chance dos dois estarem corrompidos ao mesmo tempo é baixa, então podemos usar o bloco intacto pra consertar o que corrompeu.

Todo HD falha. Não importa se é HD mecânico com discos ou chips de Flash NAND de SSDs ou NVMEs. Todo chip Flash tem uma vida útil de quantidade de operações de escrita. Depois que passar desse limite, estraga e é isso. As checagens que falei, em muitos casos, só vão indicar mais cedo que algo falhou, mas sem redundância, sem uma segunda cópia intacta, não tem como adivinhar o que era o dado original que corrompeu, só dá pra saber que corrompeu.

Checagens de checksum, recuperação de blocos corrompidos, gastam RAM, gastam CPU. Não sai de graça. Servidores de arquivo parrudos como ZFS precisam de gigabytes de RAM pra serem eficientes, e vão usar toda RAM possível. Claro que tem mais vantagens que só isso. NTFS acho que não tem, mas APFS de Mac, assim como ZFS e BTRFS de Linux tem deduplication.

Faz de conta que você é desenvolvedor web e tem diversos projetos de Node.js na sua máquina. Sabe o maldito “npm install” que gera aqueles diretórios node_modules em todo projeto? Concorda que na maioria dos projetos vai ter as mesmas bibliotecas e os mesmos arquivos? Então estamos desperdiçando espaço com tanta duplicata? A resposta é sim, está desperdiçando.

Pra combater isso existem processos de deduplicação. Num NTFS de Windows, se estiver em Windows Server, ele oferece ferramenta pra que, caso dois arquivos tenham exatamente o mesmo conteúdo binário, ele consiga fazer o metadado dos dois apontarem pros mesmos conjuntos de blocos. Se forem dois arquivos de 200MB, originalmente iriam ocupar 400MB, mas com deduplicação, vai ocupar só 200MB. Só volta a ocupar mais espaço se decidirmos modificar o segundo arquivo, por exemplo.

Isso é muito útil no cenário de servidor de arquivos da empresa. O chefe manda um email com um PDF de 100MB pra 10 pessoas. Cada uma grava no seu diretório pessoal no servidor. Iria ocupar 1 giga. Mas se rodar a ferramenta de deduplicação, ele faz as 10 cópias apontarem pros mesmos blocos de um arquivo só, economizando 10 vezes o espaço. É o mesmo caso de termos 10 projetos de Node, cada um com node_modules repetidos. Rodando algum processo de deduplicação, no caso uma ferramenta como Opendedup no Linux, dá pra fazer algo semelhante no ext4.

Mas nenhuma dessas soluções é ideal. Os sistemas de arquivos NTFS e ext4 não foram feitos pra suportar esse tipo de coisa. O sistema de arquivos em si não suporta nada disso, daí dependemos de uma ferramenta externa pra tentar adicionar essas funcionalidades. O ideal é que o próprio sistema de arquivos implemente Copy on Write, independente de uma ferramenta externa.

Copy on Write ou CoW é super importante. É literalmente os conceitos de um Git só que em nível do sistema de arquivos inteiro, funcionando de forma transparente pro usuário. Num sistema copy on write, quando editamos um arquivo que já existe, os novos blocos não são gravados por cima dos antigos, ele faz o equivalente a um branch de Git e os novos blocos são gravados nesse branch, parecido com commits. Isso mantém o arquivo original intacto.

De cara, isso também evita mais corrupção de dados. Antigamente, num FAT16 da vida, onde estávamos na situação onde não tínhamos espaço sobrando, não tinha outra opção: toda modificação de arquivos precisava gravar os blocos novos em cima dos velhos. Mas e se acabasse a luz no meio? Ia ficar um arquivo corrompido. E isso era comum. Pra mitigar esse problema criou-se o conceito de journaling, que NTFS no WIndows, ext4 no Linux. HPFS+ no Mac passaram a suportar no fim dos anos 90.

Super resumido é assim. Digamos que eu tenha um arquivo, aquele Powerpoint, e ele ocupa 10 blocos no disco. No sistema de arquivos temos o nome do arquivo e um mapa apontando pra esses 10 blocos. Isso faz parte dos tais metadados de um arquivo. Agora editamos por cima e essa mudança afetaria os dois últimos blocos. Esses dois blocos serão gravados no disco e a localização será gravada no journal. O arquivo original ainda tem os 10 blocos originais até este ponto.

Ao terminar de gravar os dois novos blocos, só aí o NTFS vai atualizar o mapa do arquivo e mudar a referência dos dois últimos blocos pra apontar pra localização dos dois novos. Mas digamos que ele começou a mudar a referência do penúltimo bloco e antes de mudar a referência do último, acaba a luz e o sistema reboota. Quando reiniciar, o NTFS checa o journal e vê que faltou mudar a localização do último bloco.

Como ele tem essa informação no journal, vai conseguir terminar a operação e o Powerpoint não fica corrompido, como ficaria antes. Se ele ficasse em dúvida, faria rollback, e manteria o arquivo intacto. Os novos blocos não sobrescreveram os antigos ainda. Esse processo gasta um pouco mais de espaço, mas evita que arquivos fiquem corrompidos. Espaço hoje é mais barato, então podemos fazer isso.

Copy on Write vai um passo além. Depois que os novos blocos são gravados e registrados no journal, é feito tipo um fork no nível dos metadados. Imagine o mundo antes de Git. Se você copiasse um arquivo em cima do outro, o que acontece com o original? Ele se perderia pra sempre, certo? É assim que todo sistema de arquivos funciona. Mas o que acontece quando habilita Git num diretório e copia um arquivo em cima do outro? Vamos testar.

Aqui temos um diretório com Git habilitado e os arquivos já comitados. Se listar o que tem neste hello.txt, veja, “hello world”. Vou criar um novo arquivo fora, lá no /tmp com conteúdo de “bla bla bla”. Copio o arquivo por cima do meu original. Normal, meu arquivo original com “hello world” foi pro saco como podem ver. E se eu mudar de idéia?

Agora entra o Git pra te salvar. Fazendo “git status” podemos ver que ele sabe que esse arquivo foi modificado mas ainda não comitamos, não nos comprometemos com ele. Então podemos fazer “git checkout” desse arquivo, olha o conteúdo, “hello world” de volta. Git nos permite mudar de idéia e não perder dados ao custo de manter uma cópia do original em algum lugar ocupando espaço extra.

É por isso que todo projeto deve usar Git. Podemos mudar de idéia sem preocupação. Quando estivermos satisfeitos fazemos commits, e mesmo assim podemos reverter e até recuperar commits apagados. Copy on Write em sistema de arquivos é a mesma coisa. E em Linux, que eu saiba, só existem dois sistemas de arquivos modernos que suportam isso: o ZFS e o BTRFS.

Quem usa Ubuntu tem na instalação a opção de usar ZFS. E aqui já aviso: evite. É muito fácil fazer besteira em ZFS e perder tudo sem querer. ZFS é excelente pra quem está montando um servidor de arquivos, usando distros com o TrueNAS, que é o melhor. Só quem estudou bastante a documentação de ZFS deve tentar usar. Não basta só instalar e acabou, precisa de constante manutenção e monitoramento pra saber se está realmente tudo funcionando como deveria. Pra usar no dia a dia, no seu notebook, acho que vai mais atrapalhar do que ajudar.

Isso não quer dizer que ZFS é ruim, pelo contrário, é provavelmente o sistema de arquivos mais avançado que existe. Porém, pros propósitos de máquina do dia a dia de programador é como matar uma mosca com uma bazuca e arriscar atirar a bazuca no seu pé. Outra coisa: todo mundo me pergunta qual distro eu mais gosto. Eu uso Manjaro GNOME no meu dia a dia. Primeiro porque é um Arch Linux mais estável. Ele segura um pouco os pacotes mais novos, pra testar e garantir que nada vai quebrar. Mesmo assim alguns updates ainda quebram de vez em quando, mas é um bom compromisso entre ter coisas novas mais rápido e não ficar parado a cada novo update.

Mais importante: Manjaro já vem pré-configurado pra BTRFS logo na instalação. É só instalar, escolher BTRFS e ele vai se virar e te dar um ambiente estável. Em vez de mostrar Manjaro, vou mostrar Ubuntu 23, que acabou de lançar. Todo o trabalho de configuração que vou mostrar agora não precisa fazer fazer no Manjaro. Começando na instalação, todo mundo escolhe aqui a primeira opção, que vai instalar EXT4 igual toda outra distro. Mas agora ela tem essa segunda opção com ZFS, que é experimental ainda. De novo: não teste numa máquina de trabalho. Teste numa máquina virtual pra aprender tudo primeiro caso queira mesmo adotar ZFS.

Em vez disso vamos nessa terceira opção e particionar o disco manualmente. Não vou explicar cada detalhe. Vamos assumir que você está num PC moderno, dos últimos 10 anos. Provavelmente vem com modo legado na BIOS desligado, já suportando boot com EFI. Falando nisso, não deixe de assistir meu video que explica como o Boot de Linux funciona.

Enfim, vamos primeiro criar uma partição EFI que a BIOS vai procurar primeiro. Uns 200 megabytes costuma ser suficiente, deixe 500 se quiser garantir. Depois precisamos de uma segunda partição com um sistema de arquivos legado fácil da BIOS ler. Em Windows costuma ser FAT32, mas aqui podemos escolher o antigo EXT2 mesmo. Eu deixo 500 mega, mas de novo, pra garantir pro futuro caso a kernel cresça de tamanho, deixa 1 gigabyte. Espaço é barato.

Agora usamos o resto do espaço pra partição primária com BTRFS e montando o root nela. Se for um notebook, sempre recomendo criar uma partição encriptada com LUKS, ou no mínimo ter o subvolume de HOME encriptado com LUKS. Não vou explicar nada disso aqui porque é um saco de configurar, então pesquisem no Wiki do Arch sobre isso. BTRFS funciona mais ou menos como um LVM, um gerenciador de volumes lógico. Ele começa como um pool de subvolumes e por default vai criar um subvolume chamado “arroba” onde vai montar o “/” root e outro “@home” onde vai montar o “/home”.

Novamente, pesquise sobre LVM e volumes lógicos. Antigamente uma boa prática era separar duas partições: uma pra root onde fica o sistema operacional e outra pra home, daí montamos essa partição como “/home”. O problema de usar partições é que eles tem tamanho fixo. Uma vez definido não tem como redimensionar fácil. É como no Windows quando você particiona C: e D:. Mas com volumes lógicos, podemos redimensionar on the fly, sem qualquer problema. E BTRFS vai um passo além, subvolumes servem propósito parecido de volumes lógicos mas nem precisamos nos preocupar em redimensionar, eles são dinâmicos.

Enfim, quando terminar de instalar podemos bootar. Vamos acelerar aqui, três, dois, um e pronto. Ubuntu instalado. É muito fácil instalar distros Linux hoje em dia. Só não instala quem tem muita preguiça ou tem um hardware muito, mas muito ruim. Quando Linux não identifica hardware só tem duas opções: ou ele é muito ruim, ou é muito novo ou recém lançado. Se você não comprou um note que saiu este ano, não tem desculpa, é o hardware que é ruim, porque drivers pra Linux são atualizados constantemente.

Se estiver em dúvida num notebook, e tiver a oportunidade de experimentar antes de comprar, leve um pendrive com um Manjaro ou Ubuntu da vida e faça boot pelo pendrive. Veja se ele consegue identificar tudo: wifi, bluetooth, áudio, placa de video. É o melhor teste que pode fazer. Se alguma coisa não for detectada, desista desse modelo. Vai te dar mais trabalho do que compensa.

Pronto, agora vamos listar o arquivo “/etc/fstab” que o Ubuntu criou. Super simples. Dispositivos de armazenamento são identificados por um UUID. Abrindo o terminal, basta digitar “lsblk -f” e vai ter uma coluna com UUID. O arquivo “/etc/fstab” define quais dispositivos vão montar onde durante o boot. Por exemplo, o dispositivo de UUID que começa com ed022 vai montar como root “/”. Olhem na listagem, é o dispositivo /dev/vda3. O /dev/vda2 de UUID que começa com 294c8 monta como /boot.

A graça começa quando vemos o ponto de montagem de “/home”. O Ubuntu, pelo menos, separou corretamente um subvolume de BTRFS chamado “@home”. É uma boa prática. Mas temos alguns problemas. Do jeito que está aqui, não podemos ativar snapshots, porque seu espaço em disco vai desaparecer rapidamente.

Snapshots são possíveis por causa da funcionalidade de copy on write do BTRFS que expliquei antes. Copy on write funciona mais ou menos como branches num Git. Lembra que mostrei que o Git consegue manter o arquivo original, sem perder o conteúdo, mesmo eu gravando outro por cima? Pra fazer isso, obviamente, precisa manter o conteúdo original gravado em algum lugar, certo? Está gastando espaço extra. Diretórios do Linux como /var/cache, /var/log, /var/tmp estão em operação o tempo todo. Mesma coisa /tmp ou arquivo de swap. Se ficar mantendo versão velha deles em snapshots, o espaço livre do seu sistema vai acabar muito rápido sem você entender porque.

Pra resolver é assim: abre o terminal e faça “sudo chattr +C /var/log”. Isso é change attribute, estamos mudando o atributo do diretório pra dizer pro BTRFS não considerar arquivos nesse diretório pra snapshot. Esse change attribute só vai afetar novos arquivos criados, não os antigos que já existem, sempre se lembrem disso, mas como acabamos de instalar, acho que só isso deve ser suficiente.

Agora vamos instalar o Timeshift. É um programa gráfico pra fazer snapshots periódicos do sistema. Pra iniciantes, vai ser mais fácil do que lembrar os comandos pro terminal. Basta fazer “apt install timeshift” ou “yay -S timeshift” no Arch ou Manjaro. Logo que abrir ele vai oferecer pra configurar pra você. Mesmo se não estiver usando BTRFS, a alternativa é usar Rsync, caso esteja usando ext4.

Rsync, é um programa pra sincronizar dois diretórios. Equivalente no Windows é o novo robocopy ou o antigo xcopy. O jeito força bruta, sem a ajuda do sistema de arquivos, pra ter um backup local, é fazendo sincronização de diretórios. O problema é óbvio: vai ocupar espaço pra cacete no seu sistema, porque periodicamente vai duplicar tudo. Sim, se algo der errado e apagar algum arquivo que não devia, vai ter uma cópia. Com a funcionalidade de copy on write e snapshots do Btrfs temos a mesma coisa, mas sem duplicar nenhum arquivo e sem gastar mais espaço do que realmente precisa no mesmo HD.

Tá complicado de entender? Olha só, vou baixar um arquivo qualquer aqui, escolhi a ISO do Ubuntu. Acelerando e … pronto, baixado. Agora vou no Timeshift e crio um snapshot manualmente. Com o timeshift configurado posso escolher pra fazer snapshots de hora em hora, e guardar X snapshots por hora, Y snapshots por dia, Z por semana e assim por diante. Depois dêem uma fuçada, mas criei um pra mostrar agora. Snapshots são baratos, pode fazer toda hora. Não importa se você tem mil arquivos ou um milhão de arquivos, diferente de rsync, o tempo de criação de snapshots é quase instantâneo, porque ele não está duplicando nenhum byte, só metadados.

Simulando um acidente, oops, apaguei essa ISO que acabei de baixar. Que droga, vou ter que esperar um tempão pra baixar de novo. Ou não. Vamos no Timeshift e posso navegar pelos arquivos do snapshot. Olha só, se formos na pasta de downloads, a ISO está lá. Pronto, só copiar de volta pra pasta de downloads corrente e tá na mão: arquivo recuperado.

Não ficou claro? Vou dar outro exemplo. Mas pra isso precisamos terminar de configurar o Timeshift. De novo, siga o artigo que deixei linkado abaixo. Diferente do Manjaro que já me dá isso automaticamente, no Ubuntu precisamos manualmente instalar o grub-btrfs a partir do código fonte. Primeiro precisa instalar os pacotes build-essential pra termos compilador, e o git. Daí fazemos clone do repositório e “make install”.

Também precisamos instalar o pacote inotify-tools e editar a configuração do grub-btrfs com “systemctl edit –full grub-btrfsd” e trocar a opção “/.snapshots” por “–timeshift-auto”. Pronto, agora só iniciar o serviço e habilitar pra iniciar automaticamente depois do boot. E finalmente, mais um programa que precisamos instalar a partir do código fonte, o timeshift autosnap. Mesma coisa, só fazer clone do repositório e rodar “make install” dentro.

O que tudo isso faz? Se ainda não passou por isso, é só uma questão de tempo. Sabe quando estamos no meio do dia e pensamos, ah, vou fazer uma atualização no sistema. “apt update” daí “apt upgrade”, reboota o computador e pau, não boota mais. E vai ser justo naquele dia que você tá sem nenhum pendrive por perto, daí não consegue bootar no LiveCD. Você tá de home office e decidiu ir trabalhar do Starbucks, não tem nenhum amigo com computador por perto pra baixar a ISO pra você. Acabou sua tarde. Vai ter que voltar pra casa, achar um pendrive, baixar a ISO e gastar um tempo no stackoverflow tentando voltar um kernel antigo pra bootar de volta na sua máquina. Quem nunca?

E se eu disser que nunca mais vai precisar fazer isso? Vamos simular de novo. O Timeshift já está configurado pra fazer snapshots periódicos. Com isso, caso um dia lembre, puts, eu queria aquele arquivo que apaguei mês passado e achei que não fosse precisar. Meu HD de backup tá em casa, e agora? Sem problemas, só pegar o snapshot do mês passado, que está local na sua máquina. Mas, e na situação quando fizer um “apt upgrade” e isso quebrar seu sistema? Sem problemas também, aquele pacote timeshift autosnap vai criar um snapshot automático antes de todo “apt upgrade”.

Daí aquele pacote grub-btrfs vai listar esses snapshots no menu de boot do grub. Oops, Ubuntu por padrão não mostra o menu do Grub. Mas isso é fácil, só editar o arquivo “/etc/default/grub” e mudar a opção GRUB_TIMEOUT_STYLE de “hidden” pra “menu” e a opção GRUB_TIMEOUT de zero pra uns cinco ou dez segundos. Pra atualizar, só rodar “update-grub”. Vamos ver como funciona.

Pra simular, vamos criar mais um snapshot temporário chamado “teste” no Timeshift. Como é um snapshot manual, vou rodar “update-grub” manualmente, mas num “apt upgrade” não precisaria. Agora vou abrir a loja do Ubuntu e instalar alguns programas. Vamos instalar aqui o Gimp, vai demorar um bocado. Acelerando … Agora instalamos o Discord, de novo, vamos acelerar. Pronto. Podemos checar no menu, e estão aqui, Gimp, e Discord. Faz de conta que instalei um monte de coisas mas no final mudei de idéia, queria desinstalar tudo e voltar como estava antes. Como faz?

Fácil, só rebootar. Agora aparece o menu do Grub aqui no boot e tem esta nova opção e olha só os snapshots que estávamos vendo no timeshift. Estão vendo a descrição “teste”? Basta escolher esse ou um snapshot anterior. Entenderam? Posso bootar direto em um snapshot. Esperamos iniciar, e olha só. Cadê o Gimp? Cadê o Discord? Como o nome diz, timeshift, ele fez um shift no tempo, voltamos ao passado, exatamente como estava antes de instalar aqueles aplicativos. Imagine que em vez de Gimp ou Discord fosse um “apt upgrade” e veio uma kernel quebrada que fode o boot? Basta rebootar, escolher o snapshot anterior e pronto, vai ser como se nada tivesse acontecido.

Abrindo o Timeshift, pra tornar isso permanente, posso fazer um Restore do snapshot antigo pra passar a ser meu sistema corrente. Só isso. Entenderam? Com o Timeshift temos um backup local que ocupa muito pouco espaço e com isso qualquer acidente pode ser facilmente recuperado sem precisar de HD externo, sem precisar esperar copiar tudo de backup nem nada, muito menos reinstalar tudo do zero. É instantâneo.

Claro, isso é uma conveniência, pense como sendo sua última barreira de defesa. Isso não substitui um backup externo. O Timeshift e BTRFS, pra funcionar, depende que seu SSD esteja funcionando perfeitamente. Se o SSD em si der pau, como mostrei no começo do video, isso não vai te salvar. Aí só um backup externo. O que estou recomendando é ter as três coisas que mostrei até agora: se disciplinar a usar Git em todo projeto, pessoal ou de trabalho. Daí ter BTRFS e Timeshift pra consertar acidentes rápidos. E um backup externo pra evitar catástrofes mais sérias. São três níveis de segurança de dados pra ter dar paz de espírito.

E pra finalizar, tem um detalhe importante no caso de BTRFS. Aqui tem a ver um pouco com a Rinha de Backend de novo. Durante toda minha exploração dos projetos dos participantes, fiquei rodando Docker Compose de cada projeto. Eu já fiz um video explicando containers e Docker em particular, não deixem de assistir. Mas vamos entender o problema.

De dentro do projeto de qualquer um dos participantes, vamos rodar “docker compose up”. Lendo o arquivo docker-compose.yml, vai estar configurado várias aplicações, por exemplo, nginx, postgres. De onde vem esses aplicativos? O Docker vai baixar a imagem do docker.io. É isso que significa esses “pulls”. Uma imagem não é um único arquivo, é um conjunto de arquivos binários, que chamamos de overlays. Pense como se fossem commits de Git, mas commits binários. Esses overlays são unificados num único sistema de arquivos usando o Union File System ou UFS.

Se rodar o comando “mount” olha só aqui no fim, vários pontos de montagem usando overlays. Rode o comando “docker image ls” e temos a listagem das imagens baixadas e geradas localmente. A imagem do projeto em Node.js tá custando 220MB, o nginx tá ocupando quase 200MB, o postgres mais de 400MB. Só esse projeto, pra rodar, precisou gastar quase 1 Giga aqui no meu HD.

Onde ficam esses arquivos de overlays? Dentro do diretório “/var/lib/docker/overlay2”. Podemos listar como sudo e temos vários diretórios com o SHA256 de cada camada da imagem. Agora experimente testar docker compose de uns 50 projetos. Coisas como postgres e nginx, se forem da mesma versão, vão ser reusados, mas cada imagem de aplicação custa na faixa de 200 MB pra cima. Então 50 vezes 200 vai dar quase 10 Giga.

De tempos em tempos é recomendado rodar um “docker system prune” pra apagar imagens que não estão sendo usadas. Mas cuidado, se tiver containers, mesmo desligados, associados a uma imagem, ela não vai ser apagada e vai ficar sobrando ocupando espaço a toa. Use o comando “docker container ls -a” pra listar e apague os que não precisa. No caso de docker compose, quando acabar de testar o projeto, faça “docker compose down rmi –all” pra limpar containers, imagens, volumes e network que não for usar mais.

Mas beleza, 10Gb pra 50 projetos parece pouca coisa. O problema é que eu não excluí o diretório do docker da solução de snapshot. E o timeshift vai ficar criando snapshots periodicamente. Pense assim, eu fui baixando docker compose up, um monte de imagens, ao longo de mais de uma semana. Todo dia o timeshift foi fazendo snapshots. Num dia eu fazia docker compose up. No dia seguinte fazia docker compose down, achando que tava apagando tudo, mas na verdade eles estavam sendo guardados nos snapshots.

Depois eu resolvo testar o projeto de novo, faço um novo docker compose up. Vai baixar 1 giga de imagens outra vez. Só que agora tem 1 giga das imagens antigas no snapshot de ontem, e mais 1 giga duplicado no snapshot de hoje. BTRFS tem opção de deduplicação, mas ele não roda automaticamente, por padrão vai duplicar tudo. Repita isso em diversos projetos ao longo de duas semanas.

Quando terminei de testar tudo, escrevi o script do último video, gravei, editei, e meu sistema começou a ficar estranho. Tudo foi ficando mais lento. No começo achei que era pau do Microsoft Edge, porque ele começou a crashear do nada. Tentei reinstalar e nada. Ué, que diabos tá acontecendo com meu sistema. Eis que comandos de instalar pacotes como yay começaram a dar problema e aí caiu a ficha. Fui checar quanto de espaço eu tinha com “df -h” e tava dizendo que tava com 100% ocupado na partição primária.

Puts, as malditas imagens de docker! Tentei dar um docker system prune. Mas nada. Continua ocupando 100% do disco. Puts, os snapshots! As malditas imagens ficaram presas em snapshots do passado. Abri o timeshift e apaguei todos os snapshots do passado. Voltei pra verificar o espaço livre, e nada, continuava ocupando. Ué, que diabos.

BTRFS é conservador, ele não vai apagar nada a menos que você realmente diga pra apagar. Apagar snapshots não libera o espaço, pra isso precisa reclamar esse espaço de volta. Deixa eu demonstrar. Podemos rodar o comando “btrfs filesystem df /”. Uma das pequenas desvantagens de usar btrfs é que ferramentas normais de Linux como o comando “df” propriamente dito, podem informar valores incorretos.

No nosso Ubuntu de exemplo, estamos usando um total de 25GB. Isso é somando coisas como metadados do sistema de arquivos e tudo mais. Os bytes dos arquivos em si é esse “used”, pouco mais de 23GB. Ou seja, pelo menos 2GB são só metadados. Você precisa entender essa diferença. Tamanho de um arquivo não são só os bytes dentro desse arquivo. O nome do arquivo ocupa espaço, a informação de data de criação também, atributos como read only, localização no diretório também. Tudo ocupa espaço. E quanto mais avançado é o sistema de arquivos, mais espaço vai ocupar de metadados.

Enfim, se você não tem noção de quanto um sistema recém instalado ocupa, pode pensar “ah, 25 giga, ok, faz sentido”. Mas lembra que eu fiz alguns testes de snapshots pra vocês verem na prática? E aquele Gimp, e aquele Discord? Eles desapareceram, mas os bytes deles continuam no snapshot antigo. Vamos abrir o Timeshift e apagar todos os snapshots.

Rodando de novo o comando “df” do btrfs, não mudou nada. Continua indicando 25GB. Foi o que aconteceu na minha máquina quando acabou espaço. Mesmo apagando os snapshots, continuava indicando falta de espaço. Precisa manualmente reclamar o espaço de volta, pra isso usamos o comando “btrfs filesystem balance start /”. Esse comando é bem demorado. Pode levar mais de hora numa máquina como a minha, mas pelo menos podemos continuar usando o sistema em paralelo.

Enfim, esperamos acabar e pronto. Vamos ver de novo o comando “df” e olha só, caiu de 25GB pra 10GB! Tinha 15 GB sendo reservado pelo btrfs seja pros snapshots antigos e outras coisas dele. E isso numa instalação nova, praticamente vazia, onde só instalamos 2 programas. Agora imagina no meu caso, com dezenas de imagens de docker em snapshots. Ocupou meu HD inteiro de 1 terabyte. Pois é, foi muito fácil encher 1 tera em poucos dias só de não ter tomado cuidado.

E como faz pra isso não acontecer? Tem que fazer “sudo chattr +C /var/lib/docker” ou também “sudo chattr +C /var/lib/libvirt” no caso de estar usando Libvirt pra máquinas virtuais. E de novo, isso só vai se aplicar a arquivos novos. O correto é primeiro limpar esses diretórios, daí mudar esse atributo. Acho que o certo não é aplicar esse atributo no diretório todo, algumas coisas talvez você queira manter snapshots, como volumes de Docker. Fique só atento com isso.

Essa dica é muito importante, porque se você não entender o funcionamento de snapshots no btrfs e começar a usar como máquina de desenvolvimento, com certeza vai ter imagens de docker, e isso com certeza vai destruir o espaço livre em poucas semanas. Você não vai saber que é, nenhum tutorial de como liberar espaço vai funcionar, você não saberia que precisa rebalancear o sistema, e no final iria desistir e reinstalar tudo do zero de novo.

No momento em que estou escrevendo este script, no meu Manjaro, se rodar “df” ele me diz que está usando 775 giga do meu NVME de 1TB de novo. De arquivos mesmo são só 164 GB. Bora rodar “balance start” e ir tomar café. Deixei 1 hora rodando e olha só, agora diz que está usando um total de só 166 giga, que faz mais sentido. Ainda tinha uns snapshots velhos, provavelmente com imagens de docker velhas.

Logo que instalei o Timeshift, mostrei que tem como configurar pra guardar snapshots só de hoje, ou da semana, ou até de meses. Se você tem um bom backup externo, isso não é necessário, só o do dia ou até o da semana deve ser suficiente. Quando ver que está acabando o espaço, sabendo que tem tudo no backup externo, pode apagar todos os snapshots do timeshift, menos o último. Daí rodar o rebalanceamento e pronto.

Segurança é um trade off com performance e espaço. Gastamos mais processamento e gastamos mais espaço, pra garantir paz de espírito, essa é a filosofia. E felizmente chegamos num ponto onde o sistema operacional realmente nos ajuda a não perder nada. A única coisa que nenhum software consegue fazer, é consertar um hardware barato porcaria. Contanto que o hardware seja bom, é quase impossível perder dados hoje em dia. Tão importante quanto não perder dados importante é não perder horas ou dias tentando recuperar seu sistema por causa de uma atualização bugada. Basta não ter preguiça, porque as ferramentas estão à nossa disposição e, como demonstrei, são super fáceis de usar.

O meu NAS Synology usa BTRFS também, mas em configuração de RAID. Ele roda scrubbing a cada 6 meses e faz checagens de checksum pra garantir que nenhum erro físico nos HDs me faça perder dados. Isso é só pra quem escolher ter um NAS: lembre-se de configurar pra rodar scrubbing, é essencial, mas isso vem desligado por padrão. Não basta só instalar e achar que vai tudo funcionar por mágica.

Numa distro Linux como Ubuntu ou Manjaro, tenho o Timeshift. Mas no sistema operacional da Synology, ele tem o Snapshot Replication, que também me permite navegar por snapshots antigos e recuperar coisas rapidamente. Olha só, se der qualquer problema, consigo ver como eram meus arquivos de 4 meses atrás. E não sei se perceberam, mas esse sistema de snapshots me dá outra coisa de graça: proteção contra ransomware.

O que é um ransomware? É um malware que você instala ao abrir um powerpoint ou PDF qualquer que veio de um email desconhecido e na verdade era um programa malicioso. É assim que YouTuber perde o canal deles: clicando em PDF falso que não era um PDF. Parem com essa mania de dar duplo clique em tudo. O malware se instala silenciosamente na sua máquina e começa a encriptar seus arquivos. Pode levar dias e você não vai perceber até precisar abrir um desses arquivos e notar que não abre mais.

No final vai aparecer uma janela parecida com essa dizendo algo como “Você se fodeu, encriptamos todos os seus arquivos, podemos te dar a chave pra desencriptar mas você vai nos pagar X bitcoins pra isso. Mande pra este endereço e daí te damos a chave”. Isso realmente acontece, e não existe garantia nenhuma de receber essa tal chave, mesmo pagando. Se isso acontecer com você, nunca pague, só aceite que você se fodeu. Reze pra ter seguido minhas recomendações.

Ah, mas eu tenho backup externo, então tô seguro, não? Não. Eu disse que leva dias pra esse processo conseguir encriptar todos os seus arquivos. Durante esse período o que você fez? Plugou o HD externo e deixou fazendo backup dos arquivos encriptados por cima dos arquivos bons do backup. Agora seu backup também foi contaminado, parte dele tá encriptado. Perdeu playboy.

É menos ruim se estiver usando Google Drive ou Dropbox ou OneDrive da vida, porque eles tem suporte de snapshot. Mas eu não confiaria muito. Nunca precisei usar o deles então não fucei o suficiente, mas veja esta minha pasta do Obsidian no Dropbox, que é onde edito meus scripts. Tem essa função de Rewind, que é voltar pra trás. Escolho o dia que quero voltar, e ele me mostra as últimas atividades. Daqui posso escolher voltar pra algum ponto do passado, mais ou menos como commits também. É meio um saco porque eu não vi uma interface que permite voltar meu Dropbox inteiro, acho que tem que ir diretório a diretório, não tenho certeza. Enfim, não achei muito intuitivo de usar, mas em última instância, se não tiver mais pra onde recorrer, talvez isso ajude.

Se um ransomware encriptar todos os seus arquivos, mesmo no Dropbox vai estar tudo encriptado, mas se tiver o Rewind de alguns dias pra trás, pode tentar recuperar. Isso é ok, mas eu não gosto de depender de um serviço que não tenho controle. Por isso essa mesma pasta de Dropbox está em BTRFS no meu NAS, sendo sincronizado com o aplicativo Cloud Sync da Synology. Eu uso os três, Google Drive, Microsoft OneDrive e Dropbox como backups secundários offsite de alguns dados. E o meu NAS tem snapshots de BTRFS ativado pra até 4 meses pra trás.

Ou seja, isso nunca vai acontecer, mas se por ventura algum malware conseguir passar por mim e encriptar meus arquivos, eu só dou risada, volto alguns snapshots pra trás e mando esse hackerzinho de merda tomar no cú. Não pego malware faz pelo menos uns 20 anos, e sempre tenho múltiplos backups de tudo, tanto local quanto offsite, fora daqui. E os arquivos mais antigos que realmente não quero perder já queimei tudo em Blurays Millenium Disk, feitos de material inorgânico que nunca oxidam. Todos guardados no meu cofre. Vem tentar encriptar meus dados seus hackerzinhos de merda.

Segurança é uma questão de oportunidades. Quanto mais você pensar que nunca vai acontecer com você, maiores as chances de realmente acontecer. Eu penso o contrário, sempre penso que estou 100% inseguro 100% do tempo e faço toda a estratégia em cima disso. Segurança funciona em camadas. Se o plano A falhar, tem o plano B. Se o plano B falhar tem o plano C. Isso se chama contingência. Quem não prepara contingências, sempre vai viver dando desculpas. E eu odeio desculpas. Se desculpas funcionassem, não precisávamos de polícia.

Por fim, um comentário que não coube antes no video é sobre como mantenho meu Manjaro. Uma recomendação que dou é usar muito Docker pros seus projetos. Não precisa instalar coisas como MySQL, Postgres, Redis nem nada local. Use tudo com Docker Compose. Primeiro porque isso garante que estamos rodando a versão certa de cada coisa pra cada projeto. Segundo, porque é menos pacotes instalados na sua máquina que o Manjaro vai precisar ficar atualizando. Quanto mais pacotes instalar, maiores as chances de algum upgrade quebrar alguma coisa.

Pelo mesmo motivo, tudo que é aplicativo como Discord, Zoom, o próprio browser Edge que eu uso, Firefox, e muito mais, eu prefiro instalar via Flatpak. Flatpaks são containers, tipo um Docker light. E dá pra usar coisas como FlatSeal pra garantir que nenhum aplicativo tem mais permissões e acessos do que deveria. Podemos fechar um Discord pra não conseguir enxer nada dos seus arquivos, só deixar ele ver a pasta de Downloads, por exemplo. Depois veja este video explicando sobre Flat Seal.

Eu sei que vai aparecer o povo do NixOS nos comentários, mas eu não pretendo usar e nem preciso. Meu sistema é super estável. Raramente tenho problemas, porque eu instalo o mínimo possível. Pra projetos tá tudo em Docker. Aplicativos tudo em Flatpak ou Snap. E coisas mais arriscadas, como games, ou meus experimentos com LLMs e IAs, estão tudo em máquinas virtuais com QEMU/KVM como mostrei neste outro video. Fazendo tudo que mostrei neste video, não precisei reinstalar meu sistema nenhuma vez e nunca perdi nem dados e nem tempo. Qualquer besteira que eu faço, o Timeshift me salva, qualquer besteira maior e os backups no meu NAS me salvam.

Recapitulando: sempre, sempre, inicie um repositório git local no seu projeto, independente de ter no GitHub ou não. Sempre, sempre, tenha no mínimo um HD externo USB da vida, um pouco maior do que o HD do seu PC, e configure o app de Backup que já vem no seu sistema operacional. Não precisa de nada super fancy nem nada. Só habilita. Qualquer backup é melhor que nenhum backup. Finalmente, se quiser aprender mais de Linux e usar o que há de mais novo, instale Manjaro com suporte a BTRFS e configure o Timeshift como eu expliquei. Isso vai tornar você quase invencível, é praticamente um super poder. Se ficaram com dúvidas, mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e compartilhem o video com seus amigos. A gente se vê, até mais!

A Rinha de Backend que aconteceu em Agosto de 2023 foi muito divertida. Eu só fiquei sabendo quando acabou, mas não quer dizer que não pude me divertir. Hoje quero resumir tudo que eu fiz nos 16 dias seguintes do evento, detalhes sobre os projetos dos participantes, a controvérsia do Ranking de Linguagens, quais os truques por trás dos vencedores, e como você também poderia ser um vencedor!

Finalmente vou demonstrar o que significa “ser promíscuo” com linguagens de programação. Vamos entender porque como de fato ler um ranking. E como podemos fazer TODO MUNDO alcançar o primeiro lugar do Rust!

Conteúdo

• 00:00:00 - Intro
• 00:01:41 - CAP 01 - As Regras - Requerimentos da Rinha
• 00:09:46 - CAP 02 - Os Participantes - Vencedores da Rinha
• 00:15:25 - CAP 03 - Dia 1: Entrando na Rinha - Minha versão em Ruby on Rails
• 00:21:08 - CAP 04 - MrPowerGamerBR entra em cena - A chegada dos Piratas!
• 00:27:55 - CAP 05 - Tentando com Crystal - Aprendendo Lucky Framework
• 00:34:01 - CAP 06 - Dia 8: Gerenciando Baratie - Fluxo de Restaurante
• 00:38:37 - CAP 07 - Consertando Meu Rails - Aprendendo com Erros
• 00:42:54 - CAP 08 - Aprendendo com Node.js - Muita Refatoração
• 00:49:48 - CAP 09 - Apanhando de Erlang - Segredos de Elixir
• 00:55:51 - CAP 10 - Explorando Go Lang - Essa foi fácil
• 00:57:31 - CAP 11 - Dando Moral pra NATS - C# Vencedor
• 00:58:15 - CAP 12 - Dia 12: Explorando PHP Moderno - De Node a Swoole
• 01:00:12 - CAP 13 - Elevando Python - Pequeno Erro
• 01:02:21 - CAP 14 - “foi lá, E FEZ” - A Saga de Lean4
• 01:06:28 - CAP 15 - Pré-Feriado: Tentando NIM - A decepção
• 01:08:47 - CAP 16 - Diário de Bordo: Resumo - Chegando na Grand Line
• 01:13:05 - CAP 17 - Feriadão! - Encontrando o One Piece??
• 01:19:16 - CAP 18 - Testando o One Piece! Todos ao Primeiro Lugar!
• 01:27:16 - CAP 19 - Conclusão: Por que todo mundo não usa Rust?? - Escala de Mercados
• 01:37:33 - Bloopers

Links

• Repo Oficial da Rinha: https://github.com/zanfranceschi/rinha-de-backend-2023-q3/tree/main
• MrPowerGamerBR: # Os Resultados da RINHA DE BACKEND estão ERRADOS, e eu posso provar https://www.youtube.com/watch?v=XqYdhlkRlus
• Raciocínio Automatizado com Leonardo de Moura, Pesquisador na Microsoft Research https://dev.to/elixir_utfpr/raciocinio-automatizado-com-leonardo-de-moura-pesquisador-na-microsoft-research-4d1k
• Rinha versão Algebraic https://github.com/meoowers/rinha Repositórios da Sofia https://github.com/algebraic-sofia?tab=repositories

Tweets

• Tweet: Início da minha versão de Rails https://x.com/AkitaOnRails/status/1695526606503022923?s=20
• Tweet: O ranking oficial não é importante, discutir as técnicas, sim https://twitter.com/AkitaOnRails/status/1695913459202838839
• Tweet: 1o resultado com Crystal/Lucky https://x.com/AkitaOnRails/status/1696207752043872433?s=20
• Tweet: Minhas impressões aprendendo framework Lucky, em Crystal https://twitter.com/AkitaOnRails/status/1696220345152176478
• Tweet Leandro: diminuir workers do nginx melhora uso no lado do postgres https://x.com/leandronsp/status/1696292520106299417?s=20
• Tweet: Mais discussão das técnicas de otimização como batch insert https://x.com/AkitaOnRails/status/1696255958328938745?s=20
• Tweet Leandro: experimentando a teoria de diminuir workers e pool na versão de Ruby, conseguindo quase 30k https://x.com/leandronsp/status/1696219396316836331?s=20
• Tweet: contribuindo com o projeto Kiwi e comentando sobre LevelDB https://x.com/AkitaOnRails/status/1697283886156226818?s=20
• Tweet: meu mantra da programação https://x.com/AkitaOnRails/status/1697317688006066432?s=20
• Tweet: 1o resultado positivo com Crystal https://x.com/AkitaOnRails/status/1697651647273427429?s=20
• Tweet: 1o resultado positivo com Rails https://x.com/AkitaOnRails/status/1698475713920119117?s=20
• Tweet: mexendo na versão Node do Lucas Weis https://x.com/AkitaOnRails/status/1698565631560282590?s=20
• Tweet: desafio: todas conseguem bater os 40k https://x.com/AkitaOnRails/status/1698491304366219744?s=20
• Tweet: apanhando da versão Elixir do Gabriel Oliveira https://x.com/AkitaOnRails/status/1698760144924905474?s=20
• Tweet: revisando a versão Elixir https://x.com/AkitaOnRails/status/1698809091055874491?s=20
• Tweet Gabriel: consertando o crash de Elixir no meu PC https://x.com/oliveigah/status/1698866344853151857?s=20
• Tweet: resolvido problema do Elixir https://twitter.com/AkitaOnRails/status/1698888695376437677
• Tweet: mexendo no Go do Luan, 29k https://x.com/AkitaOnRails/status/1698818634397647092?s=20
• Tweet: fuçando a versão finalista de Dotnet https://twitter.com/AkitaOnRails/status/1698851765658013900
• Tweet: 1o resultado da versão PHP do Lauro https://twitter.com/AkitaOnRails/status/1698923556631990453
• Tweet: 1o resultado da versão Python do Ian Cambrea: https://twitter.com/AkitaOnRails/status/1698966472083517931
• Tweet: Primeiro contato com Lean4 https://twitter.com/AkitaOnRails/status/1699064101111218212
• Tweet: Bibliotecas em Lean da Sofia https://twitter.com/AkitaOnRails/status/1699069812079767739
• Tweet: Resumo até agora https://twitter.com/AkitaOnRails/status/1698900197068153027
• Tweet: Resumo das técnicas até agora https://twitter.com/AkitaOnRails/status/1698903125338226739
• Tweet: Tentando versão em Nim (fracasso) https://twitter.com/AkitaOnRails/status/1699533869739856257
• Tweet: versão nova em Java do Junior Leão https://twitter.com/juniorleaoo/status/1699427149831114850
• Tweet: versão desclassificada em V Lang do Carlos Silva https://twitter.com/_insalubre/status/1699498542245544269
• Tweet: Leandro explica a lógica de diminuir vazão do nginx https://twitter.com/leandronsp/status/1699568664859603184
• Tweet: resumo das técnicas até agora: https://twitter.com/AkitaOnRails/status/1698903125338226739
• Tweet: Vinicius Ferraz descobre e publica network_mode: host https://twitter.com/AkitaOnRails/status/1700488994323128673
• Tweet: Reinaldo/Zsantana, atinge Zero knockouts: https://twitter.com/reijsantana/status/1701000310280573287
• Tweet: Chegando de viagem e ajustando todo mundo de novo: https://x.com/AkitaOnRails/status/1701230737922339143?s=20
• Tweet: Rails bate 45k https://x.com/AkitaOnRails/status/1701248237586219416?s=20
• Tweet: Ruby do Leandro bate 47k https://x.com/AkitaOnRails/status/1701423430870954312?s=20
• Tweet: Rails do Lazaro bate 46k https://x.com/AkitaOnRails/status/1701446727910199459?s=20
• Tweet: Node.js bate 46k https://x.com/AkitaOnRails/status/1701295880844775425?s=20
• Tweet: Go do Luan bate 46k https://x.com/AkitaOnRails/status/1701286259459523033?s=20
• Tweet: Bun bate 43k https://x.com/AkitaOnRails/status/1701630742642471420?s=20
• Tweet: Python bate 46k https://x.com/AkitaOnRails/status/1701267343521767606?s=20
• Tweet: V Lang bate 46k https://x.com/AkitaOnRails/status/1701256544904438210?s=20
• Tweet: Consertando Java do Reinaldo, bate 46k https://x.com/AkitaOnRails/status/1701402351913910693?s=20
• Tweet: C++ do Lucas William bate 46k https://x.com/AkitaOnRails/status/1702008261736534294?s=20
• Tweet: Refatorando o Rust do Vinicius https://twitter.com/AkitaOnRails/status/1701816747274260698

Pull Requests

• PR versão Node.js https://github.com/lukas8219/rinha-be-2023-q3/pull/1
• PR versão Node.js, network mode https://github.com/lukas8219/rinha-be-2023-q3/pull/2
• PR versão Go Lang https://github.com/luanpontes100/rinha-de-backend-2023-q3-golang/pull/1
• PR versão Go Lang, network mode https://github.com/luanpontes100/rinha-de-backend-2023-q3-golang/pull/1
• PR versão PHP/Swoole https://github.com/lauroappelt/rinha-de-backend-2023/pull/1
• PR versão Python/Sanic https://github.com/iancambrea/rinha-python-sanic/pull/1
• PR versão de Lean4 fix de Location: https://github.com/meoowers/rinha/pull/1
• PR versão de Lean4 fix de data: https://github.com/meoowers/rinha/pull/2
• Versão em Nim/Jesper: https://github.com/akitaonrails/rinhabackend-nim-jester-api
• Versão em Java/Quarkus: https://github.com/zsantana/rinha-backend-by-bruno-borges/tree/main
• PR versão de C++: https://github.com/lucaswilliameufrasio/backend-cockfighting-q3-2023/pull/1
• PR versão de C# do Zan: https://github.com/zanfranceschi/rinha-de-backend-2023-q3-csharp/pull/3
• PR versão de Ruby do Leandro: https://github.com/leandronsp/rinha-backend-ruby/pull/4
• PR versão de Bun: https://github.com/Met4tron/rinha-bun/pull/1
• PR versão de Java do Reinaldo, fix de data: https://github.com/zsantana/rinha-backend-sem-cache/pull/1
• PR versão de V Lang, network mode https://github.com/carlosqsilva/rinha-2023-q3/pull/1
• PR versão de Rust do Vinicius, refactoring e fix: https://github.com/viniciusfonseca/rinha-backend-rust/pull/2

SCRIPT

Olá pessoal, Fabio Akita

Se costuma acompanhar a comunidade de desenvolvimento no Twitter, talvez tenha ouvido falar que em agosto de 2023 aconteceu um mini evento online chamado de Rinha de Backend, organizado pelo Zanfranceschi, desenvolvedor experiente, atualmente trabalhando no Nubank.

Eu não conhecia ele e só fiquei sabendo que esse evento aconteceu quase uma semana depois que já tinha acabado. Mesmo se soubesse antes não teria participado porque nunca fui de competições, hackathons ou algo assim. Mas eu gostei muito do que os participantes fizeram e, sem querer, isso tomou boa parte do meu tempo, incluindo várias noites mau dormidas.

Sem sombra de dúvidas este vai ser o video mais trabalhoso que já fiz na história deste canal. Não só este como o próximo. Hoje vou resumir minha saga de 16 dias do pós-rinha avaliando diversos projetos dos participantes. Neste percurso, aprendi muita coisa nova que não sabia ou que achava que fosse ser diferente. Foi uma longa saga, muitas noites mau dormidas, frustração, ansiedade, crises existenciais, suor e lágrimas. É bastante coisa e só o resumo vai dar um video de mais de 1 hora.

Por isso vou pedir muita paciência de vocês. Vai ter várias técnicas importantes que vou mencionar o nome e os efeitos que causam, mas vai ser bem por cima. Se ficarem confusos com termos que parecem complicados, não se preocupem, vou explicar os detalhes no próximo. Também vai ser no próximo que vou falar detalhes das linguagens que vou mencionar. Então segurem as críticas. Hoje quero só compartilhar como foi minha experiência.

Primeiro vou resumir como foi o evento em si, um pouco sobre os projetos que ganharam e o ranking que gerou alguma controvérsia, pelo que ouvi falar. Daí vou contar o que pensei a respeito e como resolvi começar a abrir os projetos dos participantes com uma missão: fazer todo mundo chegar no primeiro lugar!

(…)

Como disse, eu não participei do evento, nem acompanhei o dia a dia. Acho que o desafio foi lançado primeiro mas ninguém sabia exatamente como seriam os critérios pra definir o vencedor até dias depois. E parte da graça de uma “rinha” como essa não é ser uma competição tecnicamente, perfeitamente justa, tem muito fator sorte e incerteza envolvido, como em qualquer esporte.

Nem sempre é o melhor atleta técnico que ganha todos os jogos, mas quem aprendeu mais nos jogos anteriores, quem consegue se adaptar rápido e quem teve menos azar. Assim foi esta rinha também, por isso em nenhum momento encarem qualquer coisa que parece uma crítica como uma crítica ao evento e sim como dicas pros próximos. Minha discussão vai ser puramente técnica. A crítica real vai pra quem tentou levar isso a sério demais. Ser torcedor apaixonado de um time é normal, sair xingando e brigando na rua quando vê o cara do outro time é ser um animal irracional imbecil. Vou assumir que estou falando com homo sapiens e não neandertais.

O desafio foi divulgado num repositório de GitHub do Zan que vou deixar o link nas descrições abaixo. Aliás, sempre olhem a descrição de todo video. Eu coloco links pra várias coisas extras pra vocês. Além de ter a descrição de todos os capítulos pra ficar mais fácil achar seções de videos longos como este. Enfim, leiam as instruções do desafio mas em resumo, o objetivo era escolher qualquer linguagem de programação, com ou sem frameworks, implementar 4 endpoints de APIs e configurar pra rodar com Docker Compose numa configuração específica de infraestrutura.

Fazer a API em si, em qualquer linguagem, é super simples. É um endpoint POST “/pessoas” que recebe um JSON simples com dados como apelido, nome, data de nascimento e stack de programação, um array com elementos como “php” ou “java”. É como se fosse o cadastro de um sisteminha de recrutamento ou algo assim. Tem que validar que apelido tem no máximo 32 letras, nome no máximo 100 letras, data de nascimento tem que ser minimamente válido. Inclusive ele não fala que 31 de fevereiro tem que ser inválido, só fala que o formato tem que ser ano, tracinho, me, tracinho, dia.

A lista de stack tem que ser um array sem elementos nulos e cada elemento não podia ter mais que 32 letras. E finalmente, o ID tinha que ser um UUID, que é um tipo de número aleatório. Isso foi um bom requerimento como vou mostrar mais pra frente. Mas em termos de validação era só isso. Se passar dados inválidos temos que devolver o cabeçalho HTTP 400 de bad request.

Ou se voltar erro no insert do SQL por causa de constraints inválidas como nome não poder ser nulo, apelido já existir ou algo assim, tem que devolver cabeçalho HTTP 422 de erro unprocessable entity. A resposta pra requisição de criação precisa ter o cabeçalho HTTP 201 created e um cabeçalho “Location” com o caminho pra essa pessoa recém criada no formato GET “/pessoa/uuid”. Isso é comum numa API restful básica.

Esse endpoint devolvido no Location deve conseguir encontrar a pessoa recém criada e devolver o JSON com os dados. Se passar um UUID que não existe, tem que devolver o cabeçalho HTTP de 404 not found. Depois precisava ter outro endpoint GET “/pessoas” que receba um parâmetro chamado “t” pra ser um “termo de procura”, pra pesquisarmos o termo no apelido ou nome ou na stack. Seria tipo fazer um SQL com apelido like “%termo%” OR nome like termo OR stack like termo. Já vou explicar porque esse seria o pior jeito.

Devolvemos o resultado em JSON com código HTTP 200 ou devolve código 400 de erro se não passar termo nenhum. Não encontrando nada bastava devolver um JSON com array vazio em vez de 404 not found. E finalmente o 4o endpoint era um simples GET “contagem-erro” que deveria fazer um count na tabela e devolver quantas inserções de fato aconteceram. Esse é o único endpoint que não faz parte do stress test e isso pode se tornar um ponto importante pra alguns truques como vou explicar no próximo video.

Como podem ver, são endpoints super triviais. Se você é um programador experiente tenho certeza que já tem de cabeça como faria na sua linguagem mais fluente. Dá pra fazer rapidinho uma versão que funciona em 1 ou 2 horas se estiver um pouco enferrujado. Mesmo se for bem iniciante, seguindo qualquer tutorial de APIs restful no framework que estiver aprendendo, é pra conseguir fazer em 1 dia. Essa é a ordem de grandeza e talvez sirva pra vocês saberem em que pé estão. Vai demorar mais do que isso se quiser experimentar técnicas diferentes. Teve versão que eu levei uns dois dias pra terminar porque resolvei aprender um framework novo do zero, por exemplo.

No próximo video vou demonstrar como dá pra fazer uma versão simples em poucos minutos, por agora só acreditem que dá. Aliás, vamos começar a listar coisas pro próximo episódio. “Mostrar como fazer uma versão simples do zero”. Mas agora vem a parte que separa os adultos das crianças: a infraestrutura. Não basta só fazer o código e dizer “roda na minha máquina”. Tem que rodar dentro das restrições da rinha. Então não é só subir um banco de dados, subir sua aplicação sozinha e acabou.

Segundo as regras, tem que subir duas instâncias da sua aplicação, pra rodar em paralelo. E ambos precisam ficar embaixo de um balanceador de carga, no caso pediram o Nginx. No mundo real aplicações rodam com várias instâncias em paralelo embaixo de um balanceador de um Kubernetes, Seasaw, HAProxy ou várias outras alternativas. Azure tem o Application Gateway, AWS tem o ELB, o Elastic Load Balancing, tem o Traefik, F5 Big-IP e mais. Mas NGINX é fácil e simples o suficiente pra este desafio. Não é o mais rápido, mas também não é o mais difícil de usar.

E aqui começa a parte realmente difícil: uma instância de NGINX, uma instância de banco de dados, que pode ser postgres, mysql ou mongodb, mais duas instâncias da sua aplicação sendo balanceadas, precisam caber em 1 CPU e meio e no máximo usar 3 gigabytes de RAM e só. Essa é a regra da rinha. Fazer a API não é o desafio. Essa limitação que é. Mas tudo bem, fazer caber é fácil, o problema mesmo é que no final esse sistema tem que aguentar um stress test, um teste de carga.

Stress test é um teste automatizado que simula como pessoas ou sistemas consumiriam o seu sistema, mandando requisições http pros endpoints da API. No caso eles escolheram a ferramenta Gatling, que tem versão aberta e uma paga com mais recursos. A versão gratuita é razoavelmente simples de usar e o script pro cenário de carga está no GitHub da rinha. Vamos anotar aqui pra eu explicar “O Básico de Stress Test” no próximo video.

Lembrando que quando a rinha começou acho que os participantes ainda não tinham acesso a esse script de testes, justamente pra não tentar burlar os critérios. Eu não sei se eles sequer tiveram acesso ao script durante a rinha. Imagino que não, só no final. Vamos assumir que ninguém sabia. Isso que diferencia os participantes da rinha de programadores como eu agora, que tem a oportunidade de avaliar sabendo tudo que eles não sabiam. Não comparem o meu resultado com o deles, isso seria injusto.

Em resumo, você podia escolher linguagem, framework e implementar uma aplicação web que serve 4 endpoints de APIs. Tinha que ser o mais leve possível pra aguentar carregar duas instâncias, mais nginx, mais banco, em 1.5 CPUs e 3GB de RAM, orquestrado por docker compose.

Eu ainda não fiz um video explicando o que é um framework web, então vamos anotar aqui pra explicar no próximo video. Eu já tinha feito um video sobre Docker, recomendo que assistam depois, mas aí também no próximo vou explicar como usar o Docker Composer pra subir todos os componentes de um sistema web na sua máquina também.

A idéia é que os participantes deviam empacotar a aplicação numa imagem de Docker, subir no Dockerhub, postar o arquivo de docker compose como pull request no GitHub da rinha e aí os organizadores iam rodar esse docker compose e aplicar algum teste de carga. Quem passasse, ia pro ranking final.

O ranking foi interessante. Teve 90 participantes. Desses, 39 foram desclassificados por diversas razões. Ou o docker compose tinha algum bug e nem carregava, ou algum dos endpoints da API não respondia como deveria, ou deixaram de implementar alguma coisa que tinha nas regras. Sobraram 51 projetos que funcionaram, mais da metade. Um número respeitável. No final, além de implementar os endpoints corretamente, o resultado pro ranking foi baseado na quantidade de inserts que foram feitos no banco de dados.

Ordenando a lista por essa quantidade de inserts, tivemos os Top 10. Quem ganhou a rinha foi o Vinicius Fonseca, com sua implementação usando Rust, com o framework Actix com Tokio. Em segundo lugar ficou o Leo Vargas com sua versão em Go e Fiber, o framework que usa FastHTTP. Em terceiro ficou o André Marra e Albert Kliemke, que fizeram em dupla uma versão em Dotnet 8 com C#. Em quarto ficou a Isadora Souza, que também usou Go com Gin. Em quinto ficou a dupla algebraic, a Sofia e a Gabi, que fizeram em Lean4, a linguagem mais desconhecida da rinha toda. Depois vou falar delas.

Em sexto ficou o Vinicius Santos que também fez em Rust. Em sétimo ficou o Jean Rodrigues que também fez em Go. Em oitavo ficou o Luiz Picanço, com outra versão em Rust. Em nono lugar “e” também em décimo ficou o Rodrigo Navarro, que participou com duas versões de Rust, uma feita com o framework Axum e outra com o mais leve Touche que, por ironia, ficou depois da versão em Axum. Aliás, parece que ele fez pelo menos uma dessas versões numa live no canal dele, pra quem se interessar corre atrás pra assistir.

Portanto, nos Top 10 ficou assim: 5 versões em Rust, 3 versões em Go, 1 em Lean e 1 em dotnet. Aí as redes sociais foram à loucura. Primeiro, ninguém achou estranho já que isso confirma a hegemonia do Rust e do Go como as linguagens mais rápidas da atualidade. Pior ainda: o fato de dar um dotnet nos Top 10 mas não um Java, fez um monte de gente ficar ridicularizando o Java. Sabe o que falei do torcedor de time neandertal? Sim, afinal na cabeça deles, Java é uma linguagem velha e ultrapassada, certo? Vamos ver como os neandertais leram o resto do ranking.

Seguindo pros próximos 10. Em décimo primeiro ficou o Gabriel Oliveira com uma versão em Elixir. Alguns ficaram tipo, “puts, não era o Elixir que se vendia como rápido? Perdeu até pro dotnet?” Em décimo segundo ficou o Lucas William com uma versão em C++. “Ué, C++ não era pra ser o mais rápido? Rust e Go são foda mesmo, muito melhor que C++”. Em décimo terceiro ficou o Lucas Weis com uma versão em Node.js com Express. “Pois é, bem que me falaram que Javascript não é tudo isso que falam, né?”

Em décimo quarto ficou o Yuri Gomes que fez uma versão em Bun, antes do lançamento da versão 1.0 alguns dias atrás. E pois é, Bun é só hype mesmo, nem lançou ainda e já é lento. Em décimo quinto ficou o Thales Maciel que fez em Rust também. Coitado, deve ser um júnior que né, não é culpa do Rust. Em décimo sexto ficou um cara de apelido saiintbrisson, que não deixou arquivo de README pra trás com o nome nem links, então nem fui tentar procurar.

Em décimo sétimo ficou o Lauro Appelt com sua versão em PHP. Finalmente uma linguagem que se associa mais com Web clássica. Quem diria, PHP ainda não morreu, mas tá lá embaixo com um pé na cova né? E só em décimo oitavo ficou o Bruno Borges com a primeira versão em Java da rinha. E só pra piorar a situação do Java, ele ficou encostado no décimo novo que foi o Lázaro Nixon com uma versão em Ruby on Rails e o vigésimo do Leandro Proença que também fez uma versão em Ruby. Peraí, Java tá tão ruim agora que fica encostado em Ruby?? Que fase heim?

Eu queria parar no vigésimo, mas só no vigésimo primeiro lugar tivemos o Ian Cambrea com a primeira versão em Python, usando Sanic, na competição. Pelo visto Python também é só hype né? Não ganhou nem de PHP, nem de Ruby e nem de Java. Espero que vocês que acompanharam não tenham pensado desse jeito, porque seria vergonhoso.

Dentre os 51 projetos enviados, 8 foram feitos em Go, 7 em javascript, 6 em Rust, 6 em Java. 5 em PHP. 4 em dotnet. 3 em Python, 2 em Ruby, 2 em Elixir, 1 em C++, 1 em Lean, e o último lugar foi 1 feito em Bash pelo Leandro. Teve uns 3 no ranking que o README não dizia em que linguagem foi feito e nem o link pro Github então também não fui atrás pra saber.

O Lean da Sofia e Gabi foi o mais inesperado, ainda mais por ter entrado nos Top 10 e o último de Bash do Leandro foi o mais inusitado porque acho nem ele esperaria ganhar com isso, mas quis representar e mandou super bem. Sim, Bash de terminal que vocês usam no Linux como shell. Tem gente que roda Doom numa calculadora, porque não uma aplicação web em Bash? Mas nesse caso, como esperado, Bash não tinha como competir mesmo.

Alguns participaram com mais de uma implementação, como o Leandro que fez em Ruby e Bash, o Lauro Appelt com duas versões em PHP, o Rodrigo Navarro com duas em Rust. Não sei como foi a divulgação do Zanfranchesci, mas ele mandou muito bem. Foi uma participação bem variada e ao meu ver cumpriu exatamente o que eu imaginaria de uma rinha: galos de diferentes tamanhos e cores. Rust e Go na frente, Javascript e Java pra trás. É o que a platéia gostaria de ver. Foi show de bola.

Tendo visto os resultados, se no topo tivesse sido uma hegemonia absoluta de Rust e Go provavelmente eu teria aceitado como todo mundo: sim, talvez nessas restrições de infra, só eles mesmo pra aguentar a carga. Mas como tinha um dotnet ali na terceira posição, e meus parabéns pro André e Albert por isso, mas isso chamou minha atenção: não vejo porque dotnet consegue estar nos Top 10 e outra linguagem não, seja Java ou seja Javascript.

Com essa pulga atrás da orelha, minha saga começa na sexta feira, dia 25 de agosto, eu abri o editor e comecei a fazer minha versão. Tava um pouco enferrujado, então levei acho que umas 2 horas pra implementar em Ruby on Rails mesmo. Levou mais tempo do que deveria porque pensei: “hum, se é um teste de carga em inserção, talvez o postgres seja o gargalo. Depois do HTTP POST, o teste vai checar se inseriu pelo ID. Não tem como deixar só em memória porque são duas instâncias isoladas. Como tem balanceador de carga, o normal vai ser a inserção cair numa instância e a pesquisa cair na outra instância”.

A conclusão imediata que qualquer um chegaria é: vou colocar um cache compartilhado, talvez memcached. Mas como queria já lidar com o que achei que fosse o gargalo, pensei, “vou jogar jobs em fila de redis pra inserir em background”. Então esquece memcache, vou usar redis tanto como cache quanto fila de jobs. Deve caber nas restrições de RAM porque aí o postgres deve trabalhar um pouco menos e eu divido os recursos.

Pelo que avaliei depois, não fui só eu que pensei assim. Várias das versões fizeram a mesma coisa: usaram redis ou nats como cache e fila de jobs assíncronos. É uma coisa que todos nós, que já temos cicatrizes de guerra, fazemos meio sem pensar e isso é um sério problema. Não existem soluções automáticas. Cada caso é um caso e precisa ser medido antes de implementar qualquer truque. Cache ou filas não deixam nada rápido automaticamente em todo caso. Eles também custam recursos. De novo, vamos deixar anotado aqui pra eu explicar no próximo video, como é essa estratégia de usar jobs e filas pra inserir e porque cache não fazia diferença aqui.

Pelo mesmo motivo achei que fosse ver mais gente usando MongoDB, assumindo que muitos imaginam que é mais rápido, mas do total de 90 projetos só 7 tentaram. E mesmo MySQL só 2 tentaram. A maioria esmagadora acreditou no Postgres por padrão. A conclusão: coisas relativamente fáceis, como adicionar caches e filas, todo mundo faz na frente. Coisas mais complicadas, como mudar o paradigma de armazenamento, aí deixamos pra depois. Eu também escolhei ir de Postgres.

Sendo eu criador de conteúdo que, por 20 anos venho evangelizando coisas como uso de Postgres, cache e jobs assíncronos com Redis, me deu uma ponta de dor na consciência. Mesmo aqui no canal já fiz um video chamado “Tornando sua App Web Mais Rápida”, onde faço justamente essas recomendações. Eu tento explicar em que casos usar, mas acho que dá pra explicar isso em mais detalhes, por isso deixei anotado pra voltar nesse assunto no próximo video.

Quando terminei minha versão de Rails, com cache, jobs e tudo mais, rodei o stress test. Já imaginava que poderia não ser rápido, mas sempre tem aquela esperança de “vai que” né? E pra minha decepção não deu mais que uns 15 mil inserts, abaixo ainda das versões de Rails do Lazaro e do Leandro. Foi quando comecei a postar tudo que ia descobrindo no Twitter. Esse foi meu primeiro tweet.

Olha que situação ridícula. Quem gera esses relatórios é a própria ferramenta Gatling, que roda o teste de carga. No próximo video vou mostrar como ele funciona. Nesse gráfico interessa a barrinha verde, olha como tá lá embaixo e a vermelha tá lá em cima. É a quantidade de knockouts ou KOs, de requisições que não conseguiram ser processadas e foram perdidas. Em resumo, só entenda que queremos que verde seja grande e vermelho seja pequeno ou idealmente, zero. Nesse momento eu pensei: “é, talvez essa carga seja muito pesada pra uma linguagem interpretada como Ruby numa infra de docker tão apertada”.

Resolvi baixar a versão do Leandro que usa Ruby mas sem framework pesado como o Rails. E os resultados dele foram bem melhores que os meus, mas ainda assim tem uma barra vermelha considerável de knockouts. Eu conseguia 15 mil inserts e a versão dele batia acima de 30 mil inserts, na minha máquina. Na minha cabeça essa discrepância fazia sentido. Imagino que façam na de vocês também, afinal quanto menos coisa tiver, mais rápido deveria ficar.

Só pra testar os limites, tirei a restrição de 1.5 CPU e 3GB de RAM e configurei o docker compose pra usar 24 CPUs e 20GB de RAM, afinal meu PC aguenta muito mais que isso. Assim a barrinha verde de fato sobe, mas olha que ainda tem uma barrinha vermelha. Eu ainda estou perdendo requisições, e pára pra pensar, isso não faz sentido, em nenhuma linguagem.

Nesse ponto as coisas não estavam fazendo muito sentido. Bacana, eu sei que Rust e Go são rápidos, afinal são compilados e tals, mas se o problema fosse só falta de recurso, na minha máquina, que é absurdamente potente, não deveria estar dando nenhum knockout. Isso foi aumentando a pulga atrás da minha orelha. A conclusão nunca pode ser “a linguagem é uma bosta”, a primeira conclusão sempre tem que ser “eu estou fazendo alguma coisa errada” e ir atrás de descobrir o que.

Resolvi tentar uma outra versão, aproveitar o domingo, dia 27 de agosto. Fazia algum tempo que queria desenferrujar meu Crystal e aprender o framework web chamado Lucky. Ótima desculpa. Deixei a documentação do site aberta de um lado, editor do outro e fui fazendo tentativas. Minha premissa é que Crystal, sendo uma linguagem que compila binário nativo, como Go, deveria ser bem mais rápido que minha versão em Rails. No final gastei o domingo inteiro mais a segunda feira seguinte pra fazer, porque nunca tinha usado Lucky antes.

Vamos anotar isso também pro próximo video: falar um pouco mais das minhas experiências mexendo em linguagens diferentes, mas pra hoje só precisa entender que os criadores do Crystal, o Ary e o Brian, quiseram inventar uma linguagem com sintaxe o mais próximo possível de Ruby, adicionando coisas modernas como inferência de tipos, fibers, channels, mas com perfil de performance similar de Go, e em alguns casos até de Rust.

Foi nesse ponto que fui vendo outros desenvolvedores na comunidade começarem a esmiuçar mais os critérios do ranking, em particular o MrPowerGamerBR. Sendo javeiro ele foi um dos que ficaram sofrendo bullying do povo tirando sarro do Java ter se saído tão mau no ranking. Em vez de só sair dando reply xingando todo mundo, como todo twiteiro faz, ele fez o que um programador de verdade deveria fazer: abrir o código e provar com números.

Ele fez a mesma coisa que eu: começou uma nova versão na linguagem que mais gosta: Kotlin. Pra quem não sabe, Kotlin foi inventado pela JetBrains, a empresa que faz a IDE IntelliJ e o Android Studio. Eu também gosto dela e vou deixar anotado pra comentar a respeito no próximo video. Pra hoje, basta entender que é compatível com Java e tecnicamente oferece a mesma performance.

Dia 28 de agosto ele postou essa versão, que não só melhora a posição de Java, mas iguala na mesma posição Top 1 da versão de Rust do Vinicius Fonseca. Mais do que isso, ele estudou mais a fundo o script de stress test em Gatling e determinou que existe um número máximo de requisições e de inserts possível durante os 3 minutos fixos do teste: 46 mil quinhentos e setenta e seis inserts.

Na verdade vai ser 46 mil quinhentos ou seissentos e alguma coisa porque no script de stress test do Gatling tem essa chamada pra “randomized” que afeta a quantidade de requisições pra criação de registros. Se rodar o teste várias vezes, vai dar números diferentes. Imagino que o Zanfranchesci fez isso de propósito pra adicionar o fator de “sorte” no espírito de uma rinha. Portanto o resultado numérico nunca foi pensado pra ser totalmente justo. E antes que os haters apareçam de novo: eu estou super ok com isso.

Mais do que isso, o MrPowerGamerBR olhou com mais calma a versão de Rust do Vinicius. Sim, ele estava inconformado, e nada é mais motivador do que a força do ódio. Ele notou que surgiam inconsistências esquisitas. Às vezes o total dava 300 a mais do que o máximo. Às vezes dava 500 a mais. Como isso poderia ser possível? Não tem como aparecer requisições do nada. Se existe um máximo e passa do máximo, obviamente existe um bug.

E de fato tem. Não foi de propósito, a gente esquece bugs. Por isso sempre falamos: não é porque uma linguagem compila, não é porque uma linguagem tem checagem de tipos, que não precisa de testes. No código do Vinicius tem uma rotina de aquecimento que insere mais de 500 registros falsos, não sabemos porque, mas depois tem um código que deleta isso. Só que esse código tem uma race condition, uma condição de corrida. Um erro clássico em programação concorrente. Ou seja, às vezes a rotina de limpeza roda antes de terminar de inserir tudo, aí sobra registros e isso polui o total no final.

Não chega a ser um problema, porque mesmo se corrigir esse bug, ainda assim a versão dele atinge o máximo, então sempre seria o primeiro. Mas estudando o stress test, estudando o código do Vinicius e também o do Lucas Weis que fez em Node.js, o MrPowerGamer aprendeu que existem truques que poderiam ser usados que a maioria não pensou. Não foram só eles, mas alguns pensaram além do óbvio e conseguiram resultados melhores.

Em 10 de setembro, o MrPowerGamerBR soltou um video detalhando essas descobertas e recomendo que assistam depois. Eu vou explicar tudo que ele falou e muito mais no próximo video. Uma dessas técnicas foi bulk inserts, a outra técnica foi gerar um índice especial pra pesquisas. Vamos deixar anotado aqui pro próximo video: explicar o que são bulk inserts e explicar como fazer pesquisas fuzzy no postgres e os segredos de ajustes de performance.

Se consertar o bug de race condition do código do Vinicius e se tirar o fator de aleatoriedade do stress test, o ranking fica bem diferente. Como o MrPowerGamer mostra nos seus tweets, o primeiro lugar seria compartilhado entre a versão de Rust do Vinicius, que continua sendo o primeiro, mas a versão de Go do Leonardo Vargas também sobe pra primeiro assim como o 6o lugar da Isadora e o 9o lugar do Navarro também virariam primeiro lugar.

Por causa disso o terceiro lugar de dotnet do André e Albert pula pro segundo lugar. Eles raspam no máximo mas não ultrapassam por meros sessenta e cinco inserts. O quinto lugar do Luiz Picanço em Rust sobe pro terceiro lugar. O Navarro, que tinha feito duas implementações em Rust, também sobe a outra versão, do 10o pra quarto. O oitavo lugar do Jean Rodrigues, em Go, sobe pra quinto lugar. Todo mundo vai subindo no ranking.

Mais ainda: sabendo o número máximo de inserts, se alguma versão ultrapassar, sabemos que tem bug nas validações. E isso aconteceu com o quarto lugar em Lean4 da Sofia e da Gabi, e a que ficou em sétimo lugar do Vinicius Santos, em Rust. Ambos ultrapassam os 48 mil e quinhentos e tanto, mas como tinha aquele fator de aleatoriedade no script, na rodada oficial, passaram batido, mas deveriam ter sido desclassificados. E que fique claro que não foi de propósito, que atire a primeira pedra quem nunca deixou um bug pra trás. Como já expliquei, numa rinha tem fator sorte, e está ok.

O problema é que o script de stress test, e o critério de ranking, não tinham sido divulgados desde o começo e nem testam tudo que está nas instruções. Por exemplo, eles deveriam checar as constraints da DDL do SQL que cria a tabela e índices pra garantir que coisas como apelido tem índice de unicidade, que o campo de data de nascimento era realmente de tipo data e coisas assim. Se fizer um campo de nascimento sendo um varchar, um string, e simplesmente inserir o que vier sem checar, no final vai ter mais registros do que deveria.

Se fosse pra ser mais rígido, deveriam ter implementado uma rotina de testes automatizados em Cypress, por exemplo, uma suite de testes de aceitação que testam todas as regras que estão nas instruções. Assim seria possível ver se a aplicação está devolvendo os códigos de erro quando enviamos dados inválidos. Sem isso, vários bugs passam despercebidos. Fica a dica pra uma próxima rinha. E também pra projetos de verdade: sem testes, tudo compila, tudo roda, mas bugs de validação vão passar despercebidos, em todas as linguagens, compiladas, tipadas, ou não.

Vou repetir: não encarem como uma crítica à rinha, o próprio nome “rinha” é pra ser uma brincadeira. Inclusive, eu acho que se tivesse um teste de aceitação mais rígido assim, teria muito menos participantes e muito mais projetos desclassificados, e meio que perderia a graça.

Mas o que me motivou a gastar tanto tempo nisso é que só olhando o ranking oficial, sem todo o contexto, eu também estava aceitando que Rails ou Java iam ser lentos mesmo e bola pra frente. Mas à medida que fui explorando o que o Vinicius, o Lucas, o Leandro, o MrPowerGamerBR, fizeram nas versões deles, resolvi copiar na minha versão de Crystal, pra tirar a prova dos nove. Não era pra ser difícil. Na minha cabeça, coisa de poucas horas.

Demorei um tanto pra entender o framework Lucky, o Avram que é o ORM que fala com o banco, tive até que abrir o código fonte deles pra entender. Na dúvida, na falta de documentação ou stackoverflow, nunca penso duas vezes e vou ler direto na fonte. Vantagem de usar projetos de código aberto é que o código é aberto, sacaram? É pra ler. E eu fiquei empolgado em tentar implementar o sistema de cache com job assíncrono pra fazer bulk insert como o Vinicius fez em Rust. Sendo Crystal compilado, era pra ter performance similar, né?

Ledo engano. Assim que terminei e fui testar com o Gatling, a decepção. Lembra a barrinha vermelha? Olha ela aqui firme e forte. Minha implementação nem entraria nos Top 20. Meros 20 mil inserts. Só que diferente do que tava pensando sobre Ruby, que é lento por ser interpretado e não tinha o que fazer, ou Java que come muita RAM e não tinha o que fazer, aqui eu fiquei meio puto. A culpa não podia ser do Crystal, nem do Lucky, tinha que ser minha. Eu estava fazendo alguma coisa muito errada. Será que eu sou uma farsa? Será que eu sou tão ruim assim?

Quando gastamos um tempo tentando descobrir um problema num código e depois de “ver tudo”, ou achar que viu tudo, ainda assim não encontrar, eu sempre tenho uma saída que funciona. Olhem neste código de Crystal. Pra passar o stress test, basta devolver HTTP 201 created e um Location válido pra próxima requisição. Até tinha deixado comentado aqui esse código de teste aqui. Posso descomentar essas duas linhas e comentar todas as de baixo. É isso mesmo, na dúvida, tire tudo e faça a resposta mais simples e idiota, devolver uma constante.

Mas esta Location não vai existir, porque se não inserir nada, não existe ninguém com ID número 1. Então, no show.cr, também tinha deixado esta linha comentada, que sequer tenta fazer a pesquisa no banco, só devolve outra constante. Descomento e comento o resto. Pro teste de consulta passar certo, basta devolver HTTP 200 de OK. Finalmente, na pesquisa por termos, mesma coisa, descomento esta linha pra devolver código 200 e comento o resto.

Só fazendo isso o teste de carga já passa. Esta vai ser a velocidade máxima desse app, sem processar nada no banco, manjam? Estou removendo uma das variáveis de incerteza. Rodando o Gatling, só esperar 3 minutos e esse é o resultado. Tudo verde, nenhum vermelho de knockout, e olhem aqui do lado, todos os tempos de resposta da ordem de 1 milissegundo. Na verdade é menos de 1 milissegundo, mas ele arredonda. Esse é o tempo perfeito, porque a aplicação não tá fazendo praticamente nada. Ótimo, isso mostra como o Crystal sozinho é rápido.

Agora posso ir voltando meu código, uma linha de cada vez. Salvo, subo o docker-compose, que vai recompilar a imagem, e rodo o Gatling de novo. Checo e vejo se a diferença no resultado condiz com o código extra que coloquei. Volto, descomento mais uma linha, salvo, reinicio docker-compose, testo de novo, meço. E vou fazendo isso, uma linha de cada vez. E como esperado, nenhuma dessas coisas extras deu nada de estranho.

Até eu chegar nesta linha, a que monta a URL de Location. A única coisa que isso vai fazer é gerar uma linha como esta aqui em cima, um http://localhost etc. Claro, este método faz mais do que só concatenar strings, serve pra montar todo tipo de URL complexa que quiser incluindo encoding de parâmetros e tudo mais. Imagina aquelas URLs gigantes da Amazon. Mas eu nunca esperaria isso causar qualquer diferença significativa.

Na realidade, isso tá até errado. Pensei melhor e Location na realidade só precisa devolver o path, só a parte de “/pessoas/id”. Não precisa do protocolo nem domínio a menos que eu queira redirecionar o cliente consumindo a API pra outro domínio diferente, que não é o caso. Substituindo o método .url pra .path e testando de novo, batata, agora o resultado melhorou.

Eu twitei sobre isso, daí uma conta da comunidade Crystal retwitou e um dos desenvolvedores do framework Lucky, o Jeremy, ficou interessado. Ele foi tão legal que abriu uma issue no projeto. Fui lá explicar esses detalhes. Ele já tinha uma suspeita em mente e me pediu pra testar um ajuste. Este foi meu post no ticket aberto. Quando testei sem o patch dele, tava tomando knockouts, mas colocando o patch, caiu de mais de 600 knockouts pra menos de 10, então tinha alguma regressão de performance mesmo.

Não sei explicar exatamente o motivo ainda. A versão anterior parece que só concatenava strings, e o patch usa tipo um string builder. Concatenar gera duplicatas da string. Um Builder pré-aloca espaço e vai só adicionando as novas partes sem duplicar. É um trade off de CPU por RAM. Eu sei que isso faz alguma diferença, mas não sei ainda explicar porque faria diferença aqui. Mesmo tendo, não deveria ser significativo. Mas de qualquer forma, no número de stress test do Gatling fez muita diferença.

Sem querer, acabei achando um gargalo de performance no framework que levou a um conserto. É assim que a gente acaba contribuindo em projetos open source: sem querer. Mas essa não era a única otimização. Olhando outras versões notei que ninguém tava devolvendo mensagens de erro completas, como “apelido já existe” ou “formato de data inválida”. As instruções só falam que precisa devolver código de status 400 ou 422.

Na minha versão, antes, além do código eu devolvia um JSON com o erro. E processar JSON também custa tempo. Tirei todos os métodos de render ou json e usei só o método “head” que, como o nome diz, devolve só o cabeçalho, o código de erro. É uma coisa besta, que em testes individuais não faria diferença, mas o Gatling manda centena de milhares de requisições. Aí parece que faz diferença.

Mesma coisa logs. O teste não exige logs. No mundo real precisamos ter mensagens de erro gravadas e retornadas pra ficar mais fácil achar bugs e defeitos, mas pra este desafio de performance que só dura 3 minutos, podemos desligar todos os logs e ganhar alguns milissegundos importantes. E fazendo pequenos ajustes assim, o resultado de inserts de Crystal foi subindo. Dos pífios 15 mil inserts, foi pra 30 mil, daí pra quase 40 mil inserts.

Não bati no máximo mas chegando perto dos 40 mil inserts, já foi um salto muito bom. Quando postei esse resultado já era dia 1o de setembro. Ainda me distraí no processo porque queria uma biblioteca pra auxiliar o caching em Redis mas não tinha nenhuma bem feito. Esbarrei num bem antigo chamado Kiwi que ninguém atualizava fazia tempo, então resolvi arrumar e melhorar o código dela. E essa foi minha segunda pequena contribuição open source.

Enquanto isso, em paralelo, o Leandro e o Lazaro, das versões de Ruby mínimo e de Ruby on Rails, continuaram mexendo nas versões deles. O lázaro que, no ranking oficial da rinha, tinha ficado lá na 19a posição com uma faixa de 24 mil inserts, também saiu ajustando as configurações dele e com muito pouco ajuste já tinha conseguido bater os 40 mil inserts também. O Leandro também. Com esses resultados eles já teriam entrado nos Top 10.

O Leandro experimentou mais com as configurações de postgres e de nginx. Muitos de nós achávamos que esses dois componentes não eram tão importantes. Pior, achávamos que eles não ajudavam em nada, então fizemos outra coisa feia que muitos fazem sem pensar: colocamos nginx pra aceitar o máximo de conexões quanto possível aumentando o número de worker connections lá pra cima de 10 mil. E no caso do Postgres a gente configurava os pools de conexão pra dezenas ou centenas de conexões. E isso é um enorme erro.

Vamos anotar pra explicar no próximo video, mas deixa eu tentar ilustrar aqui. Pra ter uma visão na cabeça vamos imaginar uma lanchonete, com vários caixas tirando pedido e mandando pros cozinheiros atrás. Os caixas são nossa aplicação, feitos em qualquer das nossas linguagens. Os cozinheiros são as conexões do banco de dados que é a cozinha.

O nginx é como o tamanho da porta da lanchonete. Se fizer uma porta que aguenta passar 100 mil pessoas de uma só vez, o que acontece? O stress test começa com poucas pessoas, umas 3, mas ao longo de 3 minutos, dispara 600 simultaneamente. Só que essas 600 não são atendidas ao mesmo tempo. Não tem caixa suficiente, daí vai formar um amontoado de gente desordenado.

Do lado da cozinha, o banco de dados, cada cozinheiro extra exige pelo menos uns 3 MB de RAM de espaço e vai consumir CPU. Mas a cozinha, é limitada. Lembra da regra da rinha? No máximo 1.5 CPU. Não adianta aumentar cozinheiro infinitamente, que a cozinha não aguenta. Se falarmos pros caixas tirarem quantos pedidos conseguirem, rapidamente esses pedidos vão ficar empilhados porque não tem cozinheiro suficiente pra atender.

A vontade é aumentar os cozinheiros, o pool de conexões. Digamos, temos duas instâncias da aplicação, os caixas, e cada um vai poder tirar até 100 pedidos de uma só vez. Então 200 pedidos. Mas não tem como ter 400 cozinheiros. Primeiro porque eles ocupam espaço, 3 mega cada já vai dar no mínimo 1.2 gigabytes de RAM. Mas beleza, o estabelecimento inteiro aguenta 3 gigabytes que é o limite imposto pela rinha lembra? Mas não tem fogão suficiente pra cozinhar, a cozinha tá apertada, temos menos de 1 CPU, cada cozinheiro vai demorar mais e mais tempo pra atender cada pedido. Entenderam?

Então o cenário é assim: a porta do estabelecimento permite entrar todo mundo de uma só vez, mil pessoas, 10 mil pessoas, entra tudo. Só tem 2 caixas, duas instâncias. Mesmo tirando pedidos rápido, fica tudo acumulado esperando. Não adianta contratar mais cozinheiro, porque a cozinha é limitada, e quanto mais cozinheiros tentamos colocar, mais cada cozinheiro demora. E enquanto o pedido não é atendido, a pessoa fica lá pendurada na frente do caixa esperando. E assim, vai acumulando centenas de pessoas na lanchonete esperando, até começarem a perder a paciência e ir embora. São as requisições perdidas ou knockouts.

A solução que o Leandro publicou não é intuitiva. Em vez de fazer o nginx aceitar quantas pessoas puder, fazemos diferente: limitamos o tamanho da porta. Digamos, no máximo 1000 pessoas. O NGINX coloca um sistema de senhas do lado de fora e vai deixando entrar só 1000 de cada vez, de forma mais ordenada. É igual num Poupa Tempo ou no seu banco. Pega a senha, senta e espera ser chamado. Agora os caixas atendem menos pessoas de uma vez, mais ordenado, e tiram menos pedidos de uma só vez, digamos, no máximo 50 em vez de 100 ou 200. Esse é o pool de conexões.

E na cozinha, em vez de precisarmos de 300 ou 400 cozinheiros, agora precisamos só de 100. Mas aí não vai andar mais devagar? Não, porque sobra mais espaço na cozinha e cada cozinheiro consegue cozinhar mais rápido. É melhor 100 cozinheiros terminando os pratos em 1 minuto ou 400 cozinheiros levando 10 minutos cada porque tão disputando fogão? Entenderam?

Eu estava cometendo esse erro também. Tava deixando nginx lá em cima, com portão gigante pra suportar 10 mil conexões e compensando com 200 conexões no pool de cada instância do Rails. E pra piorar ainda estava cometendo um erro no postgres. Eu tinha esta linha no docker-compose:

volumes: - ./postgresql.conf:/docker-entrypoint-initdb.d/postgresql.conf

Isso diz pro Docker Compose pegar esse arquivo postgresql.conf do meu diretório local e copiar pra dentro do container de postgres. Mas tava faltando modificar o comando de inicialização pra ter “-c” com o nome desse arquivo. É nesse arquivo que digo pro postgres que ele deve suportar, digamos, um máximo de 400 conexões.

Como não tava carregando o arquivo, subia com o limite padrão de 100 conexões. E isso confunde, porque eu pensava que ia conseguir abrir mais de 100, mas não ia. E não sabia porque. Esse foi o primeiro motivo de porque meus resultados tavam lá na casa dos 15 mil inserts: nesse caso faltava cozinheiro e eu achava que tinha suficiente. Falta de atenção que chama isso. Em vez de consertar no lugar certo, eu ficava tentando compensar em outros lugares, como no NGINX.

No próximo episódio vou explicar como eu poderia ter evitado essa confusão. Vamos deixar anotado aqui. Depois que descobri isso, e li o tweet do Leandro, reconfigurei o nginx pra faixa de 1000 workers de conexão e depois diminuí o número de cozinheiros no pool de conexões pra uns 40. O problema nem era o máximo de conexões, era a compensação excessiva que tava fazendo no NGINX. Um erro levando a outro erro.

À medida que ia diminuindo esses dois números, passava a aumentar a quantidade de inserts no final, a quantidade de pessoas atendidas de fato. Eu tava achando que minha versão de Rails, pelo fato de ter exagerado na solução e enfiado Sidekiq pra jobs, Redis pra fila e cache, ia faltar espaço na cozinha, mas não foi isso, foi questão de gerenciar o fluxo de pessoas.

Limitar a porta e os caixas em vez de escancarar. Lembrem-se disso: atendimento não é tentar atender todo mundo de uma só vez, é atender grupos organizados de cada vez. É uma questão de vazão e fluxo. Isso é essencial em operações. Seja atendimento numa lanchonete, seja numa linha de fábrica, seja num servidor web.

E foi assim que em 3 de setembro, postei o resultado da minha versão de Rails. Faixa de 39 mil inserts, quase batendo os 40 mil que queria. O cenário que descrevi de gerenciar o fluxo de pessoas na lanchonete é um caso clássico, que demonstra que o problema não é a capacidade de atendimento do caixa, ou de cozinhar dos cozinheiros: é de gerenciar o fluxo de requisições, das pessoas ou sessões. É quando sabemos que o problema principal é gerenciar I/O, entrada e saída.

Nós que somos mais experientes já deveríamos ter parado pra pensar nisso primeiro, mas assumimos errado no começo e essa hipótese errada nos fez perder muito tempo. Assumimos que o problema seria a cozinha, o banco de dados. Aí tentamos compensar aumentando número de cozinheiros ou cozinheiros mais rápidos que seriam os caches. Seria o caso se o problema fosse CPU bound, limitação de CPU. Mas na realidade era problema de fluxo, de entrada e saída, no fluxo dos caixas, o problema era I/O bound, como a maioria dos problemas de Web comum.

Uma vez controlado o fluxo, podemos otimizar o caixa pra em vez de só tirar o pedido e ficar esperando de braços cruzados esperando; enquanto o cozinheiro tá ocupado, o caixa pode fazer outras coisas na frente, como receber o pagamento, pegar a bandeja, separar o refrigerante, limpar o balcão. Não precisa esperar o prato chegar pra depois fazer tudo isso, dá pra fazer em paralelo. É pra isso que servem threads ou os async/await de várias linguagens, como Javascript no Node.js.

Nesse ponto eu já tinha visto o MrPowerGamer e outros colaboradores como o Bruno Borges conseguindo subir Kotlin e Java pro mesmo nível do Rust. Já vi o Leandro e o Lazaro subindo Ruby e Rails pra perto do mesmo nível, faixa dos 40 mil inserts. Eu mesmo já tinha conseguido subir Crystal e Rails. Foi quando minha intuição dizia que a maioria dos participantes, se tivessem conhecimento de tudo que a gente descobriu até agora, seriam capazes de chegar perto desses 40 mil inserts ou até bater o máximo dos 46 mil e quinhentos do Rust do Vinicius.

Alguns não gostaram de ouvir isso, porque agora aquele bullying contra o Java ou a fanboyisse de Rust perderiam valor. E como eu detesto dizer uma coisa sem ter provado antes, resolvi fazer a única coisa racional: demonstrar na prática. Ainda era a mesma segunda-feira, 4 de setembro. Escolhi começar aleatoriamente mexendo na versão em Node.js e Express do Lukas Weis que já tava perto do topo, na faixa de 34 mil inserts, em 13o lugar no ranking oficial. Na minha máquina tava dando abaixo disso, uns 27 mil.

A versão dele foi uma das que mexi mais. Como foi um código feito pra competição, ele e muitos outros não se preocuparam em seguir boas práticas, clean code, nem nada disso, só cuspiram código até funcionar e publicaram. Não tem absolutamente nada de errado nisso e não considerem esses códigos como representação do que eles conseguem fazer com mais tempo, em projeto de verdade. Isso tem que ser repetido o tempo todo: código pra competição é diferente de código de verdade.

Mas como eu estava com tempo e não era pra participar da competição, aproveitei pra desenferrujar meu Javascript e fui refatorar um pouco o código pra ficar mais organizado e mais legível. Meu objetivo era totalmente diferente da rinha: dar uma limpada e otimizar o suficiente pra bater pelo menos a faixa dos 40 mil inserts, o que elevaria o projeto pros Top 5 oficiais.

Recomendo que leiam meu pull request com calma, deixei o link na descrição do video abaixo, mas em resumo, depois de organizar o código comecei tirando fora a otimização prematura de usar Redis como cache. Como falei antes, o problema não era a velocidade dos cozinheiros, o postgres. Portanto a solução não era tentar achar cozinheiro mais rápido, um Redis. Com a configuração adequada do fluxo de nginx, do pool por postgres, dividindo CPU e RAM melhor no Docker Compose, já resolvia. Arranquei o Redis fora, daí teria mais recursos pro postgres.

Esse cache, além de tudo, não estava sendo efetivo porque o Lucas tentava cachear os resultados do endpoint de pesquisa por termos, só que o stress test manda pesquisas com termos aleatórios, raramente repetidos, então o cache nunca ia ajudar, porque toda pesquisa ia ser nova e não ia ter o resultado no cache. Portanto cache na pesquisa de termos era inútil, só um peso a mais de gravar no cache.

Além disso, no endpoint de criar novo registro, ele deixava o banco de dados criar a chave primária, daí recebia de volta no final e só aí gravava no cache. Isso tem que acontecer um atrás do outro, não dá pra ser assíncrono. Adicionar o valor no cache só aumentava o tempo da requisição. Mais uma vez, era um trabalho extra sem benefício.

No endpoint seguinte, de pesquisar pessoa direto por ID, ele buscava no cache. Mas a pesquisa por chave primária no postgres é igualmente rápido. De novo, o cache não fazia diferença. Só faria sentido se primeiro gerar a chave primária, com uma biblioteca de UUID na aplicação, e mandar o insert pro banco já com essa ID e em paralelo já mandar gravar no cache também com a mesma ID. Como não precisa esperar o banco devolver uma nova ID, não precisamos esperar pra gravar no cache, entenderam? É uma das vantagens de usar um gerador de chaves primárias externo ao banco. Muito iniciante não sabe que não é obrigatório deixar o banco responsável por IDs.

O Lucas também tava devolvendo códigos de erro HTTP junto com mensagens em JSON descrevendo o erro, mas a rinha não se incomodava com isso, então só arranquei fora. O stress test não liga pra mensagem, só quer respostas rápidas. No mundo real, o certo é dar respostas completas, porque sem logs bem descritos depois fica difícil achar bugs e problemas. Novamente, é uma otimização que só serve pra uma competição.

O Node.js tem recurso de cluster, subir forks do processo pra escalar melhor. Mesma coisa que Rails também faz. O Lucas parece que experimentou, mas desistiu. Eu ia tirar fora, mas voltei e passei a usar pra tentar distribuir um pouco mais a carga. Ter um reactor com corrotinas assíncronas e conseguir ter concorrência é diferente de ter paralelismo e o ideal é ter as duas coisas. Eu explico isso no video de concorrência e paralelismo e no próximo video talvez eu tente explicar melhor neste contexto. Vamos deixar anotado.

A parte que possivelmente pesou mais na versão do Lucas foi o endpoint de pesquisa que faz select LIKE na tabela. Muitos erraram nisso: precisa fazer select LIKE nas colunas apelido, nome e stack, então é apelido LIKE termo OR nome LIKE termo OR stack like termo, e esse é o pior jeito de fazer select. O melhor jeito é pré-criar um único campo com as três colunas concatenados durante o insert. Daí fazer um índice usando GIST com a extensão de trigrams. Alguns tentaram GIN, mas pra este desafio o melhor era GIST. Já tínhamos anotado, mas vou explicar isso no próximo video.

A segunda coisa foram as validações. Validar os dados antes de inserir no banco costuma ser mais rápido do que tentar inserir e deixar o banco devolver erro. Por exemplo, que a data de nascimento é inválido, tipo mês 13 ou dia 31 em fevereiro. Podemos só checar se a string tem o formato de ano, tracinho, mês, tracinho dia, no mínimo. Ou tentar converter essa string num objeto válido de data pra garantir. Eu não medi exatamente esse ponto, mas o Lucas usou a biblioteca moment.js, que antigamente já foi bem popular mas acho que é considerada meio obsoleta.

O jeito mais popular hoje é usar outra biblioteca, a date-fns ou simplesmente usar o construtor da classe Date do Javascript nativo. Eu comecei tentando usar o date-fns mas achei mais fácil só checar se o parse da string pra um new Date is not a number (isNaN). Com todas essas mexidas fui mexer no Docker Compose. Ele tava subindo 3 instâncias de Node no Docker, mas como reativei o código de Node Cluster, desci pra 2, cada uma com 1 fork extra, totalizando 4 processos.

Diminuindo a carga do código de cache, que não tava servindo pra nada. Melhorando as pesquisas por termo. Diminuindo a carga do código de validação. Ou seja, fazendo nossos caixas trabalhar menos, em seguida era o problema de diminuir a montanha de gente que o nginx tava deixando entrar tudo de uma só vez. Diminuí a quantidade de workers do nginx dos absurdos 20 mil, pra 10 mil até 1024. Notei que uns 1000 é ideal pra maioria das aplicações. Muitos até menos.

Fazendo isso os caixas trabalham de forma mais organizada e eficiente, precisando de menos cozinheiros, menos conexões de banco no pool. O Lucas tinha configurado com 200, mas agora dava pra descer pra uns 45, talvez até menos. E fazendo tudo isso, essa versão de Node.js saiu da faixa de 27 mil inserts, na minha máquina, ou 34 mil que conseguiu na máquina dos organizadores da rinha, e pulou pra faixa dos 40 mil também. Do meu ponto de vista, foi uma mudança significativa. E cimentou na minha cabeça que dava pra fazer a mesma coisa pra outras versões.

Desculpas ao Lucas por ter pego ele pra Judas, mas não entendam errado. Vários outros, incluindo eu mesmo, cometemos os mesmos erros. Só aproveitei pra explicar mais na versão dele pra não me repetir em todos os próximos. Enfim, ainda no dia 4 de setembro, depois de atingir os 40 mil inserts com o Node.js, resolvi mexer em outro velho conhecido, Elixir. Na minha cabeça não fazia sentido Elixir ter se saído abaixo dos Top 10. Mas eu fiquei surpreso com um problema: essa versão do Gabriel Oliveira se recusava a carregar na minha máquina!

Como chegou a figurar no ranking oficial, significa que o Zan conseguiu rodar pra avaliar. Portanto, se a versão é a mesma (e tem que ser, é a mesma imagem de Docker), por exclusão, tem que ser alguma coisa na minha máquina. Mas toda vez que eu tentava subir o Docker Compose, via as instâncias da app crasheando sem nenhuma mensagem de erro, simplesmente morriam. Puf, zero, nada.

Sem entender o motivo, fiz um teste: mudei o comando do docker compose pra só subir um “sleep infinity” do Linux. Todo mundo conhece o conceito de sleep, certo? Pausa o processamento pelo tempo que mandar. Linux suporta infinity, daí fica pausado pra sempre, como um loop infinito, while true da vida. Fazendo isso o container fica de pé pra eu poder fuçar. Daí é possível usar o comando docker-compose exec pra abrir um bash dentro do container.

De dentro, tentei executar o binário do app na mão, e de fato, crasheava. Achei isso muito estranho, aí me ocorreu, será que o app é muito pesado? Vou tentar carregar o iex que é só a linha de comando do REPL do Elixir, sem carregar nada da aplicação. E crasheava também. Estranhíssimo. Vamos pular o Elixir e carregar direto só o Erlang, o comando “erl”. E crasheava! Bizarro! A sensação que eu fiquei é que os programas pediam mais recurso do que a máquina conseguia entregar e crasheavam, como falta de RAM.

Resolvi editar o arquivo de docker compose pra tirar a limitação da rinha de CPU e RAM. Tentando rodar de novo, aí subia! Por alguma razão tava faltando RAM. Abri o HTOP pra ver quanto de RAM tava usando e era um absurdo, coisa de quase 1 gigabyte e meio! Fiquei bem confuso. Como fazia tempo que não mexia com Elixir fiquei pensando, “ué, será que nos últimos anos eles enfiaram tanta coisa no Elixir que agora precisa de mais memória que uma JVM do Java?”. É confuso porque quem já mexeu com web de Java, com Spring e tudo, sabe que 1GB de RAM não é fora do comum. Mas não esperava isso do Elixir.

Eu tava quase jogando a toalha, então resolvi reportar no meu Twitter. Todo mundo achou estranho, mas o próprio Gabriel conseguiu achar a resposta, era o limite máximo de porta que o Erlang detectava no meu sistema. Em Erlang e portanto também em Elixir, portas são usadas pra se conectar com o mundo externo. Por exemplo, pra ler do standard input, STDIN, ou escrever no standard output, STDOUT, são portas. Pra abrir arquivos, pra receber conexões de rede, são portas.

Erlang pré-aloca no mínimo 1024 portas. Pra determinar o máximo, podemos abrir o shell “erl” e rodar o comando erlang:system_info(port_limit). E olha só: meu sistema devolve mais de 1 milhão de portas. Daí tem o detalhe que ainda não entendi: na aplicação em Elixir parece que tenta pré-alocar esse máximo sei lá porque, em vez de ir só alocando se precisar. Daí dá mais de 1 gigabyte de RAM. E se limito dentro das restrições da rinha, iria faltar memória no container, crasheando na inicialização.

Felizmente, com uma simples variável de ambiente ERL_MAX_PORTS, podemos colocar um número mais sano, tipo 2048 ou algo assim. Limitando de 1 milhão pra 2 mil, fez uma puta diferença, agora o app sobe, consumindo na faixa de 160 megabytes por instância, que é bem mais razoável e próximo até de versões como Rails ou Node.

Isso é um problema que só aconteceu no meu sistema porque a configuração de Arch Linux é mais agressiva nos limites do que um Debian ou Ubuntu, que são mais conservadores. Sendo mais específico, isso é limite de file descriptors, ulimit do sistema, depois pesquisem sobre isso. De qualquer forma, a versão Elixir do Gabriel eu gostei bastante porque usou características exclusivas de Elixir. Ele fez as duas instâncias rodando em containers diferentes se conectarem num cluster.

Clusters saem de graça em Erlang, porque a máquina virtual já trás toda a infraestrutura pronta. É fácil de usar. Não serve pra tudo, mas quando precisa é bem útil. Lembram como falei que não valia a pena usar um cache como Redis, primeiro porque o postgres já era rápido o suficiente, mas também porque subir um container de Redis significa dar menos recursos pro postgres? Com o recurso de cluster do Erlang, dá pra ter um cache compartilhado entre as duas instâncias, sem precisar de um Redis entre os dois.

O app em Elixir consegue consultar na memória da primeira instância, e a segunda instância no outro container, consegue pedir pra primeira instância porque estão no mesmo cluster. Assim não precisam de uma memória externa na forma de um Redis da vida. À primeira vista isso parece mais esperto, mas como já disse antes, o problema não é o postgres, e adicionar um sistema de cache só adiciona peso desnecessário.

Mesmo assim esta versão, ajustando só nginx e o pool de conexões, consegue passar dos 41 mil inserts e entra nos Top 5. Mas tem um porém, além do cache, as instâncias faziam chamadas RPC entre eles, ou seja a 1a instância podia pedir pra 2a instância gravar ou pesquisar no banco e vice versa. Isso eu achei desnecessário e adiciona uma comunicação externa via rede pra toda chamada.

Eu não tive tempo de testar, acho que se arrancar fora essas chamadas remotas, o código de cache e dar mais recursos pro postgres, talvez seja possível conseguir um resultado melhor. Mesmo assim eu esperava que Elixir conseguisse um número maior. De todas as versões que eu mexi, essa ainda foi a que performou um pouco pior. Então tem espaço pra simplificar mais o código. Elixir certamente consegue mais. Estão notando o padrão: em vez de adicionar coisa, estou tirando coisas e com isso deixando mais rápido. Por isso sempre repetimos tanto que otimização prematura é a raíz de todo o mal.

Com a versão Elixir do Gabriel batendo acima dos 40 mil inserts, resolvi procurar uma versão em Go Lang. E escolhi um dos que ficou mais embaixo no ranking. A do Luan ficou em 23o lugar com só 21 mil inserts. Assim como Elixir, não tem porque Go ficar lá embaixo e isso já se provou porque pelo menos 3 versões tinham alcançado os Top 10.

Fiz pequenos ajustes no docker compose, pra dar um pouco menos de CPU pras instâncias de app, assumindo que Go sem nenhum framework iria precisar de menos recursos que Elixir. Daí podemos aumentar CPU do postgres. Teve duas modificações de código que quis mexer. Primeiro, fazer erros devolverem só os códigos de erro 400 ou 422 de HTTP sem mensagens de erro. É pouca coisa mas já faz um pouco de diferença.

A segunda coisa é que ele tava usando Regular Expressions pra validar o formato da data de nascimento. Na real, acho que isso é meio besteira, mas como Regex costuma ser mais lento do que dar split na string e checar cada componente, troquei também. Acho que nenhuma dessas duas coisas faz muita diferença no final. O que deu diferença sim foi o que já falei antes. Primeiro, diminuir o tamanho da porta de entrada: diminuir os 10 mil workers de nginx pra 1024. E aumentar o pool de conexões, embora isso também nem tenha sido necessário.

Só de limitar e controlar o fluxo de entrada de requisições, literalmente uma linha, já disparou o resultado da faixa de 29 mil inserts pra 34 mil. Não chegou nos 40 mil que eu queria, mas por hora resolvi subir meu pull request, que também tem link na descrição abaixo, e pular pra outra coisa. Só pra terminar esse dia 4 de setembro, fui dar uma fuçada na tal versão em dotnet do André e Albert que alcançaram terceiro lugar.

Como muitos outros, eles também optaram por fazer uma versão codificada de forma rápida, sem muitas boas práticas, então ficou bem verbose, tudo super longo. A curiosidade é que como muitos, também optaram por implementar um cache, mas diferente da maioria, em vez de Redis escolheram usar Nats.

Nats deveria ser mais usado, e parece que povo de Dotnet usa mais. É uma alternativa até mais confiável do que Redis pras funções de cache ou como uma fila de jobs simples. Em cima do nats, usaram os recursos de async do C# com channels pra fazer a implementação de bulk insert. E com isso conseguiram atingir quase o máximo, 44 mil inserts. Esta versão não mexi em nada, só fucei e tweetei a respeito.

No dia seguinte, dia 5 de setembro, me sugeriram fuçar alguma versão de PHP então puxei pra rodar a versão do Lauro Appelt que ficou em 17o lugar no ranking, com meros 25 mil inserts. Fazia muitos anos que não mexia com PHP, então precisei da ajuda dos universitários.

Pacotes de PHP hoje em dia se instalam com Composer, que é parecido com NPM de Javascript ou Cargo de Rust. Foram-se os dias de baixar zip de sites como Freshmeat ou SourceForge. Mas PHP ainda tem o conceito de extensions, que como o nome diz, carrega junto com o PHP em si, e modificam as estruturas internas da linguagem.

Antigamente lembro de usar PEAR que eram as extensions em C, mas hoje parece que são PECL. Nesse estágio precisava carregar essa nova extension chamada Swoole, que adiciona funcionalidades de corrotinas e modelo de I/O não-bloqueante, o que transforma o PHP em algo parecido com Node.js. Basta baixar, compilar e instalar a extension e editar o php.ini pra carregar ela na inicialização.

Depois de bater cabeça pra entender isso e instalar os pacotes, pude rodar essa versão do Lauro, que ele implementou com o framework Hyperf. PHP 7 tem uma sintaxe bem mais moderna do que o antigo PHP 3 que eu usava, mais de 20 anos atrás. Mudou bastante coisa, tá bem mais legível, bem mais organizado. E o Lauro foi um dos poucos que deu uma caprichada e deixou tudo fácil de entender e legível. Recomendo darem uma olhada.

Nessa versão também não mexi em nada no código, só parei pra entender, desenferrujar um pouco do meu PHP. A única coisa que ajustei foi o pool de conexões. Aqui, ao contrário da maioria, o Lauro foi super conservador e limitou o pool de conexões com 10 conexões, muito pouco. Resolvi soltar tudo e jogar lá pra cima, em 500, que é exagerado. Mas fazendo isso e rodando o stress test, essa versão também subiu pra quase 40 mil inserts, o que também o colocaria lá pelos Top 5.

Por causa disso já me dei por satisfeito por enquanto, já que queria pular pra ver outras versões. Nesse dia não mexi em muita coisa. Dei uma pausa e a noite resolvi que ia mexer mais no dia seguinte, mas acabei não conseguindo dormir. Levantei e voltei pro PC. Queria mexer em pelo menos mais uma versão, a de Python. Escolhi o 21o lugar do Ian Cambrea, com menos de 24 mil inserts.

Ele não fez em Django, que seria o mais comum pra web em geral, nem em FastAPI que parece ser o mais comum pra APIs. Ele escolheu Sanic, que é um framework que eu não conhecia. A única modificação significativa que eu fiz foi notar que ele também resolveu usar Redis pra cache, mas não implementou um pool de conexões pro Redis. Tava usando uma única conexão pra tudo.

Não consigo afirmar que era só isso, mas testando na minha máquina como os outros, o resultado bateu nos 40 mil inserts também. De curiosidade, essa foi a única versão que eu vi que usou NGINX diferente. Normalmente a gente configura NGINX pra fazer balanceamento de carga usando protocolo HTTP, portanto usando rede TCP por baixo, fazendo proxy reverso pra outro servidor web HTTP atrás, no caso o Sanic.

Mas NGINX, e outros serviços que rodam em Linux, como o próprio Postgres, que também costumamos conectar via TCP na porta 5432, suportam conexões usando UNIX Sockets. Se tudo for rodar na mesma máquina, que não é comum no mundo real, não tem necessidade de usar rede TCP/IP. Tá tudo na mesma máquina. Podemos fazer um processo se comunicar diretamente com outro processo usando IPC ou inter-process communication, e um dos jeitos de fazer isso é via UNIX Sockets.

De forma resumida, sabe quando fazemos tipo um cat num arquivo, adicionamos um Pipe, e rodamos um grep do outro lado pra filtrar o conteúdo do arquivo? Isso é um jeito do processo grep se comunicar com o processo cat via esse pipe que liga o stdout do cat ao stdin do grep. É mais ou menos isso que acontece com o NGINX usando unix sockets pra falar com as instâncias de Sanic. Basta todos enxergarem os mesmos arquivos .sock. Depois dêem uma olhada no repositório do Ian pra ver como ele fez.

Como a versão de Python também foi fácil e não exigiu nenhum trabalho meu além de ajustes triviais, fui dormir e no dia seguinte resolvi olhar pro topo da lista de novo. Fiquei curioso com isso de Lean4 que a Sofia e a Gabi usaram e alcançaram o Top 4 do ranking. Nunca tinha ouvido falar nessa linguagem, mas o que vi foi impressionante.

Lean4 é uma linguagem experimental ainda, longe de ser 1.0, criada na Microsoft Research pelo brasileiro Leonardo de Moura em 2013. O objetivo dele foi criar uma linguagem pra ser fácil criar provas de teoremas. É uma linguagem mais focada em formalidades matemáticas, inspirada em linguagens funcionais como Haskell ou OCaML. Ele tem um cheiro de dialeto de linguagem da família ML. Se curte linguagens funcionais e formalidade matemática, essa pode ser uma boa alternativa.

Mais impressionante foi a dupla Algebraic, as autoras do projeto da rinha, a Sofia que tem só 21 anos e a Gabi que tem só 17 ou 18 anos. Como falei desde o começo, implementar esses endpoints de API, em si, não é nenhum desafio. Mas neste caso foi. Lean4 é experimental, comunidade pequena, e quase nada pra Web, porque nunca foi o foco. Ela é quase toda focada em teoremas matemáticos e não criar APIs pra Web.

Pra fazer APIs, elas precisavam de um parser de JSON, já que na regra da rinha, o stress test ia mandar milhares de requisições com JSON. Mas não tinha uma biblioteca de JSON, então a Sofia fez um do zero. Quando se recebe as requisições HTTP, algumas contendo esses JSON, precisa conseguir parsear o pacote. Existe já parser de HTTP em C, que todo mundo usa em várias linguagens, mas pra Lean4 não tinha. Então a sofia fez um wrapper em FFI pra integrar.

Pra implementar a aplicação em si, ela queria usar algum framework web, como em Node você tem Express ou em Java tem Spring. Mas em Lean4 não tinha, então a Sofia fez um pequeno do zero. Além disso, pra rodar uma aplicação web, duh, precisa de um servidor Web. Sabe? Tipo Node.js, tipo um web2py, ou um Tomcat. E claro, também não tinha. E claro, a Sofia fez um. Ou seja, esse foi aquele caso de “não sabendo que era impossível, foi lá e fez”.

Só esse esforço já merece uma menção honrosa, porque eu acho que ninguém teve metade do trabalho que elas tiveram. Mais foda ainda porque essa versão foi uma das mais performáticas. Também é igualmente impressionante que uma linguagem desconhecida, experimental e que provavelmente ninguém nunca usou pra web, seja tão performática.

O criador, Leonardo, focou em fazer uma linguagem com objetivo de provar teoremas e verificação formal em vez de performance bruta. Mesmo assim foi bem sucedido em performance. Não deixem de olhar o código da rinha no repositório da Gabi, além das bibliotecas no repositório da Sofia. Links abaixo.

No video de análise do MrPowerGamerBR, onde ele descobriu os limites do stress test e das regras da rinha, também conseguiu identificar que algumas das versões nos Top 10 tinham bugs, como de validação, que acabaram deixando passar inserts que não deveriam, em particular por falta de validação de data.

Essa versão em Lean4 tinha esse tipo de bug. Elas esqueceram de colocar validação da data de nascimento. Tudo bem, mesmo com a validação, a versão delas ainda ia ficar entre os Top 10, por pouco. Então aproveitei pra tentar molhar meus dedos em Lean4 pela primeira vez e implementei uma validação simples. Foi o código menos intuitivo que eu fiz em muito tempo. Acredito que quem for mais experiente em linguagens como Haskell ou F# devem conseguir entender mais fácil.

Tinha outro pequeno bugzinho na hora de gerar a URL pro cabeçalho de Location depois de inserir o registro no banco, então corrigi isso também. De qualquer forma, vejam o link dos meus pull requests na seção de links abaixo. No fim desse dia postei um tweet de resumo até este momento com tudo que descobri. Neste estágio da minha saga, já tinha conseguido fazer minha própria versão de Rails e de Crystal bater os 40 mil inserts, ajustei a versão em Node do Lucas, Elixir do Gabriel, Go do Luan, PHP do Lauro, Python do Ian, além dos ajustes no Lean da Sofia e Gabi.

Chegamos no dia 6 de setembro, véspera de feriado prolongado de Independência e que eu tinha planejado viajar… Depois de ter batido cabeça com Lean4, resolvi que queria bater cabeça com outra linguagem que nunca mexi antes. Tentei fuçar Zig, mas achei que tava experimental demais, o ferramental super instável, na verdade, tudo instável. Coisas da versão 0.10.0 quebram na 0.12.0. Pra uma experiência de um dia só, não ia compensar. Eu acho que é uma das linguagens mais promissoras, tanto que foi usada pra fazer o novo Bun, mas vou deixar pra outra ocasião.

Então lembrei que sempre quis tentar a linguagem Nim, outra que é compilada como Go, tem uma sintaxe inspirada em Python, existe já faz alguns anos então assumi que seria mais estável e melhor documentada do que Zig. Provavelmente fácil de chegar numa boa performance, assim como consegui com Crystal. Ledo engano. Apanhei bastante, a começar pela falta de documentação.

Não ajudou nada que a biblioteca assíncrona pra Postgres se chama asyncpg, que é o mesmo nome da de Python. Quando pesquisa no Google, adivinha quem aparece primeiro? Pra piorar, a linguagem e suas bibliotecas usam e abusam de macros, que modificam a sintaxe da linguagem. Sem ter uma boa experiência, foi confuso diferenciar o que era da linguagem e o que eram macros. As mensagens de erro do compilador confundiam mais do que ajudavam. Reclamações de amador, claro, não estou dizendo que é um defeito, mas é uma curva de aprendizado maior pra iniciantes.

Recursos de corrotinas, tipos como Option, pareciam ainda meio experimentais, com hacks pra funcionar certas sintaxes. Escolhi o framework web Jesper ,que parece um Sinatra de Ruby. Apanhei um bocado mas consegui implementar os 4 endpoints numa manhã. Só que contrário às minhas expectativas, o resultado foi pífio, uma verdadeira droga mesmo.

Já tentei compilar com opção speed, nada. Já tentei compilar com modo multithread, nada. Suspeito que a biblioteca de async pool que estou usando é imatura e vaza conexões. Depois preciso investigar isso melhor. Mesmo aumentando pool pra 100 ou mais, nem chega até o fim do stress test, abre o bico muito antes. Male male insere 2000 inserts. Isso deixaria esta versão lá no fim do ranking oficial, só ganhando da versão de brincadeira feita em Bash do Leandro.

A probabilidade maior é que eu, sendo amador, posso ter feito erros de iniciantes e por isso foi ruim. Mas na maioria das linguagens mais maduras, um iniciante teria dificuldade de deixar tão lento assim, mesmo se fosse num Javascript. Se tiver alguém assistindo que tem experiência com Nim, não deixe de dar uma olhada no meu pull request linkado abaixo pra ver se descobre o problema, mas no estado que tá agora, eu não recomendaria usar Nim pra uma aplicação web, mesmo se fosse bem simples. Se for pra usar uma linguagem imatura com bibliotecas instáveis e mau testadas, é melhor ir direto pra Zig ou V Lang que são mais modernas.

Apesar dessa tentativa frustrada, outros desenvolvedores acompanhando minha saga começaram a se mexer pra fazer versões melhores. Por exemplo, nesse mesmo dia vi o Junior Leão mostrando uma outra versão em Java com Spring Boot, usando Redis pra cache com JDBC direto e também conseguiu alcançar os 40 mil inserts.

Outra tentativa bem sucedida foi do Carlos Silva, conhecido como Insalubre, que tinha participado com uma versão em V Lang, mas tinha algum problema e ele foi desclassificado, então nem entrou no ranking oficial. V Lang é uma nova linguagem com cara de Go. Ele se inspirou nas discussões de técnicas que ficamos fazendo no Twitter, consertou a versão dele, e atingiu os 46 mil inserts.

O Leandro continuou mexendo na sua versão de Ruby e neste dia reportou que conseguiu bater os 46 mil inserts. Ele foi quem mais testou a hipótese de diminuir a porta de entrada do NGINX e controlar a vazão de requisições. Com só 256 workers do NGINX e 30 conexões totais de Postgres no pool, conseguiu alcançar os 46 mil inserts, demonstrando que nem o nginx e nem o postgres nunca foram os gargalos desta rinha. Veja o fio do tweet dele nos links abaixo pra mais detalhes.

No fim do dia resumi num tweet todas as técnicas que descobrimos até agora. Por exemplo, validação pode consumir tempo precioso, quanto mais otimizar, melhor. Não precisa devolver mensagens de erro elaboradas, muito menos em JSON, só o cabeçalho HTTP com o código de erro tá otimo e vai ser mais rápido. O postgres não é o gargalo, não com essa quantidade mixuruca de dados. 50 mil inserts não é nem um peido. Por isso não precisa tentar otimizar prematuramente com Redis pra cache.

Linguagens que escalam com threads ou forks precisam de mais conexões com o banco. Um exclusivo pra cada thread. Então tem que dar um pouco mais de RAM pro banco subir essas conexões extras. Cada conexão de Postgres custa caro, uns 2 a 3 megabytes, porque são forks. Então 100 conexões exigem no mínimo 300 megabytes. E ainda tem que sobrar RAM pra processar as queries. Ou seja, menos de 500 megabytes é inviável. Linguagens com suporte a fibers exigem um pouco menos conexões, porque compartilham a mesma conexão na mesma thread. De novo, tá anotado já pra eu explicar isso no próximo episódio.

Uma coisa que eu e o MrPowerGamerBR vimos na implementação vencedora em Rust do Vinicius Fonseca, é que ele entendeu mas nem todo mundo pensou na forma correta de lidar com searches fuzzy do Postgres. Também já anotamos pra eu explicar no próximo episódio. O Vinicius fez certinho. Ao tornar o search mais eficiente, sobra mais CPU pro postgres conseguir lidar com os inserts.

E por fim, o mais importante, é lembrar do conceito de controlar a vazão na entrada, diminuindo quantidade de workers de NGINX. Esse nunca foi o gargalo, com meio CPU e quase nada de RAM, aguenta todas as requisições do stress test sem reclamar. Alguns não gostam de NGINX porque algo usando FastHTTP de Go é muito mais eficiente, mas nesta rinha o NGINX nem chega perto de ser gargalo.

Colocando 0.15 CPU e uns 200 megabytes pro NGINX, perto de 0.75 CPU e pelo menos 1.2 GB de RAM pro Postgres, daria pra colocar um pool exagerado de mais de 200 conexões, embora os 100 padrão no total seja suficiente pra maioria. O que sobrar, dá pra dividir com sua aplicação, ou seja, 0.3 CPU e até 0.8 GB de RAM pra cada instância. Depende se sua aplicação for mais pesada que isso, como as versões em Java ou Rails ou mesmo Node, aí precisa ir tirando e testando de 0.05 em 0.05 do postgres, dando pra aplicação e medindo pra ver os limites.

E chegamos no feriadão de 7 de setembro. Apesar de eu estar coçando pra investigar mais códigos da rinha, tive que parar por alguns dias. Eu corri pra tentar desvendar tudo antes do feriado, e apesar de ter conseguido ajustar várias versões pra chegar nos 40 mil inserts, ainda tava coçando a cabeça com o elusivo máximo de 46 mil. Tinha algumas suspeitas pra testar quando voltasse, mas fui viajar com essa pulga atrás da orelha ainda.

Já tinha planejado de levar minha namorada pra conhecer Gramado, no Rio Grande do Sul. Nos divertimos bastante apesar de estar super cheio e com tempo meio duvidoso. Visitamos diversas atrações, como a Super Carros, onde pude fazer test driver de Ferrari e Nissam GT-R! Mas, este video não é de turismo. Quem me acompanhou no Instagram viu as stories em tempo real. Se não acompanhou e ficou curioso, deixei um destaque lá. Procurem o link na descrição abaixo.

Mesmo durante o feriado, vários desenvolvedores continuaram empenhados em desvendar os mistérios da Rinha e na sexta feira, dia 8 de setembro, outro dos participantes, o Vinicius Ferraz, fez umaa descoberta muito importante. Ele twitou assim: “você que participou da rinha, tomou um j.i.IOException: Premature Close? Tunou o banco, sua app, o nginx e não conseguiu resolver 100%? Sabe onde poderia estar o problema? Na rede do docker. Como resolver? network_mode: host em todos os serviços.

Caraca!!! Nas primeiras versões que mexi, na minha em Rails, em Crystal, a de Node, onde gastei mais horas, chegava perto dos 40 mil, 39 mil, o comportamento ficava estranho. Olhando no gráfico não tinha muita explicação. Ficava esse tremido esquisito no fim do gráfico, como se estivesse tentando ultrapassar um teto invisível.

Mesmo nas versões vencedoras, como o Rust do Vinicius, dava pra ver um tremido menor no fim. Mas ele conseguia ir aguentar até o fim. Independente da versão, mais cedo ou mais tarde, aparecia isso. Eram requisições que começavam a se perder! Não perdia tudo nos inserts, mas principalmente nas pesquisas por termo, até em pesquisas inválidas, o que era mais absurdo, já que só checa se o parâmetro de termo não existe e devolve cabeçalho de erro. Esse endpoint nunca tinha que dar knockout, porque não processa nada.

Como teve aquele caso do Elixir do Gabriel, que descobrimos que meu sistema Manjaro baseado em ArchLinux tem ulimit maior e por isso afetava o uso de memória do Erlang, imaginei que tinha alguma coisa na minha infra que também pudesse estar afetando isso. Cheguei a suspeitar do Podman, que eu estava usando no lugar do Docker. Mas não deu tempo pra investigar isso porque chegou o feriadão e fui obrigado a parar.

E era mesmo no Docker, e o mesmo problema acontece no Podman. Explicando. Quando subimos container de Docker, não é uma máquina virtual. Eu expliquei isso em detalhes no meu video de Docker, então assistam lá depois. O processo roda nativo no sistema operacional host. Só que a infra do RunC de Linux, que é a base do Docker e do Podman, nos dá opção de enganar o processo rodando. Uma dessas formas é quando mapeamos volumes. Dizemos que um diretório dentro do container na verdade mapeia pra outro diretório do lado de fora, no host.

O mesmo vale pra rede. Digamos que eu queira subir vários postgres na mesma máquina. Não ia conseguir, porque o primeiro ia subir e dar bind na porta 5432. O segundo ia tentar dar bind na mesma porta, mas como já tá ocupado, ia falhar. Com containers, cada processo consegue dar bind na porta 5432 de uma rede falsa, virtual. Ele acha que tá sozinho na máquina. Daí podemos mapear a porta interna do container pra uma porta na rede de verdade do lado de fora.

Pra isso precisamos de uma ponte de rede, um “bridge”, que é o modo de rede ou network mode padrão. Mas podemos escolher fazer bind direto na porta da rede de verdade, do host. É isso que o Vinicius sugeriu: network_mode: host. Ao não usar o modo ponte, estamos retirando o gargalo da tradução de tráfego da rede virtual pra rede de verdade. Isso custa recursos, é mais pesado. Não existe almoço grátis. Tudo custa alguma coisa. O que a gente não sabia é que era pesado a ponto de afetar esse stress test.

Sem querer, esse era o elo perdido da rinha, a última peça que faltava. E só pra me deixar ainda mais ansioso pra voltar do feriadão, no domingo dia 10 o desenvolvedor Reinaldo resolveu fazer uma versão nova em Java usando Quarkus, Reactive e VertX seguindo as dicas do Bruno Borges e Vinicius Ferraz. Depois vejam o repositório dele, o usuário é zsantana. Ele twitou como conseguiu uma versão que atingia mais de 51 mil inserts.

Mas já falamos que o máximo é 46 mil e quinhentos, portanto certamente esta versão tem bug de validações, como eu demonstrei na versão em Lean4 da Sofia. Mais importante, esta versão em Java atingia um critério que a rinha não media mas que pra mim era importante e eu passei os últimos dias tentando entender porque ninguém atingia: Zero Knockouts. Não perder nenhuma requisição. Esse é o ponto onde vencemos o stress test.

Entenderam? Até este momento a noção era que o stress test era tão pesado que nenhuma aplicação conseguia segurar tudo e eventualmente ia perder algumas requisições. Alguns mais, alguns menos. Isso é comum em testes de carga. Mas assim como nginx e postgres nunca foram o gargalo, a carga também nunca foi tão pesada assim. Quando o Zan foi testar os participantes pra encontrar os finalistas, o teste era ainda mais leve.

Ele dobrou o teste, senão todo mundo ia passar. Mas mesmo dobrando, ainda não é pesado o suficiente. Todos os teste que fiz até agora foi com essa versão já dobrada. É importante ter essas ordens de grandeza em mente. Vamos deixar anotado porque preciso explicar isso pra vocês, o que significa sessões simultâneas, tempo de resposta, throughput.

Faixa de 50 mil linhas numa tabela é super leve pra um banco de dados como Postgres. Só vamos sentir que ele tá pedindo água quando atingirmos faixa de milhões de linhas e isso se estiver sem índices adequados. 600 sessões fazendo requisições, não é pesado. Mesmo com a restrição de menos de 1 CPU no Docker Compose. 1000 sessões simultâneas continua não sendo pesado.

A viagem de volta de Gramado foi cansativa. Varamos noite no domingo pra segunda. Estava de carro alugado e saímos quase 2h da manhã de Gramado pra devolver o carro às 4h em Porto Alegre e pegar o vôo de volta pra Congonhas, em São Paulo às 6h. Pegamos táxi perto das 9h da manhã. Antes das 10h chegamos em casa. Eu só pude cochilar rapidinho no avião e quando cheguei já liguei meu PC.

A primeira versão que queria testar foi a de Crystal com Lucky. Troquei o network mode no docker compose pra host e … foi! Era isso. Bateu 47 mil inserts. Provavelmente algum bug de validação porque ultrapassou o máximo. Zero knockouts. Sabe a tal tremida nos gráficos que falei? Liso, até o fim, uma linha reta em todos os gráficos. Era isso que eu sabia que Crystal tinha capacidade, e confirmamos, a rede do Docker que não estava deixando!

Próxima versão, mexi no meu Rails overengineered com Sidekiq e tudo mais. Network mode host e bateu acima de 45 mil inserts, faltou pouco pra atingir o máximo dos 46 mil e tantos. Não gastei muito tempo ajustando valores no docker composer, mas mesmo assim deu só 4% de knockouts. Antes dava 20%, 30% ou mais. Mas isso prova meu ponto: o gargalo nunca foi nem falta de CPU e nem falta de RAM, nem postgres e nem nginx, era um problema de I/O e isso é gerenciável em quase qualquer linguagem. Se Crystal e Ruby batem o máximo, qualquer outra deveria conseguir.

Peguei a versão de Lean4 e ainda tem algum bug de validação, mas bate acima dos 47 mil inserts. Mais uma versão que vence o stress test sem suar. Peguei a versão em Node.js do Lucas e também bateu no máximo de 46 mil e tantos. E isso foi se repetindo. A versão em Python e Sanic do Ian Cambrea, a versão em V Lang do Carlos, a versão em Go do Luan, a de PHP com Swoole do Lauro, a outra versão em Rails do Lazaro, todos batem o máximo.

De bônus, resolvi testar a versão em C++ do Lucas William que tinha ficado em 12o lugar com menos de 35 mil inserts, também bate perto do máximo agora, 43 mil inserts. Não bateu por algum bug na validação. Enquanto algumas versões faltava validação e deixava inserir mais que o máximo, nesta versão tem alguma coisa filtrando demais e impedindo de gravar mais. Olhando os gráficos claramente podemos ver que tá sobrando recursos. Zero knockouts, não tá perdendo requisições, então tem recursos sobrando.

Nesta segunda-feira, tava todo mundo só falando do lançamento da versão 1.0 do Bun, a nova alternativa a Node.js e Deno que promete ser mais performático. Ainda é cedo pra dizer e ainda nem é totalmente compatível. Mas o Yuri Gomes tinha participado da rinha com a versão pré-lançamento do Bun, 0.8 e tinha ficado em 14o lugar com menos de 28 mil inserts. Mas com network mode em host, ele também bateu o máximo e com tempos similares da versão de Rust. Neste exemplo com escopo pequeno, seu desempenho foi à altura do hype, o que é bem promissor.

Alguns ficaram me cutucando pra mexer em C# também. Eu não tinha mexido em nenhum até agora porque a versão do André e do Albert já provaram que alcançava o máximo. Mas, nada mais justo do que finalizar essa segunda-feira super corrida pós-feriado, do que avaliar a versão do nosso querido organizador da rinha, Zanfranceschi. Por coincidência ele participou com uma versão de Dotnet.

Não vi ele no ranking oficial. Acho que, como organizador ele se absteve de se colocar na disputa, participou pela diversão mesmo. Mas cometeu o mesmo erro que eu e outros: assumimos que postgres ia ser o gargalo e colocamos cache de Redis antes de realmente medir a necessidade. Mas espero que a esta altura tenha ficado claro que postgres nunca foi o gargalo. Não estou dizendo que nunca é, em outros projetos pode ser, mas neste desafio não era. Por isso é caso a caso, precisa medir.

Por causa disso ele implementou um cache em memória usando um ConcurrentDictionary. Lembra aquelas pesquisas com select LIKE que mencionei antes? No Postgres, se indexarmos com GIST e trigrams, fica bem rápido, mas com uma estrutura rudimentar como um dicionário, um hash, ele é obrigado a percorrer 100% do dicionário o tempo todo, extremamente lento.

Isso limitou o resultado a 40 mil inserts. Eu tentei fazer os mesmos ajustes de todo mundo: limitar vazão do nginx, mexer no pool de conexões, dividir melhor recursos do docker composer, colocar em network mode host, mesmo assim não dava. Minha suspeita é que esse ConcurrentDictionary matou esta versão, se alguém quiser tentar tirar e retestar, vá no repositório dele nos links abaixo.

De qualquer forma, com a ajuda de todo mundo, do Leandro, do MrPowerGamer, do Gabriel Oliveira, do Vinicius Ferraz e outros, conseguimos atingir o objetivo não oficial que eu estabeleci pra rinha: vencer o stress test e colocar todas as linguagens no mesmo 1o lugar ou dentro dos Top 3. Fizemos isso com 3 versões de Ruby, Node.js, PHP, Python, Java e Kotlin, Bun, V Lang, Go Lang, Crystal, C++, todo mundo bateu os máximos.

As duas exceções que não bateram foi a de C# do Zan e a de Elixir do Gabriel. Em ambos os casos, acho que a lógica de cache engargalou. Que é lição aprendida: não faça otimização prematura. Em vez de ficar mais rápido, pode ficar mais lento. Se tirar esse cache, provavelmente bateriam os Top 3. E falando em Top 1, agora que consegui cumprir minha missão nesta rinha, só faltava uma última coisa que queria fazer: desenferrujar meu Rust mexendo na versão do ganhador oficial, o Vinicius Fonseca. Finalmente chegamos no 16o dia da minha saga, dia 13 de setembro.

Assim como a versão em C++ do Lucas, ou em Node do outro Lucas, que colocaram tudo num arquivo só. O Vinicius fez a mesma coisa em Rust. Repetindo: é uma rinha, o critério não era o código durar pra sempre, era só aguentar o stress test. Beleza do código, mantenabilidade, legibilidade, segurança, nada disso eram critérios. Eu que fui narigudo e fiquei fuçando e mexendo no código dos outros sem ninguém pedir. Meu objetivo era só desenferrujar meus skills. Uma boa forma de fazer isso era pegar o código dos outros e sair reorganizando.

Essa foi a primeira coisa que fiz no código do Vinicius: refatorar. Rust já não é uma linguagem muito fácil de bater o olho. Cheio de anotações, um monte de .clone() e .unwraps() e tipos e generics pra lá e pra cá. E tudo amontoado. Dividindo em módulos fica mais fácil de bater o olho. Mas eu queria corrigir o bug que o MrPowerGamerBR identificou na análise dele: a condição de corrida que acabava deixando sobrar mais linhas na tabela do que o máximo possível.

Isso acontece porque o Vinicius manda inserir mais de 500 linhas na inicialização pra algum tipo de aquecimento. Que eu saiba o Rust não tem e nem precisa de um just in time compiler, um JIT, já que é pré-compilado em binário. Aquecimento faz mais sentido pra Java, que tem JIT. Enfim, ele deixa essa rotina rodando numa corrotina da biblioteca Tokio, a mais famosa que dá suporte à semântica de Futures, o equivalente a Promises de Node.js.

Na sequência, inicia um segundo Future assíncrono. Essa rotina tem um timer, um sleep de 2 segundos. Quando passa 2 segundos manda um comando de SQL pra deletar as linhas de aquecimento. É aqui que acontece a condição de corrida. Nada garante que 2 segundos é suficiente pra inserir essas 500 linhas. Muitas vezes o delete acontece antes. Daí sobra linhas na tabela.

Não havia necessidade do delete estar num future separado. Bastava disparar o delete depois do último insert. Ou uma gambiarra seria aumentar esse timer de 2 pra mais segundos. Eu fiz isso. E pra garantir, alterei o último endpoint, o de contagem final da tabela, pra filtrar os registros de aquecimento. Com isso batemos os mesmos 46 mil e tantos inserts, como todo mundo. Depois dêem uma olhada no meu pull request pra conseguir entender melhor essa versão de Rust.

Eu não curto competições de código. Não porque sou contra. Cada um com seu entretenimento. Não tem nada de errado em competir com código. Só não pode achar que código de competição é a mesma coisa que código pra projeto de verdade. As técnicas são diferentes. Os requerimentos são diferentes. Muitos truques que mencionei, não devem ser usadas sem critério, vai dar errado. E nenhuma comparação generalizada deve ser feita entre as diferentes tecnologias usadas.

Uma competição no estilo dessa rinha serve pra mostrar quem foi mais esperto, quem teve mais sorte, quem foi mais cuidadoso. O Zan teve bastante trabalho pra organizar e pra avaliar um a um. Cada rodada do stress test do Gatling custa 3 minutos. 50 projetos que passaram significa que ele gastou quase 3 horas só esperando os testes rodarem, sem contar os outros projetos participantes que tinham bugs. Agora que passou é fácil dizer “ah, poderia ter feito X melhor, poderia ter feito Y melhor”, mas a posteriori tudo é fácil.

Eu gastei mais de 2 semanas avaliando 18 repositórios em 16 linguagens diferentes. Eu tive a sorte de contar com a contribuição de diversos outros desenvolvedores que se animaram pra investigar junto. Acho que conseguimos desvendar todos os truques possíveis desta rinha, incluindo vencer o stress test do Gatling. Mas isso não é competição, é análise técnica. Não é divertido pra todo mundo, só pra nós mais nerds.

Mesmo se você for torcedor de um Neymar, Messi, Cristiano Ronaldo, seja lá quem acha que é o melhor jogador do mundo, se no dia do jogo eles torcerem o tornozelo e não participarem, o resultado vai ser o que der no dia. Quando perdem, não significa que são ruins no geral. Só significa que perderam aquele jogo, ponto final. É o conjunto da obra que determina os melhores e não um jogo individual. Sorte faz parte do jogo. Mesma coisa nesta rinha. Só porque um Java ou um PHP não apareceram no topo, desta vez, não tem nenhuma correlação com a qualidade deles em outros jogos.

Amador desbocado é quem faz mais barulho nas redes sociais, então meu objetivo foi educacional: demonstrar porque estão errados e fazer todos entenderem que sim: com mais tempo, experiência, skill, qualquer uma das linguagens tinha capacidade de alcançar resultados semelhantes, alguns com mais trabalho, alguns com menos trabalho, alguns gastando mais recursos, alguns menos, não importa. Sua linguagem não te define.

Assistiram meus videos de Sua Linguagem Não é Especial? O que eu falei lá? Um bom desenvolvedor é promíscuo com linguagens. Eu mexo em qualquer uma, a qualquer hora, quando quiser e como quiser. O que eu falei em videos como Aprendendo a Aprender ou Aprendizado na Beira do Caos? Várias das linguagens que mexi nesta saga, ou nunca tinha mexido, como Nim, Lean4, V Lang, ou tava enferrujado fazia anos, como C++, C#, Rust, Go, PHP, Crystal. Mesmo linguagens que tenho um pouco mais de intimidade, como Ruby, Javascript, Python, tive que quebrar a cabeça.

O que eu fiz? Instalei uma a uma e fui fuçar código dos outros. Quebrei elas várias vezes. Consertei, refatorei, reorganizei, fiquei em muita tentativa e erro, reimplementei técnicas diferentes, apliquei técnicas de uma linguagem em outra, li muito código fonte. Mesmo sem nunca ter mexido num framework como Lucky, mesmo Bun que acabou de lançar, não levou mais que algumas horas pra me acostumar. Essa é a diferença: as primeiras linguagens que aprender vai levar meses, anos pra dominar.

As próximas vão ficando exponencialmente mais rápido de pegar, o suficiente pra conseguir fazer o básico. Novamente, demonstrei este ponto na prática. Em um dia já dá pra fazer alguma coisa, se me der poucos dias, consigo me virar em qualquer uma. Em poucas semanas já vou saber truques avançados de cada uma. Eu consigo me tornar produtivo numa linguagem nova em 1 mês. Onde vou levar mais tempo? Em linguagens que tem paradigmas muito diferentes, como Haskell, Ocaml, F#, Clojure ou o Lean4 que vimos hoje.

Com todos esses disclaimers e avisos feitos, ouçam até o final antes de sair comentando. Sim, Rust e Go aparecem no topo do ranking oficial porque, se não cometer erros graves, o tempo de resposta individual de cada requisição vai ser na faixa abaixo de 1 milissegundo, de microssegundos. Frameworks como Rails ou um Laravel da vida vão responder na faixa de milissegundos. Quanto menor o tempo de resposta, mais requisições dá pra responder no mesmo período de tempo. Rust ou Go realmente tem mais velocidade bruta e conseguiram bater a barreira acima dos 40 mil inserts, mesmo com docker em modo ponte, e chegar no máximo durante o evento.

Porque todo mundo não passa a adotar Rust, Go, V Lang, Zig, de uma vez? Tudo compilado em binário nativo super rápido? Vamos colocar assim: não existe um único motivo. Não pensem que as pessoas ou empresas são burras e não sabem que são rápidos. C e C++ existem muito antes da maioria de vocês nascerem e sempre foram rápido. Todo mundo sabe disso.

No caso de um V Lang ou Zig é fácil explicar: é porque são novos demais e instáveis demais, tem suporte baixo, tem ferramental imaturo, mudando o tempo todo e quebrando compatibilidade, falta documentação na forma de livros, cursos justamente porque ainda estão mudando muito. Esses não tem como ser adotados em larga escala. Só early adopters muito dedicados. Só empresas menores e com maior margem de assumir riscos, com um co-fundador ou diretor técnico muito bom pra liderar.

Mas tudo é uma questão econômica. Não me xinguem, eu sou só mensageiro, mas a realidade é que a enorme maioria dos programadores não tem capacidade de aprender a usar linguagens de baixo nível, no nível que seria necessário pra serem produtivos e produzir código bem feito. O fato da maioria das empresas não estar desesperadamente procurando esse perfil é a evidência. Sempre existem exceções, não comece com “ah, mas eu conheço fulano ou ciclano”. Exceção não define a regra.

Fica a dica: se tornar um programador avançado nas tecnologias mais difíceis, te torna uma mosca branca, que vale muito mais que os outros. O que eu sempre falo? Tudo que é fácil pra você aprender, também é fácil pra qualquer outro. Quanto mais gente tiver fazendo a mesma coisa, mais barato todos vão ser. O valor está em ser bom naquilo que poucos tem capacidade de conseguir. Onde a barreira é mais alta. E isso vai ser Rust, Go, C++, pra resolver problemas muito mais complicados do que fazer Cruds ou APIs.

Reflitam sobre vocês mesmos, porque estão estudando Java ou C# ou Javascript? Porque são as posições que tem mais vagas. Rust não se vê vagas todos os dias. Estão vendo? É o problema do ovo e da galinha. Você não quer investir tempo pra aprender Rust porque não vê vagas todo dia. E as empresas não oferecem vagas porque não vêem trocentos cursos e estudantes aprendendo. Por isso que esse tipo de movimento, ou começa em startups arrojadas ou dentro de gigantes como uma Microsoft. As vagas existem, bem pouco, e pagam bem, só que são bem mais exigentes. Mas ninguém gosta de vagas difíceis, só querem as que acham fácil.

Não é prático nem realista manter aplicações web complexas e gigantes em linguagens assim. Imagine um Shopify, GitHub, MercadoLivre, Amazon ou iFood da vida, 100% em linguagens de baixo nível. Partes do sistema, que são mais sensíveis a performance, já adotam coisas como Go, mas é a menor parte. Pro uso do dia a dia, dashboard, relatórios, cruds e coisas assim, não compensam. Seria um enorme desperdício dar tarefas consideras commodity como fazer relatórios, pra um tipo de programador raro e caro, com de Go ou Rust.

Adotar uma tecnologia só porque é mais rápida, não é um bom argumento. Hoje em dia todas são rápidas o suficiente. Mesmo linguagens que um programador de Rust chamaria de lentas, como Javascript ou Python, conseguimos atingir patamares similares com um custo um pouco maior de máquina. Como demonstrei aqui, na maioria dos casos, é possível dobrar a performance, triplicar, tendo o conhecimento adequado, sem quase modificar código, nem precisar jogar tudo fora e reescrever tudo em Rust. É isso que programadores como eu fazemos.

No fim dia, dado a escassez de programadores de Rust ou Go e a dificuldade de achar talentos que consigam ser treinados nisso, em pouco tempo, sai bem mais barato compensar com servidores mais parrudos. Alguns pensam que pra dobrar a performance da sua aplicação em PHP, em Java, Dotnet, Python, Node, precisa jogar tudo fora e reescrever em Go. Tá errado.

Só vai garantir que os erros por ignorância que foram cometidos com um PHP, vão se repetir em Go. Programador ruim, vai fazer código ruim em PHP ou em Go. Não existe nenhuma garantia que vai ficar mais rápido se você continua não sabendo porque o anterior tava lento. Por outro lado, por experiência, já melhorei muito sistema de verdade mexendo nos 20% de problemas que dão 80% de retorno. É sempre assim, às vezes são besteiras de pouquíssimas linhas, como as que mostrei durante este video.

Como falei antes, são vários motivos, custo-benefício sendo o principal. No geral o maior problema é que é muito difícil formar bons programadores que consigam tirar vantagem dessas tecnologias. O custo-benefício não compensa. Não significa que essas linguagens não tem chance, significa que esse mercado sempre vai ser de nicho. Mas pra quem tem o talento e a capacidade, é um nicho que paga muito melhor. É só ser bom.

Enfim, hoje eu só quis resumir minha saga de como explorei 16 linguagens, claro que superficialmente, em 16 dias. Não deu pra detalhar cada truque, mas deixamos tudo anotado, e no próximo video vou explicar o truque por trás da mágica: como tudo isso funciona, por que funciona e, mais importante, quando usar e quando não usar. Se ficaram com dúvidas mande nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais!

Um dos assuntos que mais assusta iniciante é esse negócio de “modelagem de software” ou “design de software” ou “arquitetura de software”. Vários nomes que parecem ser a mesma coisa e ao mesmo tempo não serem coisa nenhuma.

Hoje quero “filosofar” um pouco pra dar uma perspectiva diferente de como se deve encarar esses assuntos e talvez uma estratégia de como realmente entender como isso funciona.

CAPÍTULOS

• 00:00 - Intro
• 02:08 - CAP 1 - Livros de Modelagem e Arquitetura - Devo Estudar Todos?
• 04:14 - CAP 2 - O Problema dos Tutoriais - Modelando Objetos Reais?
• 13:07 - CAP 3 - Modelando o Mundo Real - Um Exemplo
• 16:04 - CAP 4 - A diferença de “VER” e “ENXERGAR” - Michelângelo e Arte
• 21:30 - CAP 5 - Mentoria do Mundo Real - Cuidados
• 24:44 - CAP 6 - Analisando o Mundo Real - Aprendendo Ecommerce
• 33:11 - CAP 7 - Teoria e Prática - A História do Magento
• 41:07 - CAP 8 - Recomendação de Livros - Aprendendo com Especialistas
• 49:17 - Bloopers

Links

• Magento 2
• Spree
• Agile Web Development with Rails - GitHub
• Agile Web Development with Rails
• The Architecture of Open Source Applications
• Rails Summit 2009 - Ilya Grigorik
• Chatting with Luke Kanies
• RailsConf 09 - Exclusive Audio Interviews | AkitaOnRails.com

SCRIPT

Olá pessoal, Fabio Akita

No último video resolvi falar mais sobre bancos de dados. Já tinha feito dois videos antes sobre isso e em todos fui pelo caminho mais fácil: explicar como funcionam por baixo. As engrenagens que possibilitam existir armazéns de dados. Mas explicar implementação não é tão difícil, porque eles já existem e funcionam bem.

O problema que eu venho me esquivando desde o começo do canal é explicar o que a maioria de nós, programadores, considera o problema mais difícil da programação: dar nomes pras coisas. Isso mesmo, não é piada. Em particular, como modelar um problema de negócios em código? O que é um design de software “feito direito”? O que significa “fazer direito”? Significa seguir Domain Driven Development? Significa usar a maioria dos Design Patterns? Significa seguir algum framework? Tem algum livro que se possa ler e aprender o que significa isso de “modelar”?

Durante toda a vida deste canal eu vim flertando com esse assunto, por exemplo quando falei do Livro The Mythical-Man Month, que afirmei ser o mais importante pra se ler. O video de hoje vai ser uma filosofada super longa e provavelmente super frustrante. Frustrante porque eu não vou dar copy e paste de material que já tem online. É só procurar que você acha tudo de patterns, arquitetura, modelagem. O objetivo do video é explicar porque muitos acham “difícil”, mesmo tendo todo esse material. E no final vou até recomendar outros materiais, então assistam tudo.

O spoiler é que não existe o “jeito certo” de se fazer software, mas por outro lado, o processo não é aleatório. Existe um balanço fino entre teoria e prática que é onde se encontra nossa profissão. A razão de existir programadores é justamente porque é nossa função decidir o que é “melhor” pra determinada circunstância.

Lembram do video de Não Terceirize Suas Decisões? O pior programador é aquele que é incapaz de tomar decisões. O melhor programador não é aquele que toma todas ou a maioria das decisões corretas, mas sim aquele que toma decisões possíveis no momento em que precisam ser tomadas, nem antes, e nem depois. E o que vou tentar fazer hoje é ilustrar esses conceitos. Então vamos lá.

(….)

Como primeira opinião controversa do dia, vou afirmar o seguinte. A maioria dos livros de modelagem e design, como o Clean Code do Bob Martin, o Domain Driven Development do Eric Evans, o Design Patterns do Gang of Four, o Patterns of Enterprise Application Architecture do Martin Fowler; todos livros excelentes, mas eu acho que são totalmente inúteis no seu primeiro ano pós faculdade. Entenda: você acabou de se formar, ainda tem pouca ou nenhuma experiência em projetos reais ou em projetos pessoais ou open source. Esses livros são perda de tempo.

Pra ficar muito claro: eu não estou dizendo que os livros são inúteis. Muito pelo contrário, eu acho todos eles excelentes e que precisam ser estudados. Mas todos tem um pré-requisito: que você já tenha quilometragem em código. Tanto em fazer seu próprio código quanto lidar com código dos outros, especialmente código legado.

A estratégia é assim: nenhum desses livros você deve tentar ler de cabo a rabo de uma só vez. Folheie alguns capítulos, os iniciais. Veja os temas de cada um pelo índice, leia a primeira página de cada capítulo. Guarde. Vá trabalhar ou treinar com projetos open source. Volte daqui um ou dois meses. Folheie de novo, avance um capítulo a mais, pule pra um capítulo no meio que tem assunto que chamou sua atenção porque é compatível com o que está mexendo no momento. Guarde de novo.

Depois do primeiro ano trabalhando tempo integral com programação, retorne. Leia com um pouco mais de esforço. Releia os primeiros capítulos. Repita. É um processo que deveria te custar os primeiros 3, talvez 5 anos iniciais de carreira. Se fizer direito, talvez comece a entender o que esses autores queriam dizer quando estiver lá pelo quarto ano.

Um dos sinais que você conseguiu mesmo pular de nível junior pra pleno, é quando começa a entender o que os autores queriam dizer, e não está tentando seguir ao pé da letra o que está escrito, sem saber porque. Mas no primeiro ano, esses livros são inúteis. Você ainda não lidou com problemas suficiente pra entender esses porquês. E o importante é o porquê. Agora deixa eu dar uns passos pra trás e explicar porque.

Qualquer um que já tenha tido curso ou lido livro sobre modelagem de objetos já deve ter esbarrado no famoso exemplo dos animais ou veículos. Por exemplo, ambos cachorro e gato são animais. Animal é uma abstração. Portanto, parece óbvio que deveríamos fazer uma classe abstrata chamada Animal, daí podemos derivar sub-classes Cachorro e Gato que herdem de Animal, ou em linguagens mais modernas, que tenham o “trait” ou protocolo de Animal.

Ou então temos Carro e Caminhão, ambos são veículos, poderia ser essa a classe pai abstrata. Carro e Caminhão herdam de veículo. O problema com todos esses exemplos, primeiro é que eu nunca vi ninguém fazer uma classe realmente chamada Animal. Talvez quem já trabalhou em projetos de biologia ou zoológico. Mesmo se fizer um sistema de uma fábrica ou concessionária de carros, provavelmente vamos ter uma tabela ou classe mais genérica, mais abstrata ainda, como “Produto”.

O problema de sistemas de verdade é que praticamente todos os conceitos mais importantes são abstratos, não concretos. Por exemplo, o caso mais óbvio, que são os usuários de um sistema. Usuários não são pessoas? Acho que é por isso que todo iniciante começa um sistema pela tabela de usuários, porque é a única coisa que consegue se identificar, é familiar. Ou seja, tem alguma experiência. Mesmo um iniciante sabe que um usuário deve ter atributos como nome, email, telefone, endereço, RG ou CPF e coisas assim.

Mas rapidamente isso complica. Estamos falando dos dados de identificação de um usuário? Ou estamos falando dos dados de autenticação, como login? Nesse caso precisamos de atributos como “username” e “password”. E já começa o primeiro erro. Já expliquei nos episódios de segurança e criptografia que não gravamos senha numa tabela. Precisamos de atributos abstratos como “salt” e “hash”. Mas e two-factor authentication? Precisamos de um seed pro algoritmo de Time-based One-Time Password ou TOTP. Só se você estudou segurança vai saber disso.

Dá pra complicar mais. Enviar link pra redefinir uma nova senha, caso tenha esquecido. O ideal é fazer uma tabela secundária, ou no banco de dados, ou num servidor de cache como Redis. Com um ID único que só pode ser usado uma vez, e aí o ideal é logar o endereço IP da pessoa que clicar no link, pra fazermos auditoria e ver se parece suspeito. Novamente, estratégias de segurança.

Se deixarmos segurança de lado. Usuário é usuário, certo? Tendo nome, email e coisas assim, tá tudo certo? Não. Digamos que o cadastro é pra parte de logística de um ecommerce. Logística precisa de um endereço. Ótimo, basta pedir o endereço. Mas cuidado, uma coisa é endereço de entrega, outra coisa é endereço de cobrança. Pra você, que é iniciante, só deve conhecer o conceito que uma pessoa só tem um endereço, certo?

Mas não. Uma coisa é o endereço de cobrança, pra mandar nota fiscal, outra coisa diferente é o endereço de entrega, pra onde enviar o produto. Eu posso ter endereço residencial, mas posso querer que a entrega seja feita no meu endereço comercial. Mas e se você se mudar de residência? E se você mudar de emprego? Ambos vão mudar. Ou, e se eu quiser comprar e pagar no meu cartão de crédito, mas mandar entregar como presente pros meus pais? Então preciso conseguir cadastrar endereço dos meus pais. Eu deveria criar um usuário separado pros pais? Como faz?

À primeira vista, endereço parecia ser só meia dúzia de campos na tabela usuário. Mas agora deve começar a ficar mais claro que pode ser uma tabela separada de endereços que precisa de uma chave-estrangeira apontando pra chave-primária do usuário. Mas não é só isso. E se meu ecommerce oferece coisas como pontos por fidelidade? Quanto mais eu comprar, mais pontos eu ganho e com isso posso usar como desconto nas compras? Pontos do usuário, ficam na tabela de usuários? Não? Então onde coloca?

Num sistema empresarial maior, usuários podem ter vários perfis, várias visões. Usuário pode ser funcionário da empresa, e aí vai precisar de atributos como número de PIS/PASEP pra coisas como fundo de garantia. Usuário pode ser um fornecedor ou funcionário de um fornecedor. Fornecedor tem um cadastro separado, CNPJ, número interno de fornecedor. Usuário pode ser consumidor mesmo, daí vai ter pedidos, entregas, suporte. Usuário é um conceito muito mais complicado do que se pensa e num sistema de verdade, raramente é só uma tabela. Vai ser uma coleção de tabelas e classes. Talvez um sub-sistema inteiro separado.

Só pra dar outro exemplo. Falei de carro. Se você é um iniciante fazendo um ecommerce pra uma concessionária ou um concorrente de webmotors da vida, poderia pensar em fazer uma tabela chamada “Carro”. Daí coloca atributos como “marca” tipo Volks ou Fiat, modelo tipo Nivus ou Corsa. Ano, combustível, chassi e coisas assim. É o que você conhece vendo o carro dos seus pais. Mas claro, isso tá longe de completo.

E se quiser vender caminhonetes, ou motos, ou vãs? Melhor criar uma tabela mais genérica chamada “Produto” então? Os atributos vão ser mais ou menos os mesmos mas podemos colocar uma coluna de “tipo” pra dizer se é um carro ou moto ou outra coisa. Daí é só ter colunas como preço e já era, certo? Não tá errado, mas não é só isso nem de longe.

Só pra dar um pequeno exemplo: em ecommerces e varejo em geral, existe o conceito de SKUs. Stock Keeping Unit, que é um item distinto de venda, seja de produto ou serviço. É um código alfanumérico. Esse código é importantíssimo pro gerenciamento de inventário, de estoque. Faz de conta, o produto Volks Nivus, tem a versão Comfortline e Highline. A Highline tem 4 cores especiais, 2 cores metálicas, 3 cores sólidas como Preto Ninja ou Branco Cristal ou Cinza Moonstone.

Então o Volks Nivus Highline 2023 Cinza Moonstone tem um SKU único e diferente do Volks Nivus Highline 2023 Preto Ninja. Entende porque? Se você vai na loja, não quer saber se tem o Nivus, quer saber se tem exatamente o Highline 2023 Branco Cristal. Não adianta ter estoque do Preto Ninja, não é ele que você quer. E não adianta ter o Branco do Comfortline, você quer o Highline. O SKU reflete o exato item que você quer.

Mesma coisa com roupa. Ah, tem a camiseta com estampa do Iron Maiden, mas só tem o tamanho M, mas você queria o G. Camiseta Iron Maiden, tamanho M é um SKU e tamanho G é outro SKU diferente. É assim que se modela produtos numa loja. Então, numa tabela de produtos o item que você cadastra não é “Volks Nivus” ou “Camiseta Iron Maiden” e sim “Volks Nivus Comfortline 2023 Vermelho Sunset” ou “Camiseta Iron Maiden tamanho PP”.

Mas os problemas só começaram. Porque se você é a Volkswagen, vai ter um sub-sistema separado, a da fábrica, com outro cadastro de Volks Nivus Comfortline 2023 totalmente diferente. Pra manufatura vai ter outros atributos como o BOM ou “Bill of Materials”. Precisa de quais peças pra montar uma unidade? Transmissão, injeção, computador de bordo, disco de freio, etc. Cada um desses itens tem estoque, tem fornecedor, tem leilão reverso no setor de compras, tem tempo de entrega pra receber essas peças.

Com tudo isso temos um custo de fabricação. Isso pode, ou não, estar ligado ao sistema de vendas. Primeiro, isso influi no estoque e disponibilidade. E também influi no sistema de precificação. Preço não é um valor único na tabela de produtos, como muitos iniciantes podem pensar. É o resultado de diversos cálculos. Custo de fabricação é só um dos fatores. Tem coisas com impostos. ICMS que é o Imposto sobre Operações relativas à Circulação de Mercadorias e sobre Prestações de Serviços de Transporte Interestadual e Intermunicipal e de Comunicação.

Faz diferença onde o carro é fabricado, pra onde precisa ser transportado, especialmente se atravessa estados. Existem impostos federais, estaduais, municipais. Tem todo um cálculo de impostos que influi no preço final. Por isso costumava ser mais barato comprar carro em Minas Gerais do que em São Paulo, por exemplo, não sei se ainda é, mas lembro que me falaram que por isso muito carro de empresa que aluga, tem placa de Minas. O preço varia por região. Mas não é só isso, tem cálculo de custo de oportunidade, depende da estratégia da empresa. O importante é lembrar que preços não são estáticos, tem diversos fatores.

Beleza, temos o carro fabricado, temos o preço pro consumidor final, a venda foi feita, agora o carro precisa transitar entre a fábrica de São Bernardo Campo até a concessionária em Belo Horizonte. Pra trafegar precisa da nota fiscal. Pra colocar o caminhão na rua, precisa de rotas. De onde eu puxo informação pra rota? Google Maps? Maplink? Sistema proprietário, já que eu sou grande como uma Volks?

E não é só isso. Se queremos implementar sistemas de pagamentos, que lidam com dados sensitivos como números de cartão de crédito e coisas assim, nos Estados Unidos, temos o PCI DSS, Payment Card Industry Data Security Standard que dita como empresas devem proteger esse tipo de informação. E estou falando “Estados Unidos” daí parece que não é seu problema. Mas não se esqueça que hoje empresas são multinacionais. Pode ter empresa que começou no Brasil e agora atua internacionalmente, daí precisa implementar essas normas.

No caso específico de privacidade, segurança de dados de consumidores, na Europa temos o GDPR que é o General Data Protection Regulation da União Européia e no Brasil temos o LGPD, a Lei Geral de Proteção de Dados, que é similar. Enfim, o ponto é que não basta só sair modelando tabelas e jogando em qualquer lugar. Cada indústria tem seus padrões e cada país tem suas regulamentações. Precisa seguir. E pior: não é um checklist simples. Algumas coisas você é obrigado, algumas coisas dá um jeitinho, depende de como lidar com o auditor. Muitas nuances não documentadas.

O mundo real é muito mais complicado do que simplesmente pensar em modelagem de dados da forma acadêmica, onde nos preocupamos com coisas como normalização, se queremos terceira forma normal, ou no caso de DDD se estamos falando de Bounded Context, aggregates, domain events. Ou no caso de Design Patterns, se queremos chain-of-command ou mediator. O que eu falei até agora é parte do que chamamos das tais “regras de negócio” e patterns, arquiteturas, DDD da vida é a “descrição” da implementação dessas regras.

O problema é que se você não entende a regra de negócio, não interessa discutir se vai escolher um Adapter ou um Proxy, se vai organizar na terceira ou quarta forma normal. Se a regra estiver errada, a implementação vai estar errada, independente se seguiu o livro do Eric Evans ou pé da letra. E falando no livro de DDD, logo na introdução ele dá um exemplo interessante de um sisteminha de entrega de mercadorias.

Digamos que temos as entidades Voyage e Cargo, tipo viagem e mercadoria, onde uma viagem tem muitas mercadorias. O Eric descreve um sistema que tem responsabilidade de associar cada mercadoria com uma viagem, gravar e rastrear esse relacionamento. Até aqui tudo bem. Em algum lugar do código vamos ter um método como esse:

public int makeBooking(Cargo cargo, Voyage voyage) {
	int confirmation = orderConfirmationSequence.next();
	voyage.addCargo(cargo, confirmation);
	return confirmation;
}

Mas porque existem cancelamentos de última hora, uma prática padrão da indústria de entrega é aceitar mais mercadorias do que é possível numa única viagem. É o que se chama de “overbooking”. Algumas vezes é usado um percentual simples, como 110% da capacidade, em outros casos tem regras mais complexas.

Isso é uma estratégia básica no domínio de entregas que é conhecido de qualquer empresário dessa indústria, mas normalmente nós, programadores, não sabemos disso. O requerimento que vem pra nós poderia ser algo como “Permitir 10% de overbooking”, o diagrama de classes poderia ficar parecido com isto e o código seria atualizado da seguinte forma:

public int makeBooking(Cargo cargo, Voyage voyage) {
	double maxBooking = voyage.capacity() * 1.1;
	if ((voyage.bookedCargoSize() + cargo.size()) > maxBooking)
		return -1;
		
	int confirmation = orderConfirmationSequence.next();
	voyage.addCargo(cargo, confirmation);
	return confirmation;
}

Ou seja, no código determinamos quanto é o novo máximo com 10% a mais de overbooking e vemos se a mercadoria que queremos adicionar ultrapassa esse máximo. Mas isso cria um problema: agora temos uma regra de negócio escondida, como uma cláusula de guarda, no meio do método da aplicação.

Segundo o Eric, essa regra de overbooking é uma política. Política é outro nome pra um design pattern conhecido como Strategy. Em resumo, esse novo código poderia ser refatorado pra ter uma classe separada de OverbookingPolicy e no método de adicionar a mercadoria na viagem, chamar o método “isAllowed” dessa nova classes, e assim separar a política numa entidade separada, que documenta melhor essa regra em vez de deixar misturada e escondida com o código anterior.

public int makeBooking(Cargo cargo, Voyage voyage) {
	if (!overbookingPolicy.isAllowed(cargo, voyage))
		return -1;
	int confirmation = orderConfirmationSequence.next();
	voyage.addCargo(cargo, confirmation);
	return confirmation;
}

class OverbookingPolicy {
	public static double OVERBOOKING = 1.1;
	public boolean isAllowed(Cargo cargo, Voyage voyage) {
		double maxBooking = voyage.capacity() * OVERBOOKING;
		return ((voyage.bookedCargoSize() + cargo.size()) <= maxBooking;
	}
}

Agora que eu descrevi dessa forma, deve ter ficado óbvio. “Puts, claro, porque eu não pensei nisso antes”. Mas o que quero expor aqui é justamente isso: pra nenhum iniciante é óbvio que isso poderia ser um strategy pattern, provavelmente não era óbvio que isso era uma “Política”. Todo mundo ia ter implementado do primeiro jeito e nunca ia pensar nisso. Até o dia que alguém pedisse pra mexer na regra e mudar de 10% pra 5% por exemplo. Daí iam gastar o dia inteiro tentando achar “onde que tá definido isso no código???”

Deixa eu dar outro exemplo pra ilustrar mais esse ponto. Eu gosto de quadrinhos, comics, mangá, até já me arrisquei a desenhar como hobby no passado. Todo mundo que fica empolgado com um One Piece ou Naruto da vida já rascunhou seus personagens preferidos em algum pedaço de papel e, se não for completamente iludido, sabe que saiu uma porcaria. Mas tudo bem, o objetivo era passatempo.

Já percebeu como todo iniciante em arte faz as mesmas coisas? Ou é paisagem de casinha com uma árvore, um sol e uma montanha. Ah sim, com uma chaminé, não pode esquecer a chaminé. Ou é close-up de rosto de anime. Agora, tenta desenhar um quarteirão de uma cidade, com ângulo olhando de cima. Ou tenta desenhar uma personagem de anime mesmo, sentada numa mesa com as pernas cruzadas e tomando um café. Vai sair a coisa mais torta do mundo, se sair.

Desenhar prédios pode parecer fácil, só retângulos, mas tente fazer um. Não vai conseguir. Convivemos a vida toda do lado de prédios, andamos todos os dias na frente de vários, por anos. Mas nunca paramos pra realmente olhar, observar, absorver os detalhes e, mais importante, nunca pensamos porque determinados aspectos de um prédio são tão particulares. Nunca tivemos treinamento formal de urbanismo. Não paramos pra pensar em zoneamento, por exemplo. Certas áreas não podem ter prédios comerciais, certas áreas tem limite na quantidade de andares. Quem mora perto do aeroporto de Congonhas sabe disso.

Por isso quando você tenta desenhar uma cidade, sai parecendo desenho infantil de casinha com sol. Pra ficar realista, precisaríamos ter experiência com urbanismo e arquitetura. Mesma coisa a personagem sentada de pernas cruzadas. A parte que mais chama a atenção de iniciantes são rostos. Por isso perde-se muito tempo só desenhando olhos, e com rostos sempre em posições parecidas, em 3/4.

Pra desenhar um corpo direito precisa estudar anatomia. Todo estudante de medicina no primeiro ano sabe isso, mas pra gente que não é médico, talvez nem fôssemos pensar nisso. Vemos pessoas na nossa frente todos os dias, em todas as posições. Mas quando você parou pra realmente observar uma pessoa? Como o tecido da calça interage com o material da cadeira, como o peso da perna cria dobras, como músculos como o biceps femoral e o soleus se mexem quando dobramos a perna?

Quando falamos de arte, imediatamente pensamos em coisas como a Capela Sistina, o magnum opus de Michelangelo Buonarroti. Contém cenas super detalhadas e difíceis como o Último Julgamento ou a Criação de Adão. É um trabalho de mais de 500 metros quadrados. Sabe quanto tempo levou pra pintar aquele monstro? Quatro anos inteiros, de 1508 a 1512, usando tecnologia do século XVI.

Entenda, quando Michelangelo começou o projeto da Capela Sistina ele tinha 33 anos. Mas começou a estudar arte desde muito cedo, provavelmente pelos 13 anos de idade e já como discípulo de Domenico Ghirlandaio. Depois estudou escultura sob a tutelagem de Lorenzo de’Medici. Por anos, estudou e produziu pinturas, esculturas e já tinha entregado nada menos que a Pieta e a escultura de David antes da Capela.

Naquela época, a arte não era estruturada e bem dividida como hoje. A maioria dos grandes nomes como Michelangelo, chamamos de polimatas. Mas eles mesmos não se chamavam de “polimatas”, isso é um termo moderno. Só hoje que dividimos que anatomia é mais coisa de médico, lentes e ótica é mais coisa de fotógrafo, urbanismo é mais coisa de arquiteto, pincel é mais coisa de artista. Antigamente não existia essa divisão. Existia o problema e que conhecimentos a pessoa achava que precisava pra resolver o problema. Ponto.

Um artista estudava seja lá o que precisava pra melhorar sua arte. Um bom artista é crítico do seu próprio trabalho. Se ele nota que toda escultura que faz não se parece em nada com uma pessoa de verdade, que escolha ele tem? Vamos lá dissecar corpos de pessoas mortas pra investigar como a pele realmente funciona, como os órgãos influenciam o movimento e assim por diante.

Não existe isso que um artista só precisa estudar cores e pincel. Não existe isso que um programador só precisa estudar algoritmos e código. Um bom profissional estuda o que for necessário pra ser a melhor versão dele mesmo. Pra finalizar. Eu estava refletindo sobre animes outro dia. Já notaram como é muito comum ter várias histórias que se passam no colégio? Romance sempre é romance entre estudantes no colégio. Aventuras sempre são com adolescentes.

Tirando o cinismo de achar que tudo é fetiche, a resposta pode ser mais simples do que isso. É só um chute, mas a maioria dos desenhistas de mangá começa a trabalhar logo depois do colégio, ou até abandona o colégio. E esses desenhistas fazem tudo: inventam a história e desenham. O que é a única experiência de vida que eles tiveram até esse momento? O colégio.

Você, iniciante que ainda não entrou na faculdade, ou mesmo recém formado, é a mesma coisa. O que você conhece sobre a vida e o mundo? Nada. Sua única experiência foi o colégio, seus únicos amigos foram do colégio, os únicos problemas que teve que resolver eram relacionados ao colégio. Festas, trabalhos, tudo. Aos 20 e poucos anos, seu conhecimento sobre o mundo é minúsculo.

Parece coisa de boomer dizer isso, mas é verdade: até começar a pagar seus próprios boletos em dia, você ainda é uma criança. Eu já disse isso em outros videos e vou repetir: é impossível ser um empreendedor que vai inovar o ecommerce aos 20 anos. Você nunca trabalhou num ecommerce. É impossível inovar o setor hospilar com 20 anos, você nunca trabalhou como médico. É impossível inovar o setor agrícola com 20 anos, você nunca sequer levantou uma enxada na vida. É impossível inovar qualquer setor com 20 anos, você nunca produziu nada com 20 anos.

E eu volto a esse ponto porque, pra programadores, temos exatamente esse problema quando discutimos modelagem de bancos de dados, modelagem de orientação a objetos, modelagem de arquiteturas. O que significa modelar? Modelar é representar alguma coisa do mundo real de uma forma abstrata. Mas eis o problema: o que você conhece do mundo real? Quase nada. Não tem como modelar alguma coisa que não se conhece.

Antes que alguém vá nos comentários discordar. Óbvio, eu sei que existem exceções. É por isso que se chamam exceções. Com esse disclaimer feito, vale relembrar porque estou cagando regra nesse assunto. Vamos lá, eu trabalhei em projetos de software de vários tipos de negócios diferentes. Telecomunicações, varejo, manufatura, RH, infraestrutura, agências, grandes corporações, startups. Em 30 anos passei por várias indústrias diferentes e por isso consigo comparar o que cada uma faz de diferente. E mesmo assim não posso dizer que sei tudo. Por isso aviso pra desconfiar de qualquer um que queira ensinar sem nunca ter tido experiências similares.

Professores de faculdade, a maioria, não tiveram essa experiência, mas eles estudaram pra profissão de ensino, fizeram pedagogia, psicologia. Eles foram treinados pra ensinar. Alguns melhores que outros, não importa, mas essa é a carreira. Porém, a grande maioria dos que criam cursos online não tem nem perto da minha experiência e nem perto do treinamento de um professor. Portanto o que tem a oferecer? Quase nada. Eles dependem de caçar material na internet, empacotar como se fossem deles e vender pra você com um discurso que parece convincente e promessas que nunca vão ser cumpridas.

Veja o exemplo do Michelangelo que falei. Seu primeiro mentor foi Domenico Ghirlandaio. Quem foi ele? Foi um pintor renascentista de terceira geração, especializado em frescos e fez diversos trabalhos importantes, embora não do calibre do seu aluno. Porém, ele reconheceu esse talento e foi ele quem recomendou Michelangelo pra academia de Medici. Parece ter sido um bom professor, que teve ele próprio uma boa carreira, suficiente pra catapultar seu aluno prodígio.

O ideal é se fosse possível todo aluno ter a possibilidade de ser mentorado por alguém experiente assim. Infelizmente isso não é possível. Não existem mentores suficientes pra todo mundo. Por isso eu digo que o correto, antes de tentar empreender qualquer coisa por conta própria, é iniciar a carreira em empresas de verdade, que tem problemas e soluções de verdade e aprender as outras áreas que não é possível ensinar numa faculdade.

Eu tive vários mentores que nem sabiam que estavam me mentorando. Quando eu tinha que ajudar a resolver um problema de marketing, tive a oportunidade de trabalhar com pessoas treinadas em marketing e entender o básico de como eles pensam. Quando tive que resolver problemas financeiros, tive a oportunidade de trabalhar com pessoas treinadas em contabilidade e finalmente entender coisas cabeludas como impostos. Quando tive que resolver problemas de varejo, tive a oportunidade de trabalhar com pessoas com experiência real em vendas e ver como de fato fechavam negócios. Nenhum curso ensina essas coisas.

O problema de todo programador é que ele assume que a parte mais difícil e mais importante é só a programação, e que todo mundo que não é programador é mais burro que ele. Por isso tem tanta dificuldade de entregar valor. Óbvio, o cliente deveria ter te explicado melhor. Basta o cara do marketing deixar de ser burro e escrever uma especificação melhor que você, o gênio, não precisa perder tempo pensando e pode só escrever seu maravilhoso código em paz.

Falando em ecommerces. Deixa eu dar um exemplo mais concreto. Vou falar de Ruby on Rails porque ainda é a área que eu lembro de mais referências, mas o mesmo exemplo vale pra qualquer outro framework da vida. Um dos primeiros livros que todo mundo que quer aprender Rails usa é o Agile Web Development with Rails. Originalmente escrito pelo lendário Dave Thomas, mantido atualmente por Sam Ruby. Aliás, excelente nome pro autor de um livro de Rails.

Enfim, o livro é um grande tutorial pra desenvolver um mini-ecommerce à medida que explica como funciona o framework Rails. No fim, temos uma aplicação web que mais ou menos se parece com um ecommerce. Mas lembrem-se, o livro não é sobre como fazer o melhor ecommerce, só em como dá pra usar Rails pra implementar uma versão simples de um. Resolvi procurar no Github e achei o código do que é mostrado no livro, pro Rails versão 6.

Usando a ferramenta Tokei, podemos ver que no final do livro, seu projeto vai ter mais de 100 arquivos de Ruby, quase 2.700 linhas de código. Além de 17 arquivos de javascript que dá mais de 1.300 linhas de código. Fora outras coisas como stylesheets em Sass e um monte de arquivos JSON. Parece bastante coisa né?

Por acaso, no ecossistema Rails existe uma plataforma aberta de ecommerce chamada Spree Commerce. Muito boa por sinal. Eu trabalhei com ela anos atrás e até conheci o autor original Sean Schofield. Na época era um projeto monolítico, mas em anos recentes dividiram em sub-projetos. Inclusive acho que a interface web agora é feita em Next.js e o projeto principal virou mais um servidor de APIs. Vamos ver só esse repositório principal com o Tokei e olha só a diferença: temos mais de 1.300 arquivos de Ruby, mais de 92 mil linhas de código Ruby.

Comparado com o projetinho do livro de Rails, estamos falando de uma diferença de 34 vezes o volume de código Ruby. E isso porque não tem nenhuma lógica de front-end, só a lógica de backend mesmo. Se pegarmos só um arquivo, o da ordem de venda propriamente dita, que ambos chamam de “Order.rb”. O do livro é super curto, pouco mais de 50 linhas. No Spree tem mais de 700 linhas e isso porque tem um sub-diretório com outros arquivos que sub-dividem ainda mais a lógica como “address_book.rb” ou “checkout.rb” ou “payments.rb”. É ordens de grandeza mais complexo.

Agora vamos fazer uma conta de padeiro. O livro Agile Web Development with Rails tem mais de 600 páginas. Se consideramos que o produto final dele é 34 vezes menos complexo que o backend do Spree. Pra explicar o Spree do zero, o livro talvez tivesse que ter então 20 mil páginas. Tem idéia do que isso significa? Coloca em perspectiva, os 5 livros de A Song of Ice and Fire, que deu origem ao Game of Thrones, male male tem umas 4 mil páginas. Ou seja, precisaria de 5 vezes o volume de Game of Thrones, uns 20 volumes, pra descrever um ecommerce como o Spree do zero.

Deixa eu complicar mais: um Spree é um ecommerce muito bom, mas nem de longe é o mais completo. Um dos mais antigos e populares ecommerces de código aberto é o Magento. Hoje existe o Magento 2. Ele é feito em PHP e rodando a ferramenta tokei, olha só: são 2 MILHÕES de linhas de código PHP. Mais de 200 mil linhas de Javascript. O Magento sozinho, só no javascript, tem o dobro de linhas de código do que Ruby no Spree que, por sua vez, já era 34 vezes maior do que o ecommerce do livro que ensina Rails.

Se em 600 páginas o livro Agile Web Development with Rails conseguiu explicar uma versão simples de ecommerce que dá 2.700 linhas de código de Ruby, sabemos que PHP e Ruby não são equivalentes, mas só por diversão, o Magento, só em PHP é mais de 700 vezes maior. Seriam 700 livros. Seriam 100 coleções de Game of Thrones pra descrever do zero, no mínimo. Conseguem entender porque eu fico tão puto quando alguém me pergunta se tem algum livro que explica tudo? Não tem, é inviável de ter.

E eu vou piorar a vida de vocês. Mesmo um Magento ainda é pequeno se desse pra comparar os repositórios de código de uma Amazon da vida, com todos os seus sub-sistemas internos. O que eu estou dizendo? Entenda essa verdades: você nunca vai saber tudo. É impossível. E isso que eu descrevi é só ecommerce. Vejam meu episódio sobre SAP e seu ERP que tem meia década de idade e roda no coração de toda grande corporação no S&P 500. Lembram? Só no banco de dados são dezenas de milhares de tabelas. Repetindo, dezenas de milhares de tabelas. É impossível saber tudo.

Se alguém ficou desesperado com esses números deixa eu contar o grande segredo: eu, Fabio Akita, nunca li o código do Spree, muito menos do Magento. Já trabalhei em projetos com eles e com outras plataformas proprietárias. Mas nunca li todo o código deles e esse é o ponto: não precisa ler tudo.

Posso estar enganado, mas me dá impressão que muitos iniciantes pensam que quando fazem um curso ou lêem um livro, ou um tutorial, “como fazer seu próprio instagram” ou “como fazer seu próprio Facebook”, acham que o código que sai no final já é quase a mesma coisa que o Instagram ou Facebook de verdade, faltando pouquinha coisa.

Ou, que o ecommerce que fez no fim do curso já é quase o Mercado Livre. Ou seja, muitos tem a noção bem errada que existe um curso ou livro que vai te ensinar 100% do que precisa saber pra fazer um produto de verdade do começo ao fim. Eu estou afirmando que não tem, não existe, e não seria prático ter. Seriam literalmente 700 livros de 600 páginas e nem isso seria tudo. Se você não consegue visualizar 700 livros, se colocados de pé um do lado do outro daria mais de 2 metros. Eu duvido que você vá ler uma fração disso na sua vida inteira.

Durante todos os videos do canal vim tentando explicar esse conceito. Deixa eu tentar repetir. Quando você faz faculdade de ciências da computação, em nenhum momento vai ter nenhum curso explicando como se faz um ecommerce, ou como se faz um rede social, ou como se faz um aplicativo de fintech, ou de edutech, ou de saúde, nada disso. Você aprende matérias esquisitas, como algoritmos e estruturas de dados, álgebra linear, cálculo, estatística e probabilidade. Mas onde que ensina como fazer um carrinho de compras ou lista de produtos?

No outro lado do espectro, você pula tudo isso e faz cursos numa Udemy da vida “como fazer seu próprio ecommerce” e sai com uma versão parecida com o do livro Agile Web Development with Rails que eu mostrei. Parece que é melhor, afinal, você fez um carrinho de compras e uma lista de produtos. Só que eu acabei de demonstrar que não é uma fração de projetos de código aberto como Spree ou Magento, na verdade, é de 30 a 100 vezes menor.

Mas eu também disse que ecommerces de verdade, como uma Amazon ou Magazine Luiza da vida, são muito diferentes do que tem num Magento. Então, como faz pra saber? Eis o ponto que eu falei sobre mentoria: você só vai saber como um Magazine Luiza funciona trabalhando dentro do Magazine Luiza. Só tem como saber como um iFood funciona, trabalhando dentro do iFood. Não tem outra forma.

Mas aí não é o problema do ovo e da galinha? Como eu vou conseguir trabalhar num Mercado Livre, se nenhum lugar ensina como eles funcionam? É isso que você também não está entendendo. Quando uma empresa dessas oferece emprego, nenhuma espera que você saiba como elas funcionam. Elas esperam sim, que você tenha um mínimo de ferramentas pra conseguir se adaptar ao sistema deles.

Por isso eu fiz videos analisando os códigos que o Twitter liberou, o código vazado do Twitch ou a arquitetura do Ingresso.com. Se não assistiu, depois assistam. Eu mesmo não trabalhei em nenhuma delas, mas é o tipo de raciocínio que é possível fazer gastando algumas poucas horas, tendo o conhecimento de base. No episódio do Ingresso.com eu falei da arquitetura de filas e salas de espera, que empresas como Amazon e outros utilizam. No episódio do Twitter explico como embeddings de álgebra linear ajudam a resolver o problema de relevância e recomendação de tweets.

Com a base de estatística e probabilidade, dá pra interpretar dados de monitoramento e chegar em conclusões corretas sobre comportamento dos usuários no site, baseado nos dados de navegação e compra. Com cálculo, dá pra saber como o sistema deveria se comportar, coisas com taxa e velocidade de resposta quando se aumenta o tráfego e quais estruturas de dados podem beneficiar mais certas partes do sistema. Com entendimento de sistemas operacionais e compiladores, dependendo do tamanho da empresa, dá pra trabalhar numa nova linguagem que nem existia, como já aconteceu até em empresas nacionais, como a Totus.

Com essa base, dá pra começar a derivar o resto do conhecimento. Uma vez dentro do sistema é que começa realmente a viver o dia a dia de operações da empresa. A burocracia fiscal, a correria de fulfillment de pedidos nos centros de distribuição, a logística de entrega, o tempo de resposta pra suporte ao cliente, as regulamentações e mudanças em leis que precisam ser refletidas no software. Com o tempo você vai aprender o que em DDD se chama de “domínio”.

O Domain, em Domain Driven Design, só faz sentido se você sabe o que compõe esse domínio. No exemplo que usei no começo do video, saber que SKU faz parte do domínio de inventário, ou saber que checkout faz parte do domínio de pagamento. E isso que eu acabei de falar não é absoluto. Em outra empresa, checkout pode fazer parte de um domínio maior chamado “vendas”, ou o checkout é tão complexo que pode ser um domínio por si só. Domínio, as tais “regras de negócio”, varia de empresa pra empresa, de projeto pra projeto. Não é uma coisa estática. É uma referência móvel.

Muitos iniciantes se perguntam se deveriam estudar coisas como Design Patterns e DDD logo de cara. E sim, acho que todo mundo deveria ler pelo menos uma vez, por cima, mas com o entendimento que sem experiência real, essa leitura não vai ter muita utilidade. Arquitetura, patterns, domínios, são conhecimentos que emergem naturalmente com experiência. Não é um checklist que dá pra seguir passo a passo em qualquer projeto. Estude uma vez rápido, e mantenha os livros por perto pra consultar pontos específicos, e assuma que seu entendimento inicial vai mudar na terceira vez que ler, na quarta vez que reler.

Se ler só uma vez ou de forma superficial, vai cometer erros que muitos iniciantes cometem. Por exemplo, achar que Bounded Contexts é só microsserviços e resolver tudo com microsserviços. Microsserviço é um estilo de arquitetura, já bounded context é um conceito de design de estratégia em DDD, que delineia as fronteiras onde um model em particular é definido e aplicável. Você pode ter bounded context num monolito simplesmente usando namespaces e módulos, por exemplo.

Ou então achar que DDD é basicamente só Event Sourcing e CQRS ou Command Query Responsability Segregation. Algumas partes do sistema podem realmente se beneficiar de um sistema de eventos imutáveis ou separação de escritas e leituras nos modelos. Em outros lugares vai ser overengineering. Não se aplica tudo de DDD em todos os lugares. Como diria Jack Sparrow, é mais um guideline.

Mesma coisa com Design Patterns ou qualquer outro livro de arquitetura. Não é pra usar tudo que se estudou em todo lugar. Saber onde usar é mais importante do que saber como usar. Uma vez que se descobre onde, o como é fácil. Muito antes de entrar nesse tipo de discussão, comece pelo básico que já falei antes: quantas vezes você já tentou baixar e rodar um Spree ou Magento ou um simples Wordpress?

“Ah, mas eu sou de Python, não mexo com PHP”. Então você é só um idiota. Porque fazer um Magento rodar não é só um problema de PHP, é subir banco de dados. Um postgres não é específico de PHP, em Python também precisa. Precisa subir um NGINX ou Apache. Numa aplicação web de Python também. Precisa saber onde e como guardar segredos como credenciais. Precisa saber como subir servidores de cache, como Memcache. Nada disso é específico de PHP. Toda aplicação web, em toda linguagem, usa os mesmos componentes. Porque você está querendo discutir patterns e arquiteturas se sequer consegue subir uma aplicação na sua própria máquina?

Apesar de um Magento da vida não se parecer com um Mercado Livre, os componentes e arquitetura geral é familiar. Não as linhas de código específico, mas os componentes gerais de infraestrutura, os conceitos de protocolos, redes, sistemas operacionais, configuração e tudo mais. Não é perda de tempo fuçar projetos como esses e nem mesmo as versões mais simples de tutoriais ou cursos, o meu ponto é garantir que vocês entendam que nunca vão ensinar tudo, mas como primeiro passo, tá mais que bom.

Outra coisa importante: um Magento tem 2 milhões de linhas de código hoje. Graças ao poder do Git, que mantém o histórico de tudo, posso facilmente voltar ao passado, pra versão 0.1.0 alpha 89, de agosto de 2014, quase 10 anos atrás, com o comando “git checkout -b teste 0.1.0-alpha89”. Daí podemos rodar a ferramenta Tokei de novo e olha a diferença, ele tinha mais ou menos a metade do tamanho de hoje, menos de 1 milhão de linhas de código PHP.

Podemos voltar pros primeiros commits, do final de 2011, começo de 2012. Não conheço toda a história do projeto. Pelo pouco que puxei no Google, parece que o Magento 1 foi criado em 2007. Uns 4 ou 5 anos depois a comunidade começou o Magento 2, por volta de 2011 a 2012. É o que os primeiros commits indicam, e a primeira versão estável só foi sair mesmo em 2015. Pelo que entendi, o Magento 2 foi um esforço homérico pra modernizar a plataforma.

De qualquer forma, o código inicial que serviria de base pro Magento 2 já tinha nada menos que meio milhão de linhas de código PHP. Comparado com hoje, é “só” um quarto do tamanho. Mas é pra dar uma noção. Levou de 2007 a 2012 pra chegar nesse meio milhão e depois quase 10 anos mais pra chegar nos 2 milhões de linhas de código de hoje. O projeto tem milhares de contribuidores. Não é um projeto que você vai varar um fim de semana e fazer igual.

Mas o importante é entender que todo projeto tem um dia 1 com zero linhas de código. Todo projeto de código aberto, todo grande site como uma Amazon ou Mercado Livre. No dia 1, todo projeto realmente se parece mais com o nível de código que mencionei dos tutoriais. Mas eles não ficam parados. Vão sendo testados no mundo real, feedback de usuários de verdade vão chegando, o código vai sendo moldado às necessidades do mundo real, 10 linhas se tornam 1000, que se tornam 1 milhão de linhas, ao longo de mais de uma década. E até hoje, o Magento não “acabou”, toda semana tem atualizações, novos commits.

Ao longo desse caminho, o Magento, que foi originalmente criado por uma empresa chamada Varien Inc depois virou uma entidade própria. Por volta de 2011 parece que o eBay entrou em cena e adquiriu uma parte da empresa, com objetivo de integrar com o Paypal. Mas em 2015, eBay e Paypal se tornaram duas entidades separadas e o Magento também foi separado. Daí entra a Adobe em 2018 que adquire a empresa. Hoje ela faz parte do Adobe Experience Cloud e pra contribuir no projeto você precisa assinar um acordo de Licença de Contribuidor.

Eis outro exemplo de como o software foi sendo adaptado pra responder a essas ações externas. Em 2007, ela não foi planejada pra fazer parte da plataforma da Adobe. O cloud da Adobe nem existia nessa época. Ninguém sabia que no meio do caminho ela iria desviar pra dentro do eBay e Paypal e nem que iria se separar poucos anos depois. O software vai se adaptando a tudo isso. A mesma coisa acontece com a plataforma de toda grande empresa. É assim que aos poucos vai virando um repositório de milhões de linhas de código. Nada disso é planejado com antecedência.

Modelagem é uma das respostas a esse tipo de coisa. Em algum momento, a prioridade talvez tenha sido Paypal. Em outro momento a prioridade passou a ser Adobe Cloud. Prioridades de desenvolvimento também ditam a arquitetura e arquitetura dita a modelagem. Modelagens que faziam sentido em 2011 provavelmente não fazem mais sentido em 2018. Entendam isso: software nunca está “pronto” ou “finalizado”. Se ele faz sucesso, é um trabalho constante de adaptação e evolução. Modelagem e arquitetura tem que ser respostas a essas evoluções. Elas emergem do software.

Todo livro, tutorial ou curso, vai simplificar isso. Não é um defeito, é uma limitação do pouco tempo. Como ilustrei até aqui, se tentar documentar tudo, precisaria fácil de centenas de volumes de livros. Ninguém ia conseguir estudar tudo isso. Nenhuma das técnicas de nenhum livro de DDD ou Design Patterns tem as respostas do que fazer em cada um desses grandes episódios. Elas servem de base pra adaptação, mas não tem nenhuma resposta pronta pra nenhum problema de negócios.

Do meu ponto de vista, eu diria que livros DDD ou qualquer outro de modelagem e arquitetura servem pra nos dar um vocabulário pra tentarmos nos comunicar. Tudo é abstrato em software. Não temos parâmetros físicos que todos conseguem concordar, como peso, volume, ou qualquer coisa assim. Software se chama software porque não é “hard"ware.

Uma simples classe de pagamento pode significar coisas extremamente diferentes pra programadores com experiências diferentes. Então tentamos racionalizar e normalizar esses conhecimentos via um vocabulário de modelagem e arquitetura pra começarmos a dar passos em busca de algum consenso, em algumas partes.

Pra não ficar só na filosofia, agora eu queria falar especificamente de alguns livros que acho que podem ajudar um pouco. Novamente, não são livros pra ler de cabo a rabo de uma só vez, e nem só uma vez. São livros pra se estudar um capitulo que tenha um assunto que te interessa no momento, voltar quando tiver mais experiência nesse assunto, e durante sua vida profissional ou acadêmica, quando esbarrar nos outros assuntos, vá indo um capítulo de cada vez.

Eu mesmo não conhecia esses livros até pouco tempo atrás, quem me recomendou foi meu sócio Talysson, que é responsável pelo programa de mentoria da minha empresa, ele mesmo um excelente programador. O primeiro livro se chama The Architecture of Open Source Applications. Ele é dividido em dois volumes. Cada capítulo é como se fosse um artigo sobre um projeto de código aberto escrito pelo próprio autor ou alguém bem experiente e reconhecido.

Por exemplo, o capítulo 11 do primeiro volume é sobre LLVM, que eu já expliquei em vários videos aqui do canal, como no video da Apple e GPL. E o autor desse capítulo é ninguém menos que Chris Lattner, um dos melhores engenheiros dos últimos 20 anos. LLVM tá por trás de todos os compiladores e transpilers modernos incluindo shaders de GPUs e programação de tensors pra IA.

O capítulo em si é super introdutório. Se você assistiu meu episódio e outros como o de compiladores versus interpretadores, a maior parte tá lá. Ele não explica tudo, nem explica em detalhes, mas é um bom capítulo pra quem nunca parou pra ler nada sobre o assunto. A intenção é que cada autor explique porque tomou certas decisões de design do software em que trabalhou. Coisas que hoje achamos óbvio, mas que pra época não era tão óbvio assim.

No volume dois, capítulo 14 temos o projeto NGINX, que eu também já falei várias vezes em episódios como Tornando sua App Web mais Rápida. O autor é Andrey Alexeev, um dos co-fundadores do NGINX. E de novo, é um capítulo bem curto, onde ele fala o óbvio: porque alta concorrência é importante, ou porque não usar Apache. Hoje, é óbvio, mas 20 anos atrás não era e ele explica porque o NGINX foi feito da forma como conhecemos hoje.

No capítulo 18 do volume II encontrei um nome conhecido. Luke Kanies, um dos criadores do Puppet. Hoje em dia, quando falamos de infraestrutura como código, lembramos de Kubernetes, Terraform, ou Ansible, mas Puppet foi um dos precursores, quando codificar infra não era óbvio. Eu entrevistei ele pro meu blog em 2009, vou deixar o link nas descrições.

Já no capítulo 15 do volume 1, outro nome conhecido, Francesco Cesarini. Todo mundo da comunidade Erlang e Elixir conhece esse nome, um excelente educador e evangelista. E foi num workshop dele que eu tive meu primeiro contato com Erlang, também em 2009. Você também pode ter seu primeiro contato com ele nesse capítulo. Enfim, todos os autores desses livros são excepcionais. Eu seria feliz de ser uma fração de qualquer um deles.

O terceiro livro dessa série é o The Performance of Open Source Applications. É o mesmo formato, cada capítulo com um autor que é reconhecido no assunto, mas focado na parte de performance. Logo no primeiro capítulo temos Ilya Grigorik falando sobre alta performance de rede no Chrome. Ilya é outro conhecido de longa data da comunidade Ruby, que eu trouxe pra RailsConf Brasil 2009. Daí ele foi pro Google, hoje está no Shopify e ensinou nossa comunidade sobre métricas, como medir, as melhores ferramentas, quais as prioridades de otimização, e ajudou a definir muito dessa área de performance junto com a W3C. Todo desenvolvedor web deveria ler alguns dos artigos dele sobre performance.

O quarto e último livro é um pouco mais prático e pode servir pra vocês se exercitarem em linguagens diferentes. Se chama “500 Lines or Less”, cujo objetivo é desenvolver uma mini aplicação em 500 linhas ou menos. Por exemplo, no capítulo 19, Audrey Tang nos ensina a fazer uma mini planilha, tipo Excel, com Angular.js. Ou Allison Kaptur que ensina a fazer um mini interpretador de Python, em Python. Se estava procurando exercícios, vale explorar esses capítulos. De novo, nenhum deles é uma aplicação completa de verdade, só os princípios pra quem nunca parou pra pensar “hm, como eu faria um servidor web simples do zero?”, esse é o capítulo 22.

Eu não procurei mas acho que nenhum desses livros tem em português. Mas neste site, que vou deixar o link na descrição abaixo, tem tudo gratuito online. Basta abrir seu navegador e começar a explorar. Eu deixaria uma aba permanente só pra ela, pra não se esquecerem de voltar de tempos em tempos. Como disse antes, não é pra ler tudo de uma só vez. Em particular, o “500 Lines or Less”, é pra abrir um editor de texto e realmente tentar codificar, senão não vai servir pra nada. Alguns capítulos vão usar linguagens que talvez nunca tenham tentado, como Clojure. É uma boa desculpa pra experimentar. E mesmo se não gostar, outro bom exercício é repetir o mesmo exercício em outra linguagem.

Todos os livros eu diria que são adequados pro nível junior até pleno. De pleno pra senior, diria que são textos fáceis. E mesmo assim talvez tenha assuntos que vocês não tenham parado pra estudar ainda. Por exemplo, no volume 1 do The Architecture of Open Source Applications, o Russel Bryant fala do lendário Asterisk. Se nunca trabalhou em projetos de voz sobre IP, antes de existir coisas como Zoom ou Google Meet, talvez nunca tenha ouvido falar. Mas muita gente ainda usa. É tipo um PBX digital. Eu mesmo nunca mexi pessoalmente, mas trabalhei próximo de projetos que usavam, então é um pouco familiar pra mim. Só porque uma pessoa é considerada sênior numa coisa, não quer dizer que é sênior em tudo. Em Asterisk eu não sou mais que um junior.

O maior problema no estágio inicial é que você não sabe o que não sabe. Livros como os que recomendei e projetos de código aberto, como um Magento da vida, são ótimas portas de entrada pra molhar os pés e começar a se familiarizar com código mais complexo e mais real do que tutoriais ou cursos. Não tem nenhum problema aprender via cursos, mas não fique obcecado em achar que quantidade de tutoriais ou cursos vai determinar sua qualidade. Porque não vai. Depois de um certo ponto, sem experiência, você vai estagnar ou pior, só ter a ilusão que está aprendendo. E experiência não é só no trabalho. Você nunca vai parar de estudar e nunca vai saber tudo. Essa é a carreira.

Pra saber se aprendeu mesmo, precisa contribuir código em projetos. Primeiro em exercícios sozinho na sua própria máquina, depois, se possível, em projetos de código aberto mais simples, ou já direto em projetos fechados de empresas. Se puder escolher, escolha empresas que tem desenvolvedores sêniors em quem se espelhar, idealmente que podem te mentorar. Mentorar não é professor e aluno, onde você como aluno fica passivo só esperando alguém te ensinar alguma coisa. É se virar pra fazer e alguém te dar orientação e feedback. A melhor coisa é alguém apontar o que você fez de errado quando achava que não tinha nada errado. Ou seja, apontar o que você não sabia que não sabia.

E tire da cabeça que só tem valor conseguir emprego numa empresa de nome grande como Amazon. Não. Qualquer empresa que tenha software é oportunidade de aprendizado. Não importa se o software é “legado”, antigo. Você nunca programou nada real. Não importa se é na lojinha da esquina ou no Magazine Luiza. Todo software é software. Basta não ficar 20 anos no mesmo lugar, fazendo a mesma coisa. Mas também, menos de 1 ano não é proveitoso. Tem que ter um período pra aprender tudo que puder aprender, em particular, tudo que você ainda não sabe que não sabe.

Como disse lá no começo, esse episódio poderia ser um pouco frustrante. Porque não tem uma resposta simples pra dizer como aprender a modelar, ou decidir arquiteturas, ou fazer um bom design de software. Sua versão 1.0 de tudo vai ser sempre ruim, e isso não é um defeito, é simples falta de experiência. À medida que se trabalhar em empresas ou participar de projetos de código aberto e se exercitar mais, os gaps de conhecimento vão ficando aparentes. E você vai começar a finalmente entender o que não sabe, pra conseguir ir atrás de saber.

A idéia não era tentar dar uma resposta definitiva, só abrir os conceitos pros iniciantes terem uma noção melhor do que tem pela frente. E o conceito principal é que você nunca vai saber o que é um “bom software” sem antes fazer muito mau software e lidar com mau software dos outros. Não existe um checklist que define todas as características de um bom software. Bom é relativo ao que se espera daquele software. E tudo que chamamos de modelagem ou design, são meros vocabulários pra tentar descrever essa abstração que chamamos de software. Se ficaram com dúvidas, mandem nos comentários abaixo. Se curtiram o video deixem um joinha. Assinem o canal e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais.

Não se pode ser um bom programador sem entender de verdade como bancos de dados funcionam. E não se pode entender banco de dados sem entender algoritmos e estruturas de dados. E hoje vou mostrar como dos primeiros bancos de dados dos anos 80 chegamos aos SQL e NoSQL atuais.

Este video complementa meu video anterior “Fiz um Servidor de SQL?” e outros videos que vou referenciando ao longo deste. Anote tudo e assistam depois.

Capítulos

• 00:00:00 - Intro
• 00:01:15 - CAP 01 - O que é um Banco de Dados? A era do dBase
• 00:10:04 - CAP 02 - Procurando com Índices - NDX e B-Tree
• 00:18:53 - CAP 03 - Do DBF ao SQLite3 - O banco mais usado do Mundo
• 00:23:42 - CAP 04 - Tudo são Árvores B - A estrutura mais importante da computaçãot
• 00:28:51 - CAP 05 - JSON no SQL?? Você não está entendendo
• 00:31:45 - CAP 06 - Proteção e Consistência - As garantias dos bancos
• 00:35:38 - CAP 07 - Do xBase a Cliente-Servidor - As 3 Camadas
• 00:38:59 - CAP 08 - Programando Errado - Você não sabe usar o servidor
• 00:45:26 - CAP 09 - Constraints - Usando do jeito certo
• 00:48:13 - CAP 10 - Monitorando - Sempre monitore tudo!
• 00:50:23 - CAP 11 - Big Data - Virando gente grande
• 00:53:40 - CAP 12 - Dividindo pra Conquistar - Acelerando seu App Web
• 00:56:28 - CAP 13 - Big Data Parte 2 - Por que NoSQL?
• 01:00:39 - CAP 14 - Teorema CAP - As partes importantes
• 01:07:12 - CAP 15 - Estratégias de Chaves Primárias - Chaves Surrogadas
• 01:11:25 - CAP 16 - Hashing Consistente - Sharding
• 01:18:42 - CAP 17 - O Problema de Cloud - Calculando Precificação
• 01:24:51 - CAP 18 - Recomendação pra Iniciantes - Arroz com Feijão
• 01:27:39 - Bloopers

Links

• Heroku
• Amazon ElastiCache
• Amazon RDS
• Amazon Aurora
• Amazon S3 Glacier Storage Classes | AWS
• Astra DB | DataStax
• Scylla Cloud
• SAP HANA Cloud
• Big Data SQL Cloud Service | Oracle
• Azure SQL Database
• Google Cloud
• Pricing | MongoDB
• Valentina SQLite Server
• Configure Amazon DynamoDB (calculator.aws)
• CAP Twelve Years Later: How the “Rules” Have Changed (infoq.com)
• [Dynamo: Amazon’s highly available key-value store - Amazon Science](https://www.amazon.science/publications/dynamo-amazons-highly-available-key-value-store
• PostgreSQL JSON Tutorial (postgresqltutorial.com)
• GitHub - azadkuh/sqlite-amalgamation: The SQLite amalgamation mirror with cmake

SCRIPT

Olá pessoal, Fabio Akita

Desde que comecei o canal, banco de dados é um dos temas que eu mais queria discutir, mas vim postergando pra poder explicar fundamentos antes. O objetivo não é ensinar SQL ou MongoDB nem nenhum outro em detalhes, é dar perspectiva pra quem está iniciando entender porque diabos existem tantos tipos diferentes de bancos de dados e quando se deve considerar usar um em vez do outro. Vai ser um video mais alto nível, sem tanto código em si, mas sim dar insights pra vocês pesquisarem nas respectivas documentações depois. Vou começar nos primórdios e só na metade vamos começar a cair em SQL e NoSQL. Então, vamos lá.

(…)

Infelizmente, se você estava esperando um video sobre modelagem, modelo entidade-relacional, ORMs, design patterns e coisas assim, ainda não é este video. Objetivo é falar mais o que acontece por baixo dos panos, as tecnologias que formam um banco de dados. Eu acho que modelagem só é efetiva se você sabe como a plataforma por baixo realmente funciona, senão modelagem vira só superstição e você só acha que sua modelagem é boa sem realmente saber o que ela causa por baixo. Tudo que você não sabe como realmente funciona vira superstição.

Sempre falo que uma das vantagens que eu tive, foi conseguir testemunhar as versões 1.0 de quase tudo que surgiu nos últimos 40 anos. Se você pegar um banco de dados moderno, como um DynamoDB da AWS, ou um Postgres, eles tem dezenas de funcionalidades que não são imediatamente óbvios pra que foram criados. Sem saber isso, você acaba tentando usar nos lugares errados ou acha que são ruins, ou acha que você que é burro e não consegue usar.

Pense por um segundo, o que é um banco de dados? À primeira vista poderíamos dizer que é um programa que facilita e gerencia o armazenamento de dados estruturados. Pense um armário com gavetas, cada gaveta com um tipo de formulário. As gavetas seriam nossas tabelas e o armário seria o banco de dados. Acho que é parecido com o que a maioria de vocês deve imaginar.

Pra iniciantes, acho que vale a pena retornar aos fundamentos. Por isso sempre falo tanto que é importante aprender a fundação, como algoritmos e estruturas de dados. O problema é que a estrutura mais simples de aprender e por causa disso comum de usar são listas. Essas seriam as gavetas. Em particular listas ligadas ou arrays puros. E se escolher partir desse ponto, vai ter problemas. Vamos entender.

O banco de dados mais simples de todos, um armário só com uma gaveta, é um mero array em memória com registros, como um struct ou uma instância de uma classe, um objeto. Lembram como um array é estruturado em memória? Um array de inteiros com 10 elementos, provavelmente tem 10 vezes 64 bits ou 8 bytes, ocupando 80 bytes no total. Todo array tem elementos de mesmo tamanho fixo, sempre.

Se eu quiser pegar o 5o elemento desse array, basta contar que tenho 4 elementos antes, vezes 8 bytes, então 32 bytes pra frente, vou achar o 5o elemento. Se eu souber qual posição do array quero encontrar, independe se está no começo ou no fim, o tempo de acesso é o mesmo, tempo constante. O array pode ter 10 elementos ou 10 mil elementos. Leva mais ou menos o mesmo tempo pra acessar qualquer posição.

Quando todos os meus dados cabem na memória RAM, toda operação é simples. Mesmo se eu não souber a posição, na pior das hipóteses faço força bruta via um loop do primeiro até o último elemento, até encontrar. E isso seria de longe, o jeito mais tosco de se procurar alguma coisa numa lista, mas pra conjuntos de dados pequenos, quase ninguém nota a diferença. Mas deixa eu repetir: procurar dados numa lista com um grande loop e if dentro é o jeito mais absurdamente horrendo e inaceitável. Vou repetir de novo pra ficar claro: se você está fazendo um loop pra procurar itens numa lista, você é insano!

Isso porque todo programador, especialmente iniciantes, sempre lidam com poucos dados. É muito difícil entender complexidade de algoritmos e diferença nos tempos de processamentos se só tem cem, mil elementos. Só quando começar a lidar com centenas de milhares, milhões de elementos, que vai começar a entender a diferença. Já vou chegar nisso.

Enfim. Imagine que lá no começo da computação, todo mundo lida com poucos dados comparado com hoje. Por isso as primeiras soluções são simples. Um array com elementos de tamanho fixo é a forma mais fácil de pensar. E quando acaba a memória? Digamos, uma lista de produtos ou lista de clientes num ecommerce? Obviamente não cabe tudo em RAM. Daí temos que pensar em gravar esses dados em disco. E a forma mais simples de fazer isso é o bom e velho arquivo append only, onde vamos adicionando novos elementos no fim do arquivo.

É fácil. Pense num registro como uma struct de C, ou uma classe de Javascript ou Python, só que garantindo que todos os elementos tenham tamanho fixo. Determino uma struct com o primeiro campo sendo o nome completo, com umas 100 letras, onde cada uma é representada por um código UTF-8, de 8 bits, 100 bytes no total. Depois temos um número de telefone, com DDD de 3 caracteres, um prefixo de 3 números como era antigamente e um sufixo de 4 números, mais parênteses e hífen, total de 13 letras ou 13 bytes.

Temos um total de 100 bytes mais 13, ou 113 bytes. O primeiro registro vai ocupar o começo do arquivo começando no endereço zero e indo até o endereço 112 bytes. O segundo registro começa no byte 113 e vai até 225 e assim por diante. Posso abrir o arquivo, ir até o final e gravar mais um registro. E assim fica fácil sair cadastrando novos registros.

De curiosidade, queria aproveitar pra mostrar a segunda linguagem e ambiente de programação que aprendi depois do Basic, quando eu era pré-adolescente. Acho que era 1990 e tinha uns 13 ou 14 anos. Meu pai tinha pedido pro meu tio trazer um PC do Paraguai, era um PC-AT 286 com 1 megabyte de RAM, 10 ou 20 mega de HD. Veio instalado com MS-DOS 3.0 e meu tio tinha deixado também o programa que ele usava pra trabalhar: o dBase III Plus, ainda da antiga empresa Ashton-Tate.

E era só isso que tinha instalado. Não tinha internet naquela época. Eu não tinha livro nem nada. Por acaso um outro primo meu tava estudando isso e me emprestou uma apostila do curso que tava fazendo. Foi meu primeiro PC, então só de ver ligado e ter um teclado que podia usar, em vez de uma máquina mecânica de datilografia, já achava incrível. Minha primeira ideia foi copiar a apostila do meu primo. Eu redigitei tudo do zero acho que no Wordstar.

Este é o Wordstar. Ele tem um aspecto esquisito porque tá configurado no modo de 50 linhas que o VGA permite, em vez de 25 linhas de CGA. Essa versão é uma das últimas que saiu pra DOS, acho que a 7.0, daí tem ajudas que as versões iniciais não tinham, com um menu completo com todas as opções. Senão a única forma de usar era lembrar dos atalhos como control mais P e B pra iniciar modo negrito, daí repetir control P e B pra voltar pro modo normal. Control P e Y pra itálico e assim por diante.

Era tão moderno que tinha até um Preview em modo gráfico pra mostrar como ficaria na impressora. Essa época estávamos na transição do modo texto de DOS pro modo gráfico de Windows 3. Muitos editores de texto atuais como o próprio VS Code ou Obsidian da vida tem modo de ficar focado que deixa o texto no centro e esconde toda distração. São inspirados em editores antigos como o Wordstar. Esse é o editor que o George R. R. Martin diz que usa pra escrever Game of Thrones.

Enfim, pequena tangente pra mostrar como eu copiei a apostila de dBase. Mais pra frente consegui comprar livros de verdade. Acho que nenhuma linguagem comprei tantos livros pra aprender quanto dBase e seu sucessor, o Clipper. Olha só os que ainda guardei. A razão de tanto livro é que antigamente não tinha Google nem Stackoverflow, lembrem-se disso. Depois que surgiu a Web, já não precisei de tanto livro assim.

Abrindo o dBase, tem um REPL, um interpretador de comandos, que nem quando se digita node ou python e dá pra começar a digitar comandos. Mas também tem um sistema de menus aqui pra facilitar. Olha só, posso escolher a opção de criar um novo banco de dados. Digito o campo “nome”, tipo “character” com 100 letras. Depois o campo “telefone”, tipo “character” também, com 13 letras. Vou aproveitar e adicionar um campo de “empresa” com 100 letras. Pronto. Daí quando salvo já me deixa começar a cadastrar.

Vamos lá, quero me cadastrar aqui, “Fabio Akita”, telefone bla bla bla, empresa Codeminer 42. Agora vou cadastrar “Cecil Wayne”, o criador do dBase que depois se tornaria vice-presidente da Ashton-Tate. Finalmente, vamos cadastrar Brian Russell, que criou o compilador Clipper, pra Nantucket Corporation. Nenhuma dessas empresas existe mais.

A Ashton Tate foi adquirida pela Borland que depois viraria Inprise, depois Embarcadero e a divisão CodeGear que ainda mantém o Delphi, se não me engano. A Nantucket iria pra CA ou Computer Associates, que desde 2018 faz parte da Broadcom. Todo o sucesso que eles tiveram nos anos 80 e 90 desapareceram ao ponto que hoje ninguém mais lembra. É um bom lembrete que nada dura pra sempre.

Enfim. Terminei de cadastrar meus contatos. Posso salvar e sair com control + end. Agora estou na tal linha de comando do interpretador. Posso abrir o arquivo do banco fazendo “use contatos”, digitar o comando LIST e olha só, lista o que acabei de registrar. Esse é o avô de todos os CRUDs, o CRUD original no mundo dos microcomputadores. Não o primeiro, mas possivelmente um dos mais populares.

O formato de arquivo que Cecil inventou foi o famoso DBF, literalmente database file. Quando eu era novo, antes de pular pra tecnologias mais novas como SQL Server da Microsoft, na minha cabeça “banco de dados” é o que você chama de tabela. O dBase gravava uma tabela por arquivo e chamava isso de banco de dados. Hoje, banco de dados é um servidor com conjuntos de tabelas num único arquivão. No fim dos anos 80, banco de dados, pra mim, era um arquivo com uma tabela.

Esse arquivo tem um espaço reservado nos primeiros endereços pra metadados, informações como o total de registros e coisas assim. Mas os registros em si tem todos o mesmo tamanho fixo. No exemplo dos contatos, são 100 bytes pro nome, 13 pro telefone e 100 pra empresa, então cada registro sempre vai ocupar 213 bytes. Basta ir pulando de 213 em 213 bytes pra ir avançando pro próximo registro.

Como programador você precisa entender essa estrutura. Digamos que eu queira encontrar o telefone do Brian. Como faz? Como é anos 80, vamos começar do jeito mais simples, ou seja, tosco. Podemos escrever um programinha besta, que vou chamar de “list.prg”. Abro o arquivo com “USE”, limpo a tela e começo a fazer um loop checando que não estamos no fim do arquivo, end-of-file ou EOF como tá aqui.

Daí fico comparando o campo nome do registro atual com “Brian”. E não acharia nada. Isso porque preciso procurar pelo nome exato, então “Brian Russell”. Claro, posso só pesquisar as primeiras letras também, mas é uma operação a mais, por agora vou simplificar. Da linha de comando do DOS podemos chamar o dbase passando esse programa.

USE contatos
CLEAR
DO WHILE .NOT. EOF()
	IF NOME = 'Brian Russell'
		@ 10,10 SAY 'Empresa:' GET EMPRESA
		EXIT
	ENDIF
	SKIP
ENDDO

Nesse exemplo idiota, começa pesquisando o primeiro registro, que é Fabio. Não achou e não é fim de arquivo, então vai pro próximo com o comando SKIP, que é Cecil, ainda não é fim de arquivo, então vai pro próximo e acha o Brian, daí é só pegar o campo empresa, imprimir na tela com esse comando SAY e sair do loop com EXIT.

Esse é o pior caso: onde o que quero achar é o último registro. Imagine um arquivo muito maior, com mil registros. Precisaria ir um a um mil vezes. Todas as vezes. Por isso, esse é jeito mais tosco e mais primitivo de procura num banco de dados. Agora que entendeu isso, prometa que nunca vai fazer desse jeito.

Num computador moderno, esse programa vasculhando milhares de registros ia demorar menos de um segundo. Mas nos anos 80 poderia levar alguns segundos, dependendo de quantos registros tenho. Mas claro, nem nos anos 80 a gente era ruim de fazer desse jeito tosco.

Em dBase mesmo dava pra criar um segundo arquivo, um índice. Basta fazer “INDEX ON NOME TO INDNOME” e vai criar um arquivo separado de índice com extensão “NDX”. E podemos abrir o banco de dados com “USE contatos INDEX INDNOME”. Como já tá aberto podemos só fazer “SET INDEX TO INDNOME”. É assim que podemos ficar mudando de índices dependendo de que campo queremos procurar.

Eu digitei errado o nome da empresa do Cecil, vamos usar SEEK 'Cecil Wayne' e fazer REPLACE EMPRESA WITH 'Ashton Tate'. Pronto, é assim que procuramos e depois modificamos um registro. O comando Seek vai usar o índice, em vez de fazer o loop com comparação como fiz antes. Aliás, esse comando REPLACE serve pra mudar dados dos campos do registro atual. Com SEEK podemos encontrar um registro, mas pra criar um novo, teríamos que fazer “APPEND BLANK” antes, pra “apendar”, anexar um registro vazio no fim do arquivo, daí o REPLACE gravaria os dados nesse registro novo. Esse é o básico.

Esse tipo de índice eu já expliquei no episódio de Árvores e também nos de armazenamento. É uma variante de uma B-Tree. Lembram que falei que árvores são as estruturas mais importantes na computação? O arquivo DBF de banco de dados é mais ou menos como se fosse um array de structs em disco, mas um arquivo NDX de índice é uma estrutura de árvore B. Daí, em vez do tempo de procura ser linear em força bruta com loop um a um, com o índice passa a ser logarítmico, que é uma ordem de grandeza mais rápido e eficiente.

Ou seja, no meu programa de procura tosca via loop e comparação, se cada comparação e skip levasse, digamos, 1 milissegundo, e eu tivesse 10 mil registros e o que eu procuro estivesse no último registro, então no pior caso levaria 10 mil milissegundos, 10 segundo inteiro. Mas se eu usar um índice em B-Tree, com complexidade logarítmica, levaria talvez pouco mais de 10 milissegundos.

Mesmo se eu dobrasse a quantidade de registros, o tempo de pesquisa não iria aumentar muito mais que isso, dado a natureza logarítmica. Dependendo do que estou fazendo, o ganho de performance poderia ser 100 vezes ou mais usando o índice correto. Por isso falamos tanto no mundo de bancos pra sempre garantir que tem um índice correto preparado.

Mas e se eu quisesse agora procurar pelo telefone? Ou pelo nome da empresa? Bom, podemos criar um índice pra cada campo, como INDEX ON TELEFONE TO INDFONE e INDEX ON EMPRESA TO INDEMPR. Note como o nome do índice eu tive que truncar, porque em MS-DOS nomes de arquivos podiam ter no máximo 8 letras. Era uma limitação do FAT16 antigo. O sistema de arquivos FAT que você usa pra formatar SD Cards pra câmera é ou FAT32 ou o mais moderno ExFAT, e não o FAT16 antigo. São compatíveis, mas com limites muito maiores, por isso dá pra ter nomes de arquivos longos normalmente.

Voltando pro DOS podemos listar os arquivos criados. Como disse antes, cada registro vai ocupar aproximadamente 213 bytes. Tenho 3 registros, então teríamos pelo menos 639 bytes. No caso o formato DBF grava mais coisas como cabeçalho de metadados, por isso faz sentido ser 986 bytes. Mas veja cada arquivo de índice. 1 kilobyte cada. Acho que é o tamanho mínimo pra um índice.

Eu fiz um programa besta pra adicionar mais registros falsos só pra aumentar o tamanho dos arquivos. Olha a listagem aqui. A chatice de uma linguagem tão rudimentar quanto dBase III é que ele sequer tem função pra gerar números aleatórios nem tem coisas triviais como calcular o módulo de um número. Então tive que fazer um gerador de números usando só segundos. Não tem nem função pra pegar milissegundos então tenho muitas letras repetidas, mas tudo bem. Olha só como tive que fazer pra calcular o módulo na mão. Daí vou pegando letras da tabela ASCII e concatenando. Super rudimentar.

Gerando 40 novos registros e reindexando, vamos ver o tamanho dos arquivos. O banco de dados, a tabela de contatos em si, com 43 registros agora ficou com quase 10 kilobytes, Pouco mais que 240 bytes por registro, em média. Já os índices, o de nome ficou com quase 8 kilobytes e telefone que é um campo menor, ficou com pouco mais de 2 kilobytes. Empresa é o mesmo tamanho de Nome então ficou com uns 8 kilobytes também.

Pense por um segundo. Os arquivos de índice estão ocupando quase o dobro do espaço da tabela em si. Muita gente pode não entender isso, mas índices ocupam espaço, e não é pouco espaço. Mais importante que isso. Num banco moderno, digamos que a operação de inserção na tabela de um novo registro leve 1 milissegundo. Mas agora digamos que temos esses 3 índices. E atualizar cada um dos índices leve mais 1 milissegundo cada. Agora é um total de 4 milissegundos pra inserir um novo registro e atualizar os índices. O tempo de inserção ficaria 4 vezes maior.

Índices é uma faca de dois gumes. Por um lado podemos acelerar a pesquisa em 100 vezes, talvez mais, mas por outro lado, operações como inserção, atualização ou deleção vão demorar duas vezes mais, quatro vezes mais, dependendo da quantidade de índices que tivermos. Entenderam?

Aliás, índices em dBase, ou mesmo em Clipper, eram super instáveis. Vira e mexe ficavam desatualizados e por isso todo programa que fazíamos naquela época colocávamos no menu uma opção de manutenção. Ensinávamos o operador do cliente rodar de vez em quando. Era a operação pra reindexar tudo do zero, pra garantir que a pesquisa ia funcionar. Quanto maior a tabela, mais demorado ficava reindexar. Felizmente bancos de dados modernos são bem mais estáveis pra atualizar os índices e fazem isso sem precisar de intervenção manual, na maior parte do tempo.

Mas não é só isso. Até agora só falei sobre adicionar novos registros nesse arquivo. Isso é fácil, é só ir apendando, concatenando os bytes do registro no fim do arquivo. Atualizar, também não é tão difícil. Só dar “SEEK” pra encontrar o registro pelo índice e dar “REPLACE” pra substituir com o dado novo por cima do campo desejado. Mas e pra apagar? O que acontece?

Pensa um Array em memória. É uma sequência contínua. Se você quiser deletar um elemento no meio, não tem outro jeito. Precisa criar um novo array e copiar todos os elementos de novo, pra não ficar buraco no meio. Por isso que em memória usamos outras estruturas como listas ligadas. Daí é só mudar o ponteiro do elemento anterior pra apontar pro elemento seguinte. Mas listas ligadas são super ineficientes comparados com arrays, são mais difíceis de navegar, porque não tem endereços contínuos, então não tem como só calcular o offset e ir direto pro elemento no fim, tem que ir navegando ponteiro a ponteiro. É muito lento.

Um arquivo DBF é parecido com um array: não tem como apagar um registro no meio. O que acontece é que cada registro tem um bit separado só pra dizer se é válido ou não. Quando manda apagar, ele só grava esse bit de zero pra um, daí quando tentamos dar SEEK ou navegar pra frente com SKIP, ele vai ignorar se esse bit estiver marcado como apagado. Isso torna a operação simples com um trade-off: o espaço no disco vai continuar sendo ocupado, o arquivo não diminui de tamanho.

Por isso que além de reindexação, que é regerar os arquivos de índice, na tal opção de manutenção, também tinha outro comando: “PACK”. O que o PACK vai fazer é a mesma coisa que com um array: gerar um novo arquivo DBF do zero e copiar todos os registros não apagados pra lá, e no final apagar o arquivo antigo. Esse é o único jeito de recuperar espaço do disco. Mas pra isso precisava ter quase o tamanho do arquivo original de espaço livre sobrando pra fazer a operação.

Isso existe até hoje em bancos de dados modernos. Quem já mexeu com SQLite3 ou Postgres deve ter esbarrado no comando “VACUUM”, tem até a opção de AUTO VACUUM pra ele fazer isso sozinho sem termos que enviar o comando manualmente, mas em essência é a mesma ideia do comando PACK de dBase: recuperar espaço em disco e desfragmentar os dados no disco pra ficar mais eficiente e ocupando menos espaço.

Falando em SQLite3, ele seria o sucessor espiritual do dBase e Clipper. É provavelmente o banco de dados relacional mais usado no mundo. Está em todo lugar. Se você tem dispositivos smart com Android da vida, os aplicativos rodando dentro certamente usam SQLite3. O roteador da sua casa, sua Smart TV, sua Alexa, seu smart watch, tudo tem SQLite3. Qualquer aplicativo que precise armazenar qualquer tipo de dados, normalmente usa SQLite3.

A razão disso é por ser extremamente pequeno, altamente eficiente, flexível e portável. O código fonte dele é em C super limpo, que pode ser facilmente portado pra rodar em qualquer sistema operacional, seja Linux, seja Mac e pra qualquer arquitetura, seja x86 no seu PC, seja ARM na sua SmartTV ou console de videogame. Cabe tudo num único arquivo de C com poucos page down e oferece uma linguagem compatível com SQL. É muito bem feito, um dos melhores e mais úteis projetos de código aberto de todos os tempos. Se você é estudante de C, vale a pena explorar o código fonte, não é tão difícil de entender.

Isso me leva ao episódio onde mostrei o que seria uma introdução de como fazer uma linguagem similar a SQL e eu usei justamente um trecho da gramática de SQL do SQLite3. Só que por baixo fiz ele acessar uma estrutura em memória de Javascript. Poderia ser um arquivo DBF como de dBase e Clipper que acabei de mostrar. A diferença é que em vez de comandos como APPEND, REPLACE, USE, SKIP que mostrei até agora, poderíamos oferecer uma versão com SELECT, INSERT ou UPDATE.

O formato DBF é usado até hoje em muitos lugares. Um Pandas de Python tem capacidade de carregar e manipular DBF. A linguagem R pra cálculo numérico também consegue entender DBF. Linguagens como Javascript, Java, C#, todos tem bibliotecas que conseguem carregar DBF. É um formato legado que ainda é usado, por ser super simples, por ter sistemas legados em indústrias antigas. Obviamente, ninguém deveria iniciar um novo sistema dependente desse formato, pra isso existem coisas mais modernas, como o próprio SQLite3.

SQLite3, como dBase ou Clipper, não depende de ter um servidor de rede pra servir os dados, nem clientes complicados. Ele abre o arquivo e você manipula diretamente. Por isso é tão pequeno e eficiente. Existem opções pra oferecer SQLite3 em rede, mas o foco dele sempre foi rodar localmente. Acho que exige menos de 1 megabyte de RAM pra rodar, talvez faixa de meio megabyte, o que é ridiculamente pequeno. Muitos programas de Clipper dos anos 90 precisava mais que isso.

dBase, Clipper, FoxPro é o que chamamos da família de linguagens xBase, que suportam o formato DBF. Existe uma versão mais moderna de Clipper de código aberto que é o Harbour e seu fork, o xHarbour. Não sei se alguém usa, mas serviria pra portar antigos programas xBase pra rodar em plataformas mais modernas além de adicionar funcionalidades modernas como orientação a objetos e capacidade de se conectar em bancos SQL modernos. De novo, não recomendo começar nenhum novo projeto neles. Qualquer Python da vida, conectando num SQLite3 ou Postgres vai ser melhor.

Tecnologias dos anos 80 eram limitados pelos poucos recursos que a gente tinha. Os processadores eram super lentos comparados com hoje. Estamos falando de milhares de vezes mais lento. Os programas precisavam ser super eficientes, porque qualquer operação fora do lugar roubava recursos escassos, seja de CPU, seja de RAM. Eles precisavam rodar em menos de 640 kilobytes de RAM, em 15 megahertz ou menos. Qualquer processador porcaria de hoje em dia tem 2 ou mais núcleos, cada um com pelo menos 1 gigahertz. Olha a diferença.

Eu mencionei que o sistema de arquivos FAT16 do MS-DOS da época só suportava arquivos de 8 letras mais 3 de extensão. Não tinha memória suficiente pra suportar estruturas de dados maiores que isso. Mais importante: não tinha processamento sobrando pra garantir a integridade dos dados. Coisas como calcular o checksum ou fazer hash dos arquivos. Pros anos 80 seria muito pesado. Por isso disquetes em FAT16 costumavam falhar, arquivos ficavam corrompidos, dados se perdiam.

Mesma coisa pro formato DBF. Era comum esses arquivos se corromperem. Backup era essencial. E backup naquela época era mandar fazer uma cópia num disquete no fim do dia. Toda lojinha da esquina, que tinha um programa em Clipper pra controlar estoque, fornecedores, contas a pagar e a receber e coisas assim, sabia que precisava fazer isso. Fiz alguns programas desse tipo no começo dos anos 90.

No SQLite3, o formato de arquivos reflete essa diferença. Pra começar não é um arquivo append only como DBF, onde vai simplesmente gravando um registro na frente do outro e navegando via offset de endereços. Ele adota uma estrutura de árvore B, uma B-Tree. Não só no índice mas no banco de dados em si. Aliás, no caso do SQLite3, tem um único arquivo que contém várias tabelas, em vez de cada tabela ser um arquivo separado.

Internamente não vai alocando registros e sim páginas. Páginas são como ranges, ou intervalos de endereços. Por exemplo, a página 1 pode ser do endereço 1 até 500, página 2 do endereço 501 até 1001. Páginas contém registros, ou linhas de uma tabela. As páginas são organizadas numa árvore B e os registros são nós folhas, leaf nodes, dentro das páginas.

Nos episódios de árvore, de sistemas de arquivos e de SQL eu falei sobre B-Trees e suas variantes como B+Trees, que sistemas de arquivos modernos como ZFS ou BTRFS utilizam. Tudo no seu sistema operacional é alguma variante de árvores, em particular árvores B, por isso falei que era importante saber como funcionam. No caso do SQLite3 tanto o banco de dados propriamente dito, quanto seus índices, são variantes de árvores B. Elas são muito eficientes. Vamos recapitular.

Primeiro de tudo, o B não é de binário. Árvore binária é um tipo de árvore mas não é b-tree. O B não tem uma definição definitiva mas pense como “balanceada”. Uma característica importante é se auto-balancear. Todos os nós folha tem a mesma profundidade. Isso significa que não importa qual chave tá procurando, leva mais ou menos o mesmo tempo pra acessar qualquer nó. Isso é importante porque o tempo de “seek” ou procura num HD mecânico custa tempo. Uma árvore B minimiza a quantidade de operações de procura.

Árvores B tem alto fan-out, ou seja, são feitas pra cada nó interno poder ter um número grande de nós filhos, que é a ordem da árvore. Isso ajuda armazenamento em disco porque permite uma grande porção dos dados ser escrito tudo numa única página. O jeito antigo do DBF de ir alocando um registro de cada vez no fim é bem ineficiente e gera muita fragmentação. Alto fan-out significa que muitas chaves podem ser acessadas de uma só vez numa única operação de procura em disco. É melhor pegar uma chave que não precisava junto do que ficar procurando aleatoriamente por todo o disco.

Operações de inserção e deleção são muito eficientes. O algoritmo que mantém a árvore balanceada, e eu mostro uma versão disso no video de árvore, é super eficiente. Quando uma nova chave é inserida ou apagada a árvore é re-balanceada, pra garantir a propriedade dos nós folha terem sempre a mesma profundidade. E é muito estável mesmo com a árvore crescendo muito. Um banco de dados de SQLite3, que é super pequeno, aguenta um arquivão que pode teoricamente atingir até 280 terabytes.

Operações que pegam vários registros de uma só vez, tipo um SELECT WHERE da vida ficam mais eficientes, pela propriedade de vários registros estarem juntos numa mesma página. Com poucas operações de disco dá pra pegar todas elas ordenadas de uma só vez. Então, coisas como listagens e montar relatórios, tende a ser muito mais eficiente do que num DBF antigo. Tudo que você pedir que seja ordenado e sequencial, tende a ser eficiente pelas propriedades de páginas que expliquei.

Eu sempre ouvi que ninguém deveria tentar fazer um banco de dados do zero sem ter visto como um de verdade funciona por baixo, e esse é um dos motivos: operações em disco, especialmente mecânico, custam caro. Hoje custam caro, mas nos anos 80 ou 90 eram bem mais rudimentares. Um HD moderno, como meu IronWolf de 12 terabytes vem embutido com 256 megabytes de memória RAM. Não tinha PC nos anos 90 com tudo isso de RAM. Sem cache, as operações são mais custosas, porque realmente precisa colocar a cabeça em cima do disco de verdade.

Aqui estou especulando porque realmente não me lembro se era esse o caso, mas por exemplo, eu reservaria espaço no começo do disco pra colocar coisas como metadados, índices e os dados em si começariam a ser gravados depois. Como se eu tivesse uma partição C:, mais perto do centro do disco físico, onde as operações são mais rápidas do que perto das bordas dos discos. Daí numa partição D: ficariam os dados em si.

Aliás, acho que é por isso que antigamente a gente particionava o HD, no C: ficava o sistema operacional, pra garantir que no boot o disco trabalhe menos e seja mais rápido, daí os dados e programas ficam no D:, mais longe do centro do disco. Mesma razão de hoje em dia deixarmos o boot num SSD ou NVME, que é muito mais rápido, mas sua biblioteca do Steam colocamos num HD mecânico separado. Sempre é um trade off entre mais performance ou mais espaço.

E não só SQLite3, claro, qualquer banco de dados moderno, como Postgres, Oracle, SQL Server, e até bancos não relacionais, como MongoDB, Firebase, Dynamo, Cassandra. E não só bancos de dados como sistemas de arquivos como ZFS ou BTRFS que já mencionei, todos usam alguma variante de árvore B, exatamente por todas essas propriedades. Tudo que lida com gerenciamento de dados, usa árvores B.

Porra Akita, mas um MongoDB não grava tudo em JSON? Eu mando JSON e ele me devolve JSON, portanto JSON deve ser o formato mais eficiente, não? Sério, se você for bem iniciante eu deixo isso passar, mas se algum programador pensa assim, realmente não entende nada de programação. JSON é um formato de consumo, não um formato de armazenamento. É um formato de tradução pra facilitar a vida mas é altamente ineficiente. Eu isso no episódio que falo do código do Twitter.

Primeiro, não é JSON, internamente os nós filhos são gravados em BSON que ele chama de Binary JSON, é um formato binário, como Protobufs do Google. Segundo, é internamente organizado numa B+Tree, ou árvore B+, onde os valores propriamente ditos são gravados direto nos nós folha no fim da árvore, diferente de uma árvore B pura que só tem os ponteiros.

O objetivo todo do episódio onde eu fiz um SQL em cima de um array de javascript, foi pra demonstrar que ter SQL não descreve nada de como é o banco de dados por baixo. Mesma coisa no MongoDB: a linguagem e formato de dados, como JSON, que se usa por cima, não diz nada sobre como é a arquitetura por baixo. Tanto que um Postgres, via SQL, pode devolver os dados em formato JSON se você quiser. É só uma tradução. JSON em si não significa nada pra nenhum banco de dados. Eles só precisam escolher exportar ou importar dados nesse formato. É só um formato, como XML ou CSV ou Excel.

Todo formato de dados de consumo como esse vai exigir um passo de importação pro formato interno binário de verdade, ou exportação pra esse formato. Então se você faz um “SELECT *” da vida num banco, primeiro ele vai puxar todos os registros no formato binário dele. Isso vai ocupar um X de memória. Daí você escolhe que quer em formato JSON, então ele vai precisar de mais um tanto Y de memória, maior do que X, pra fazer essa tradução. É um processo de serialização e desserialização, e sempre vai exigir o dobro de memória pra ter essa conveniência.

Por isso que comunicação de um serviço com outro serviço, deveria ser sempre utilizando protocolos binários compatíveis entre eles, por exemplo, protobufs. Evitando ao máximo fazer tradução de dados, especialmente em formato texto. O formato de dados do SQLite3 não tem nenhuma relação com ele ter capacidade de receber comandos em SQL. Não existe um banco de dados “SQL”, existem bancos de dados que entendem a linguagem SQL, só isso. Internamente todos são implementados de formas diferentes pra determinados cenários e casos de uso.

Um SQLite3 é ótimo pra usar numa SmartTV, já um Postgres ou MongoDB da vida, nem tanto. Eles foram feitos pra rodar em servidores. Existem até projetos pra rodar SQLite3 em servidores, mas de novo, não foi feito pra isso. Use a ferramenta certa no lugar certo. Só porque você consegue arrancar um parafuso da parede com um alicate, não quer dizer que deveria, acha a porra da chave correta.

Internamente, todo banco de dados vai ter um formato de arquivos de armazenamento como um DBF, ou mais corretamente como o formato de um SQLite3, e formato de arquivos de índice. Todos vão ser alguma variante de árvore B ou árvore B+. Além disso temos mais coisas modernas, no caso do SQLite3 vai ter um outro arquivo com nome terminando em “wal”, de write ahead log. Isso é outra coisa que sistemas de arquivos como FAT não tinham, mas todo sistema moderno como NTFS ou ext4 tem: um journal.

Pra economizar recursos, aquele comando REPLACE que eu mostrei lá no começo com dBase, escreve por cima do registro antigo no arquivo DBF diretamente. Isso é péssimo. Porque digamos que estamos fazendo uma atualização em massa em todos os registros do arquivo. Colocando o prefixo 9 em todo telefone que é de São Paulo, lá em 2012. Agora digamos que no meio dessa atualização acabou a luz e o computador reboota. Fodeu.

Isso era comum antigamente e significava que muito provavelmente o arquivo ficou num estado corrompido e eu perdi algum dado. Hoje em dia não se faz mais isso. Existem diversas estratégias, mas o SQLite3 escolheu um log de escrita pra frente ou write ahead log. Ele primeiro escreve as modificações nesse arquivo separado de log, depois que termina, troca um pelo outro. Bem simplificado é como se eu tivesse um arquivo chamado “contatos” daí tenho uma cópia dele chamado “contatos-wal” e as atualizações eu faço nesse segundo arquivo. Se tudo correu bem até o fim, agora troco um arquivo pelo outro.

É um pouco mais avançado que isso, mas só pra ter na cabeça a idéia. Se acabar a luz e o segundo arquivo estragar, ainda tem o original intacto. Além disso, se precisar fazer pesquisas, posso pesquisar no original enquanto a transação não acaba no segundo arquivo, em vez de ficar travado tendo que esperar até todas as operações acabarem. Todo banco de dados tem algum mecanismo desse tipo, mais sofisticado pra ter o menor tempo de trava quanto possível e garantir que nunca nenhum dado vai ser corrompido.

É um tipo de mecanismo de COW ou Copy on Write, como o sistema de arquivos BTRFS também tem em Linux. Por isso que é bem incomum hoje em dia perder dados. Mesmo o Windows tem NTFS, que protege razoavelmente bem. Qualquer Linux mais vagabundo usa pelo menos ext4, que tem suporte a journaling. Pra perder dados hoje, você precisa estar usando um hardware muito do vagabundo, como um SD card de câmera.

SD card é um hardware de armazenamento que foi feito pra ter grande capacidade e ser super barato. Ele foi feito pra tirar fotos, gravar videos e logo em seguida transferir pra um computador. Não foi feito pra deixar lá guardado pra sempre. Não é confiável e podemos perder dados do nada, especialmente nos modelos mais baratos. SSDs baratos de Aliexpress, mesma coisa, mas nesse caso porque são fraudes mesmo, fabricados pra falhar. Cuidado com isso.

Outra característica que bancos relacionais trouxeram foi esse conceito de transação e ACID, de atomicidade na operações. Ou todas acabam com sucesso ou nenhuma acaba. De consistência, por exemplo, regras de unicidade, chaves estrangeiras, e tudo mais. Os dados precisam sempre seguir essas regras, sem exceção. Isolamento, ou seja, se um conjunto de transações roda em paralelo, o resultado tem que ser o mesmo se eles tivessem rodado sequencialmente. O banco não pode ficar num estado inconsistente. E durabilidade, se a transação diz que gravou o dado, podemos acreditar que realmente está fisicamente no disco.

Caso um erro aconteça, como a famosa falta de luz, o banco precisa voltar pro último estado consistente conhecido. Nunca pode continuar operando num estado inconsistente. Cada banco implementa isso de formas diferentes, mas no geral significa que podemos confiar nos dados num banco de dados relacional. Seja um MySQL ou Posgres ou SQL Server, no geral, implementam bem essas características. Mesmo o pequeno SQLite3 faz isso. Um dos jeitos mais toscos é simplesmente bloquear o arquivo todo pra cada transação, esperar completar com sucesso e só aí liberar pra outras operações. Mas claro, isso seria altamente ineficiente.

Mas era assim que bancos de dados xBase, DBF funcionavam em rede nos anos 90 quando começamos a usar placas de rede em MS-DOS e fazer pequenas redes usando ferramentas da antiga Novell ou o Windows 3.1 for Workgroups ou o venerado OS/2 da IBM. Na prática, um computador era elegido como um servidor de arquivos, esses arquivos DBF e NDX eram compartilhados em rede, e todos os outros computadores na rede enxergavam os mesmos arquivos.

Cada computador tinha a mesma versão do programa em dBase ou Clipper ou FoxPro instalado. Se algum tivesse uma versão mais antiga, era caos. A consistência, as regras, dependiam totalmente da versão do programa instalado em cada máquina. A atomicidade era mais ou menos garantida por um sistema de lock. Quando um programa quisesse inserir um registro novo, ele travava o acesso àquele arquivo. Se um segundo computador tentasse ler, recebia um erro que o arquivo tava ocupado, e precisava esperar.

Isso nem sempre funcionava. E se o arquivo DBF, sozinho numa única máquina tendia a se corromper, porque não existia nenhum sistema de proteçõ como journals, imagine em rede. Corromper arquivos era rotina. Experimenta esquecer de fazer backup no fim do dia, certeza que no dia seguinte ia dar pau e corromper alguma coisa. Sistemas de arquivos em rede como Novell era uma puta gambiarra feita em cima do DOS, com tecnologias super imaturas.

Hoje usamos protocolos de internet como TCP/IP, mas naquela época usávamos protocolos mais rudimentares como IPX/SPX e NetBIOS da Microsoft. Verdadeiras porcarias. E mesmo a tecnologia de redes em si, hoje usamos Ethernet de 1 gigabit pra cima, antigamente eram cabos coaxiais que nem de TV a cabo, que male male, faziam 10 megabits. Perdiam pacotes, corrompiam dados e assim vai.

Com a migração de MS-DOS pra Windows e da arquitetura de 16 bits pra 32 bits, ganhamos até 4 gigabytes de RAM pra trabalhar, sem precisar fazer gambiarras de memória em DOS como eu explico no episódio dos 640 kilobytes. E com isso, em vez de cada programa em cada máquina da rede, tentar acessar diretamente os arquivos de dados, eles passaram a conversar com um software servidor. Dessa forma, só um software tinha acesso direto aos arquivos e todos os outros, programas clientes, conversavam com esse servidor usando algum protocolo, com alguma linguagem, no caso o SQL.

Essa foi a era de programas feitos em Visual Basic ou Delphi, conversando com bancos de dados servidores mais modernos como SQL Server, que tinha T-SQL, ou Oracle, que tinha PL/SQL ou alguns mais de nicho como o Interbase da Borland, que era o padrão pra quem usava Delphi. Em vez de cada programa cliente ter que controlar a integridade dos arquivos, melhor terceirizar isso pra um servidor. Os clientes só falam “ow, grava isso pra mim” ou “ow, pesquisa isso pra mim” e o servidor se vira. Isso aumentou muito não só a escalabilidade mas também a estabilidade. Se um cliente manda uma operação não suportada, o servidor pode só recusar, em vez de tentar executar e corromper arquivos.

SQLite3, oficialmente não tem um servidor. Mas tem gente tentando fazer um sei lá porque. Tem um projeto chamado ValentinaDB que faz isso. Não vejo nenhuma vantagem. Se você quer um banco de dados SQL, formato cliente-servidor, use um de verdade, que é maduro, como MySQL ou Postgres. Use SQLite3 pra programas que precisam de dados localmente, como seu roteador de internet que já dei de exemplo.

Quando temos o formato de um servidor, temos algumas vantagens e algumas desvantagens. A primeira é que a velocidade vai depender da qualidade da rede. Tudo que roda localmente sempre é mais rápido. Em rede você precisa pegar o resultado, quebrar em pacotes, rotear esses pacotes, ir recebendo, processando um buffer, e só aí vai ter os dados.

Podemos escolher ir recebendo e já processando os dados localmente, ou podemos escolher esperar receber a resposta toda e só depois fazer alguma coisa. É a diferença de receber tudo de uma vez ou usar técnicas de streaming. E aí depende da sua pesquisa. Se for tosca e mal feita, e mandar tipo um “SELECT *” pra uma tabela de 10 gigabytes, sem usar streaming, boa sorte, vai ocupar toda a memória da sua máquina e mais o swap em disco.

Isso é o que iniciantes tem mais dificuldade de entender: os dados que pedem precisam ir pra algum lugar. Nada é de graça em computação. O trabalho principal de um programador é justamente administrar os recursos da máquina da maneira mais eficiente possível. Por exemplo, digamos que preciso montar um relatório em PDF de todas as vendas do mês. Vou fazer tipo um “SELECT * FROM ORDERS WHERE created_at > date() - 30”. Essa é uma pesquisa rudimentar que filtra todas as ordens criadas nos últimos 30 dias. Faz de conta que vai devolver 500 ordens.

Digamos que cada uma dessas linhas consuma 500 bytes, só meio kilobyte. Se eu puxar tudo de uma vez do banco e colocar num array em memória, vai ocupar 250 megabytes. É bastante coisa. Daí abrimos uma biblioteca qualquer pra montar PDF e converter essas linhas em um documento PDF em memória. Pra simplificar o exemplo, digamos que cada linha no PDF também use 500 bytes. Significa que no fim da operação, vou estar consumindo 500 megabytes na memória, meio gigabyte, metade com os dados que vieram do banco e metade com o PDF.

Qual o jeito certo? Depende, talvez seja esse mesmo. Existem técnicas se quiser otimizar. Um dos jeitos é escolhendo uma biblioteca de PDF que suporte escrever direto pro disco em vez de acumular tudo em memória. Por exemplo, em Java tem a biblioteca PDFBox da Apache. Podemos ir salvando incrementalmente uma página de cada vez pro disco. Digamos que cada página tenha 20 ordens, então só vou precisar de aproximadamente 10 megabytes na memória por vez.

Além disso podemos ir recebendo uma linha de cada vez do banco, e montar uma linha no PDF e descartar essa memória, daí recebo a próxima linha e faço a mesma coisa, sem acumular tudo. Em resumo, significa que de memória de trabalho precisaria, no máximo, ter uns 10 megabytes pra montar uma página de PDF e mais meio megabyte por linha que recebo do servidor de banco de dados, um total de 10 mega e meio.

Aí não importa se o relatório vai ter 100 ordens ou 1000 ordens, sempre vou usar o máximo de 10 mega e meio de cada vez, e não 500 megabytes pra 500 ordens ou 1 gigabyte se for mês de natal e tiver 1000 ordens. Esse é seu trabalho como programador: encontrar o teto máximo que realmente precisa e limitar o uso de recursos. Só assim é possível escalar. O jeito amador é ir usando cada vez mais memória à medida que os dados vão aumentando de volume. Sempre pense em jeitos de usar um teto fixo de memória e processamento, independente de quantos dados vai processar.

Quando falamos que é importante entender SQL direito, primeiro é pra aprender a fazer queries ou pesquisas, SELECTs que devolvam a menor quantidade de dados quanto possível, porque cada dado extra que vier e não usarmos, vai desperdiçando memória e processamento. Mas também precisamos entender algumas noções como, se vamos escrever ou atualizar dados, é melhor mandar os comandos todos de uma só vez do que mandar um de cada vez, esperar um por um terminar e confirmar antes de mandar o próximo.

Aquele exemplo que falei de adicionar o número 9 na frente de todo número de telefone de São Paulo em 2012. Digamos que tenha 100 mil usuários na minha tabela. O jeito mais tosco possível é fazer um programa que conecta no banco e primeiro faz um “SELECT *” e devolve todo mundo pro seu programa. De novo, se cada registro ocupa meio kilobyte e você deu asterisco, mandou voltar todos os campos da tabela, são 50 mil megabytes, 50 gigabytes de dados. Estão entendendo porque isso de puxar tudo pra memória é ruim? É o jeito mais fácil de pensar primeiro, mas é o pior jeito.

Digamos que você tá num servidor parrudo na Amazon, ou num PC igual o meu com 64 gigabytes, e depois de um bom tempo, carregou a tabela inteira em memória. Agora você faz um loop nessa lista e manda dar um UPDATE no servidor pra cada registro. Um UPDATE em uma transação separada, 100 mil vezes. São 100 mil updates, 100 mil alterações individuais de índice, 100 mil commits, e 100 mil esperas de retorno OK do servidor. Lá se vão mais algumas horas esperando.

Qual o jeito certo? Se não ficou óbvio, não precisa dar SELECT de nada. Só fazer um único comando de UPDATE. Algo como “UPDATE SET TELEFONE = “9” + TELEFONE WHERE CITY = ‘Sao Paulo’ AND bla bla” . Um único comando que vai mexer em todos os milhares de registros tudo de uma só vez. Com uma única conexão de rede, um único commit, uma única espera. Não precisa puxar todo mundo pra memória, depois fazer update um a um separado. Entenda esse conceito. A melhor operação trás zero dados do servidor e opera tudo lá.

Do jeito tosco, o programa cliente, digamos sua aplicação web ou mobile, mandou individualmente um comando de update pra cada usuários, esperou a resposta e mandou o próximo, 100 mil vezes. Do jeito certo, seu programa só se conectou uma vez e só mandou um comando, e afetou os mesmos 100 mil registros. A diferença de tempo aqui vai ser na ordem de centenas ou milhares de vezes mais rápido e usando ordens de grandeza menos recursos de memória e processamento. Isso é entender SQL.

Programadores iniciantes aprendendo hoje não tem desculpa. O pessoal das antigas que fazia dBase, até consigo entender, porque naquele formato rudimentar de DBF, não tinha outra forma. Tinha que iniciar um loop “DO WHILE” fazer uma condição com “IF” e aí fazer “REPLACE” no registro atual, dar “SKIP” pra pular pro próximo e repetir 100 mil vezes. Não tinha um servidor que fazia isso sozinho pra gente.

Mas pelo menos naquela época estava tudo rodando localmente na mesma máquina, modificando diretamente o arquivo. É o que o servidor de SQL vai ter que fazer no lado dele. Mas um cliente de banco de dados não tem que fazer loop nenhum se comunicando com servidor registro a registro, quase nunca. Se você tem um loop pra processar dados vindos do servidor de banco de dados, provavelmente está errado. No mínimo é um red flag que precisa ser revisto. Pelo menos lembre disso como regra: se tem um loop, está errado, pense de novo.

Outra coisa que o formato antigo não permitia fazer e você tem que aprender como fazer no SQL são constraints. As tais regras de consistência. Por exemplo, um campo que nunca pode ter valor vazio. Ou um campo que é uma chave estrangeira, um campo numa tabela com o ID primário de outro registro em outra tabela. Chaves estrangeiras garantem que você só está escrevendo IDs que realmente existem. No formato DBF não existia isso, você como programador precisava garantir essas regras manualmente, no código, com um monte de IFs pra lá e pra cá. Em SQL, se tem um monte de IFs, provavelmente deveriam ser constraints.

No mundo moderno de cliente e servidor, significa que muitas vezes essas regras vão ser duplicadas, no cliente pra poder mostrar pro usuário que ele digitou dados inválidos, por exemplo, e no servidor, pra garantir que nas tabelas só tenha dados realmente corretos. Muita gente acha essa redundância ruim, mas eu acho o contrário. Não existe nada pior que dado inconsistente. É melhor checar duas vezes do que não checar. Checagens de consistência que só existem no front-end, e no lado do banco de dados aceita tudo e não checa nada, é a maior porcaria de todas as porcarias. Sempre esses bancos de dados estão em estado inconsistente e sempre vai dar problema.

Crie a tabela no schema com as constraints e validações todas, validação de tipos de dados, validação de tamanho, validação se pode ser vazio ou não, validação de chaves, tudo. Daí faça uma classe do lado cliente que reflete as tabelas usando um ORM, como Hibernate em Java ou um model em Sequelize no Javascript ou model de Django em Python, não importa, repita as mesmas validações. Daí faça um componente em React pro front-end.

Repita as mesmas validações. Puuuts, mas vai repetir 3 vezes? Sim, repita 3 vezes, e faça testes unitários pra cada uma delas e teste de integração que cheque todas ao mesmo tempo. Esse é o seu trabalho. É que nem médico achar que lavar mão toda hora antes da cirurgia é perda de tempo. “Ah, de novo? Eu já lavei de manhã, não precisa de novo”. Lave de novo.

Beleza, tem que estudar SQL. Não só saber sintaxe de SQL, mas o uso de recursos e processamento no servidor. E como otimizar. Nenhum ORM, biblioteca ou framework vai fazer isso pra você. Na verdade, é muito fácil fazer o jeito errado assumindo que o framework vai cuidar de tudo sozinho. Muitos tutoriais, no intuito de serem didáticos, vão te ensinar o jeito menos eficiente. Porque o jeito mais eficiente costuma ser mais difícil de explicar e demonstrar.

E quando você testa com poucos registros, 10, 100, mil, não faz nenhuma diferença. Só quando realmente coloca em produção que vai entender o impacto. Essa é a diferença de crianças e adultos: quem já teve a experiência de perder dados de cliente ou ficar tudo lento que a loja pára de funcionar. Só aí que entende “ahhhh, eu tava entendendo errado”. Pois é. Tente evitar ter que chegar nesse ponto. Nem todo mundo precisa enfiar o dedo na tomada pra saber que toma choque.

Num sistema grande de verdade, numa equipe com vários desenvolvedores, é difícil de checar se todo código foi bem feito ou não. E mesmo sendo experiente, na pressão alguém deixa passar um código que vai usar memória sem precisar ou que vai deixar tudo lento porque botou um loop num lugar que não deveria. Por isso que todo sistema web em produção precisa ser monitorado. Existem diversas ferramentas de monitoramento, seja usando os antigos Nagios ou Zabbix ou serviços mais modernos como Splunk, Datadog, AppOptics, AppDynamics, Dynatrace, Sentry.io, Instana, Azure Monitor e vários outros. Não tem desculpa não usar pelo menos um.

Honestamente eu não sei dizer qual é o melhor hoje em dia, mas na dúvida, sempre usei e continuo recomendando no mínimo instalar o New Relic RPM. Alguns deles são passivos, com os antigos Nagios ou Logtail, porque medem coisas fora da aplicação, como uso de CPU, memória, análise dos arquivos de log. Mas os melhores exigem que você instale uma biblioteca que age como um agente dentro da aplicação. Como tem acesso à memória da aplicação, dá pra fazer análises muito melhores.

Sem entrar em detalhes, podemos avaliar logo depois de um deployment em produção, e ver se uso de memória aumentou e fica constante, por exemplo, ou se continua lentamente subindo até uma hora crashear. Ou podemos monitorar quando uma campanha de marketing entra no ar e vem um volume maior de tráfego. O aumento do uso de recursos está proporcional? Mais importante, podemos avaliar quais partes do código costumam consumir mais recursos.

Com isso podemos focar em melhorias bem mais precisas só nas partes que realmente precisa. Em vez de ficar no achismo de mexer no código sem saber quais reais impactos está causando. Depois que uma aplicação entra em produção, toda manutenção deve ser feita ao redor de métricas. Sempre medir o antes e o depois. Se o objetivo for consumir menos infraestrutura, sempre atacar os principais ofensores segundo as métricas. Se você não consegue medir, certamente não consegue consertar.

No lado do banco de dados, nenhum consegue crescer infinitamente. Como disse, pro caso geral de empresas pequenas ou médias, leva muito tempo pra começar a entrar no território de Big Data. Dezenas ou centenas de terabytes de dados. Um banco de dados relacional tradicional costuma ter os seguintes problemas de escalabilidade:

Primeiro, as tabelas simplesmente estão grandes demais. E quando eu digo grandes, quero dizer centenas de gigabytes, ou terabytes. Por mais que você tenha índices, lembra o que mostrei no caso do DBF e seus índices NDX? O arquivo de índice vai crescendo também. Quanto mais dados for inserindo, maior vai ficando os seus índices também. E vai chegar uma hora que pesquisar índices tão pesados vai ser lento.

A primeira estratégia pra lidar com esse problema se chama “arquivamento”. O certo é ter ou um segundo servidor de banco de dados usado só pra pesquisas e relatórios, mas fora do acesso pra usuários. Digamos que você tenha um ecommerce. Se tiver sucesso e vender muito, sua tabela de ordens vai ter milhões de vendas. Mas pensa: pra que serve dados de ordens antigas? Ordens de usuários que cancelaram contas ou que não entram faz muito tempo? Mova pra um segundo banco de dados.

Assim você tem um banco de dados com dados que realmente seus usuários precisam, mas sem os dados que ninguém nunca acessa. Digamos que sua empresa é uma multi-nacional com dezenas de filiais, dezenas de milhares de funcionários e seu sistema controla tudo de RH: folha de pagamento, benefícios, férias, documentação, e tudo mais. Pra que tem dados de funcionários de 5 anos atrás? Arquive. Mova pra um segundo banco de dados, ou mova pra um backup frio mesmo, como fita ou pra um AWS Glacier da vida, que é tipo um S3 mais barato.

Em qualquer empresa média ou grande, com sistemas de controle internos, vai ter tabelas com dados antigos que não precisam estar lá. É uma prática que de tempos em tempos, todo ano, talvez todo semestre, se faça essa manutenção de limpeza: arquivar, mover dados mortos, pra outro lugar que se acessa menos. Não é apagar. É mover. Nunca é uma boa idéia apagar nada.

Nunca se sabe quando vai precisar, especialmente sua área jurídica. Mantenha dados no mínimo em backup, por no mínimo 5 anos, por causa da lei. A grande maioria das pequenas empresas peca em sequer ter um backup que funciona, quanto mais se preocupar com arquivamento. De novo, não é pra pequenos isso. Pequenos tem que se preocupar com o básico: ter um backup, pra começar.

Mas aí começamos a entrar no território de unicórnios. Uber, Netflix, iFood, MercadoLivre, e várias tech startups que geram toneladas de dados. Digamos que é um iFood da vida. Não só vai ter informações básicas como cadastro do usuário e tabela de pedidos simples, mas vai ter mais dados como quem foi o motoqueiro que fez cada entrega, que rotas usou, que contatos foram realizados durante o percurso, o usuário abriu chat, o que ele falou? É uma granularidade e volume muito maior de dados. Cada pequeno pedido gera megabytes de dados pra depois serem usados pra inteligência, métricas de como melhorar a experiência e tudo mais.

Empresas assim geram gigabytes de dados por dia. O problema não é só o volume de dados, mas a velocidade em que são gerados. Aqui é o território de Data Warehouses, Data Lakes e coisas assim. Em nenhuma dessas empresas vai ter um único servidor de banco de dados com tudo. Sempre vai ter múltiplos bancos de dados, e certamente de vários tipos diferentes pra cada caso de uso diferente.

Simplificando bastante. Do lado do usuários que usa o app, faz pedidos, acompanha a entrega e tudo mais, cada usuário vai gerar dezenas de requisições pros servidores de um iFood ou Uber da vida. As pesquisas sendo feitas precisam ser rápidas. Estamos falando de centenas de milhares de usuários acessando a plataforma ao mesmo tempo. Por mais parrudo que seja um servidor, nenhum aguentaria. Precisa distribuir essa carga em múltiplos servidores.

Quando se instala múltiplos servidores de aplicação, eles não podem todos acessar um único servidor de banco de dados. Iria gerar uma fila enorme e muita espera, muita latência entre requisições. O problema de bancos de dados relacionais como Posgres ou SQL Server é que foram originalmente feitos pra funcionar num único servidor parrudo. A gente escalava o serviço melhorando o hardware da máquina, colocando mais RAM ou colocando uma CPU maior. Eles não foram pensados pra funcionar em múltiplos servidores.

Hoje em dia fazemos um meio do caminho. O maior volume de operações costuma ser pesquisa. Como pesquisa de cardápio. Enquanto faz isso não está gravando nada, só pesquisando. Todos os serviços de bancos de dados SaaS modernos conseguem criar servidores réplica, cópia da original, automaticamente. Assim os servidores de aplicação web conseguem fazer a pesquisa em qualquer uma das réplicas, evitando que se crie gargalo só em um.

Mais do que isso, hoje em dia, um servidor de aplicação vai primeiro fazer a pesquisa num servidor de cache, como um Memcache ou Redis. Se usar uma AWS temos Amazon ElastiCache, que é basicamente Memcache ou Redis como serviço. A aplicação primeiro checa se tem o cardápio do restaurante no cache, se não tiver, aí pesquisa via SQL no banco de dados, grava no cache e serve de volta pro usuário. Muito da carga de pesquisa cai em cima de alguma solução de cache. É impossível criar serviços grandes como um iFood ou MercadoLivre sem ter um volume grande de cache.

Temos dois problemas com isso. O primeiro é que apesar de ser razoavelmente simples de criar servidores de réplica, é difícil de ter múltiplos servidores que aguentem escritas. Operações como INSERT, UPDATE ou DELETE acontecem num único servidor principal. Todas as outras réplicas costumam ser read-only, somente de leitura. Existe um pequeno delay, uma pequena latência, entre a escrita completar no servidor principal e as réplicas serem atualizadas, mas isso costuma valer a pena.

Todo ecommerce da vida, tem essa arquitetura de servidor de banco de dados mestre principal pra escritas, várias réplicas somente de leitura e muito cache, aliado à uma estratégia de jobs assíncronos, com Apache Kafka da vida. Estratégias que já expliquei no episódio do Ingresso.com, do Twitch e do Twitter, depois revejam. Mas mesmo assim, ainda tem casos especiais.

Digamos que temos um serviço de analytics, como um Google Analytics, capturando cada visualização, cada clique, toda operação que usuários estão fazendo em diversos apps, diversos sites, pra gerar monitoramento em tempo real, relatórios periódicos com informações de cada usuário.

Ou imagine que fazemos o software que captura informações vindas de Apple Watch ou Galaxy Watch. Informações de batimentos cardíacos, que cada usuário te manda 1 vez a cada 2 minutos. Apple e Samsung tem milhões de usuários, consegue imaginar esse volume de dados?

Ou imagine uma corretora de criptomoedas como uma Binance, com milhares de transações acontecendo a cada minuto, milhares de pessoas comprando e vendendo sem parar. Ou imagine um servidor de games com Call of Duty ou Fortnite, onde se captura informações de cada ação de cada jogador, cada movimento, cada tiro, cada pontuação. Jogadores do mundo inteiro.

Estamos falando de gigabytes, sendo gerados por minuto. É muito dado. E em cima desses dados, queremos gerar compilados, como o relatório da sua saúde na última hora, ou nas últimas 24 horas, ou do mês. Pra isso tem que ordenar, agrupar, processar e sumarizar gigabytes de dados recebidos por cada usuário. É muito pesado. E não por acaso essa discussão começou a surgir no fim dos anos 2000. Justamente quando redes sociais como Facebook, Twitter, estavam atingindo proporções que nenhuma outra plataforma nunca tinha atingido até aquele ponto. Sem contar o advento de Mobile e da popularização de games online.

Nessas circunstâncias, de fato, o esquema de bancos de dados relacionais atinge seus limites. As pesquisas ficam lentas pelo volume absurdo de dados. Pior, as escritas ficam absurdamente lentas, em parte por causa das garantias que estávamos acostumados a ter, como durabilidade. A idéia de que se mandamos o servidor gravar uma linha e ele diz “ok” significa que aquela linha garantidamente está no disco. Nesses cenários de Big Data, essa garantia se torna um problema.

Quando falamos em Big Data, precisamos lidar com premissas diferentes. Num banco, se sumir uma linha do seu extrato, é um grande problema. Literalmente a conta não vai fechar. Vai faltar um depósito. Vai faltar um pagamento. Dinheiro vai sumir. Pior, se uma linha for duplicada. Mesma coisa num ecommerce. Mesma coisa num sistema com da Receita Federal. Todos precisam de garantias na consistência e integridade dos dados. Por isso existe e sempre vai existir um lugar pra bancos de dados com características que um Oracle, SQL Server ou Postgres oferecem hoje.

Mas pra certos tipos de dados, como analytics, como dados de batimentos cardíacos, como dados de jogos online, mesmo se você perder ou duplicar uma linha dessas, qual o impacto? É baixo ou, no caso geral, nenhum impacto. Estando dentro de uma margem de erro, no fim do dia, você não tá interessado em cada clique individual no seu site, estamos interessados na quantidade geral por dia, por semana, por mês. Não estamos interessados no batimento exato de 5 minutos atrás, mas sim na média por hora, na média durante um exercício ou na média durante o sono. E assim por diante.

É por isso que a partir do começo dos anos 2010 começaram a surgir bancos de dados não relacionais, os NoSQL. Bancos de dados criados pra responder situações diferentes, em particular de Big Data, onde queremos lidar com séries de dados consolidados. Onde velocidade de escrita e baixa latência tem prioridade sobre consistência. Queremos poder escrever em múltiplos servidores ao mesmo tempo, mesmo que durante algum período de tempo, os dados fiquem ligeiramente inconsistentes.

O problema é como distribuir a carga, tanto de processamento pra pesquisa, quanto pra escrita, e como dividir os dados entre múltiplos servidores diferentes, pra permitir escalabilidade? Recapitulando: bancos de dados relacionais funcionam muito bem num único servidor, oferecendo as garantias ACID de atomicidade, consistência, isolamento e durabilidade que todos nós gostamos. Tem opções pra escalar via réplicas somente de leitura e, até certo ponto, replicação bi-direcional, que é sempre complicado. Mas pra situações de Big Data e volumes gigantes de escritas, começa a se tornar uma tarefa complicada, chata e com poucas opções.

Não tem como falar de NoSQL sem mencionar o famoso teorema CAP, proposto por Eric Brewer no ano 2000. Foi um divisor de águas no estudo de sistemas distribuídos e provavelmente você vai aprender no curso de ciências da computação, mas em resumo ele propõe que bancos de dados verdadeiramente distribuídos, ou seja, que rodam em múltiplos servidores, ou múltiplos nós de um cluster, no máximo satisfazem duas de três propriedades: consistência, availability ou disponibilidade e partition tolerance ou tolerância a partição.

Ou temos consistência e durabilidade, mas o sistema não tolera partições, ou seja, alguns nós do cluster podem ficar offline do nada. Isso não é legal porque não é impossível um servidor dar problema, ou mesmo termos que tirar um deles do ar pra manutenção. Então queremos consistência e tolerância a partição, mas aí temos baixa disponibilidade, ou vamos ter o ideal, disponibilidade e tolerância a partição, mas teremos baixa consistência, ou o que chamamos de “consistência eventual”, onde um servidor, por um ligeiro período de tempo, pode não ter os mesmos dados que os outros servidores.

CAP é um teorema e não uma teoria, ou seja, não é uma lei. Quando estudar vai encontrar que nem todo mundo concorda com todos os argumentos, em particular, porque os termos consistência, disponibilidade e tolerância a partição podem ser facilmente mal interpretados. Não tem uma definição muito exata pra cada coisa, e todo mundo sabe o que acontece quando termos ficam abertos à interpretação: ninguém se entende. E isso acontece com frequência, porque na minha cabeça eu quero falar de consistência mas você tá entendendo como integridade. E uma coisa é diferente da outra.

Daí tem o problema da natureza binária. É um dos poucos lugares que de fato não podemos levar ao pé da letra que só podemos escolher 2 propriedades das 3. No caso de termos disponibilidade e tolerância, não significa que não vamos ter nenhuma consistência. Depende se precisamos de consistência forte, onde é obrigatório que todas as réplicas sempre tenham exatamente o mesmo dado correto, ou se podemos ter consistência fraca, eventual, onde durante alguns segundos, os dados diferem entre os servidores. De novo, num banco, não podemos ter um saldo, recarregar o navegador e aparecer outro saldo, mas no exemplo dos batimentos cardíacos, se faltar um batimento durante 1 minuto, não vai ser um problema, não quer dizer que você teve uma parada cardíaca nem nada.

A outra coisa é tolerância a partição. De novo, pense num data center, onde um grande serviço pode ter um banco distribuído em múltiplos data centers, uma dúzia de servidores em Nova Iorque, outra dúzia de servidores em Londres, todos sincronizados, mas aí temos uma pane na internet entreeles. Um link submarino deu pane, caiu a fibra ótica. É raro acontecer, mas acontece. E o sistema tem que saber o que fazer quando acontecer, ou seja, ser tolerante a essa partição da rede.

O problema é que isso realmente é muito raro de acontecer. Nossa infraestrutura dos anos 2020 é mil vezes melhor que nos anos 2000, hardware, redes, infra em geral é muito mais estável. Então nossos sistemas não precisam ser tão agressivos na preparação pra uma situação tão rara. Talvez seja melhor ser otimizado considerando o caso que não vai acontecer, e colocar estratégias de degradação graciosa caso aconteça, como simplesmente uma página de “aguarde alguns segundos”. Mesmo se tiver pane na rede, hoje em dia, se recupera em poucos minutos. Antigamente poderia levar horas ou dias.

Essas são algumas das considerações ao se discutir o teorema CAP. Na prática vamos lidar com alguma estratégia de sharding e alguma estratégia de replicação de dados. Replicação é como acontece com um banco de dados relacional, onde podemos adicionar nós na rede, e eles vão receber uma cópia dos dados, daí cada servidor vai ficar idêntico ao outro, fornecendo redundância e possibilitando dividir a carga dos usuários pra mais servidores.

No caso de banco de dados relacional, por causa da característica de consistência forte, ficamos limitados na quantidade de servidores que podemos ter pra escrita. Num NoSQL, com consistência eventual, qualquer dos nós pode ser usado pra escrita, mas vai levar um tempo pra replicar os dados pros outros servidores. A consistência vai existir, mas vai ser eventual, ou seja, eventualmente vai estar tudo consistente.

Na real, bancos de dados NoSQL como Cassandra ou Dynamo tem como configurar que nível de consistência queremos ter. Mais forte ou mais fraco. Podemos configurar isso dependendo das necessidades. Uma coisa é um pequeno cluster de 3 servidores de Cassandra tudo no mesmo data center, na mesma rede. Outra coisa são múltiplos clusters de dúzias de servidores em vários de data center diferentes, como é a operação do tamanho de uma Netflix.

Bancos como Cassandra ou Dynamo foram feitos mais pra situações onde precisamos funcionar em múltiplos data centers. Dividido em regiões geográficas diferentes. Um no Japão, outro na Europa, outra na América e todos os servidores de todos os clusters sincronizando entre si. Não é uma situação que vamos encontrar todo dia.

Pra maioria das empresas médias, em vez de lidar com uma infraestrutura dessas do zero, o mais prático seria usar um DynamoDB da AWS. Como tudo da AWS, eles gerenciam a maior parte dessa complexidade e podemos só usar. Claro que, por causa disso, o custo por transação é bem mais caro. Mas é esse o trade-off que precisa ser estudado. Ou vamos ter que investir em contratar pessoal especializado em infraestrutura, pra ficar 24 por 7 lidando com hardware, bare metal, num data center.

Ambos Cassandra e Dynamo oferecem capacidades de particionamento e replicação. MongoDB também tem isso, mas ele chama de sharding e replica sets. O que buscamos é a capacidade de conseguir particionar os dados em múltiplos servidores de forma balanceada, e de ter replicação entre alguns desses servidores pra ter redundância. Se um deles tiver uma pane e cair, tem outra cópia idêntica pra continuar servindo os mesmos dados. É muito complexo pra tentar detalhar em um video, mas eu queria que vocês pelo menos soubessem que isso existe pra saber onde procurar depois.

Pra agora é interessante conhecer um último conceito: IDs. Voltando pro exemplo lá do começo, a tabela de contatos feito em DBF com dBase. Lembram que falei que mesmo se eu fizer um índice de nome, precisaria procurar pelo nome completo pra achar? Hoje em dia, em qualquer banco de dados, todos oferecem alguma forma de pesquisar parcialmente ou palavras que soam parecido. É o que um Elasticsearch, Solr ou os recursos de full-text search de um Postgres e outros bancos de dados oferecem. É um índice diferente pra esse tipo de pesquisa em particular. Expliquei um isso no episódio do Twitter, vejam lá depois.

Antigamente, nos anos 80, não tínhamos o poder de processamento pra fazer coisas desse tipo. Em vez de tentar lembrar se “Brian Russell” tem dois “S” ou dois “L”, em muitos casos era mais fácil lembrar o código dele, o ID. Por isso toda tabela a gente se acostumou a colocar esse código. Assim como todo pedido de compra tem um código. Assim como todo indivíduo nesse país é um CPF. Toda linha numa tabela é um código numérico, que usamos como uma chave primária ou, no caso de bancos relacionais, usamos pra fazer uma linha em uma tabela referenciar uma linha em outra tabela, e chamamos esses IDs de chaves estrangeiras, porque ela é estrangeira à tabela.

O jeito considerado errado hoje, principalmente em códigos que vamos divulgar pros usuários, é fazer a chave primária ser um número auto-incremental. Ou seja, começando de 1 e incrementando, próxima linha sendo 2, linha seguinte sendo 3 e assim por diante. Um erro de segurança que foi muito comum antigamente era ter uma aplicação web onde a URL mostra esse código, por exemplo, digamos que tivesse mercadolivre.com/users/1 que é a URL pra página com os dados cadastrais de um usuário.

Num sistema bem feito, quando o usuário faz login, eu guardo o ID dele na sessão. Quando ele navega pra outras páginas privadas, checamos com o ID na sessão antes de mostrar a informação. Se ele tentar acessar a URL que seria de outro usuário, conseguimos invalidar o pedido e devolver um erro 403 não permitido. Esse seria o certo, mas num sistema grande, alguém pode deixar passar um bug e não checar.

Daí alguém de fora, percebendo que estão usando IDs auto incrementais, e o dele é ID 1000, óbvio que significa que tem usuários abaixo de 1000 e alguns acima, e ele vai começar a tentar forçar IDs até alguma página abrir na conta de outro usuário. O certo é não ter esse bug. Mas também não é legal oferecer informação de graça pra estranhos, como a existência de outros usuários com IDs fáceis de achar.

O ideal é usar um número aleatório gigante. Um campo de inteiro de 32 bits pode conter números de 0 até mais de 4 bilhões. Mas se for um inteiro de 64 bits, estamos na ordem de 18 milhões de trilhões. É muito número. Por isso não precisamos usar números sequenciais auto incrementais, use números aleatórios. Vai ser perto de impossível tentar adivinhar o ID de alguém.

Pra isso usamos funções geradores de números como UUIDs. Nem precisamos usar o número inteiro que ele gera, basta truncar e pegar um pedaço e as chances de colisão, ou seja, de escolher um número que já existe na sua tabela, vai ser hiper baixo. E como o certo é criar campos de chave primária com constraint de unicidade, ele não vai deixar inserir um ID duplicado. Existem dezenas de estratégias pra gerar números aleatórios pra IDs, vale a pena parar pra pesquisar e evitar números sequenciais. Chamamos isso de chaves surrogadas. Não é nenhuma lei, mas é uma boa prática. Pra tabelas internas, cujos IDs você nunca vai mostrar em público, aí tanto faz.

Expliquei isso porque em sistemas distribuídos, temos o problema de balancear dados entre diferentes servidores. Quando replicamos dados, estamos fazendo uma cópia dos dados de um servidor pra outro, pra servir de redundância, mas num sistema grande distribuído, queremos dividir o processamento, e isso exige que alguns servidores vão ter dados que outros servidores não vão ter. Deixa eu dar um exemplo besta.

Digamos que trabalho na Receita Federal. Eca. Fazer um único banco de dados com todos os impostos de renda, de todas as pessoas e empresas, num único banco de dados, é bem pesado. Ainda mais se tiver a informação histórica de todo mundo das últimas décadas. Um jeito ingênuo de lidar com isso é manualmente dividir os dados. Por exemplo, posso fazer um servidor com dados da região Sudeste, outro servidor só pra região Sul, outro só pra região Nordeste e assim por diante.

Problema que um servidor vai continuar tendo mais volume de dados que outros. Não vai ser balanceado. Rapidamente o da região Sudeste vai precisar dividir. Daí teríamos que fazer um servidor só pra São Paulo separado. Mas mesmo assim, o volume só de São Paulo sempre vai ser muito maior que tudo, vamos dividir pelo menos a cidade de São Paulo num único servidor sozinho. Tá vendo o trampo? Ficar tentando dividir os dados assim manualmente vai ser um parto. Pior ainda pro software. Teríamos que fazer algo como “if sao paulo, procura no servidor X”, ou “if regiao nordeste, procura no servidor Y”. Isso rapidamente fica caótico.

Existe uma solução melhor. Antes, vamos ver um outro jeito ingênuo de balanceamento. Alguém poderia pensar “hum, e se não olharmos pros dados, esquece isso de região ou estado, vamos olhar só pro ID”. Nesse caso digamos que os IDs são numéricos e sequenciais, exatamente como eu disse pra não fazer. Daí temos 3 servidores que vamos chamar de A, B e C e 12 itens na tabela, com ID de 1 a 12, pra simplificar. Como eu divido esses 12 itens entre os 3 servidores?

Fácil, que tal usarmos o módulo do ID? Lembra a idéia de módulo? No caso faríamos módulo 3. Módulo é quando você pega o restante da divisão de um número por outro. Por exemplo. 1 módulo de 3 seria 1, 2 módulo de 3 seria 2, 3 módulo de 3 é 0, por que 3 dividido por 3 dá um e sobra zero. Interessante é acima disso. 4 dividido por 3 é 1 e sobra 1, então o módulo é 1.

5 dividido por 3 é 1 e sobra 2, então o módulo é 2, mas 6 dividido por 3 é exato 2 e sobra zero, o módulo é zero. Qualquer número módulo 3 vai ser um número de 0 a 2. Sempre vai rotacionando. Estabelecendo arbitrariamente que o servidor A é zero, B é 1 e C é 2, sabemos como dividir cada uma das 12 linhas em cada um dos 3 servidores, sacaram?

Então no servidor A teremos os itens com IDs, 1, 4, 7 e 10. No servidor B teremos os itens com IDs 2, 5, 8 e 11 e no servidor C teremos os itens com IDs 3, 6, 9 e 12, todos os múltiplos de 3. E toda vez que quisermos inserir uma nova linha, fazemos o módulo do ID e vemos pra qual servidor mandar. Isso garante que todos vão estar balanceados, ou seja, todos vão ter exatamente o mesmo número de linhas. Resolvido então?

Mas é a Receita Federal, eles crescem infinitamente. Muito em breve só 3 servidores não vai dar conta. Precisamos adicionar mais um novo servidor. Agora fodeu. A conta passa de módulo 3 pra módulo 4. Ou seja, precisamos rebalancear todos os dados em todos os servidores. Na nova configuração, cada ID vai ficar num servidor diferente do que tava antes. Essa estratégia funciona pra balancear se nunca mexermos na quantidade de servidores, mas não escala se precisarmos adicionar novos, porque precisa mover todos os dados de lugar pra rebalancear.

Por isso foi inventado o algoritmo de Consistent Hashing em computação distribuída. É um esquema de organização de IDs que permite adicionar ou remover servidores sem precisar mover todos os dados de lugar toda vez. Ele consegue isso organizando todos os IDs num anel, um círculo de hashes. Pra entender hashes recomendo que assistam o primeiro episódio de criptografia.

Em resumo bem resumido, hash é uma função que pega qualquer informação, por exemplo uma string, e devolve um número de tamanho fixo. Mas é uma função não reversível, ou seja, a partir do número não tem como encontrar a string original, porque diversas strings podem chegar no mesmo número. A função só garante que se você passar a mesma string, vai chegar no mesmo número.

Dependendo da função ela devolve um número até um determinado tamanho, por exemplo, um SHA512, vai devolver um número de até 512 bits. O número máximo de 512 bits é um absurdo maior que a quantidade de átomos no universo visível. Obviamente é exagerado demais pra um campo de ID. Um Cassandra usa outra função de hash não criptográfico, ou seja, que não deve ser usado pra criptografia, mas é bom o suficiente pra IDs, o Murmur3 que devolve hashes de 64 bits, onde o maior número é da ordem de milhões de trilhões, que ainda é um número gigante, mas mais gerenciável.

Enfim, o principal é que no sistema de consistent hashing consideramos um anel que vai de 0 até esse número máximo de 64 bits. Daí fazemos o hash dos IDs dos servidores. Digamos que temos 4 servidores. Eles se distribuem pelo anel. O lance de uma função de hash é que ela tende a ter uma distribuição uniforme, o oposto de sequencial. Podemos gerar o hash dos dados do registro, com a combinação de diversos dados como o endereço IP do usuário mais o horário, ou qualquer coisa assim.

Por exemplo, imagine um anel onde cada ponto desse anel começa em 0 no topo e tem todos os números até 2 elevado a 64, no final do anel, encostado no zero, pra dar uma volta. Entenderam, todos os IDs possíveis estão no anel. Daí aplicamos a função de hash pros nomes ou endereços IP de cada servidor, e aí eles caem arbitrariamente pelo anel, só pro exemplo, o servidor A lá em cima, depois o B mais pra direita lá embaixo e o C mais pra esquerda embaixo.

Vamos inserir alguns dados, digamos que é o hash do nome do registro. O primeiro registro tem o nome de John e digamos que o hash gerado caia entre o Nó A e o Nó B. A regra é pra ele escolher o servidor com o hash maior ou igual ao do ID olhando na direção de relógio, da esquerda pra direita. Nesse caso vai ser o Nó B. O próximo registro tem nome de Fred e o hash por acaso tem ponto aqui entre o B e o C, então ele cai no Nó C. E o último registro com nome de Susan cai aqui entre o C e o A, então vai no A. Sempre na direção de relógio.

Beleza e qual a vantagem disso? Bom, vamos voltar pro cenário onde queremos adicionar um novo servidor, o nó D e o hash dele vai aqui entre o C e o A, por acaso. Mas ele cai depois da Susan. O que acontece é que todos os dados com IDs depois do C que estavam caindo no Nó A, agora precisam ser movidos pro Nó D. É assim que rebalanceia. Mas prestem atenção, no exemplo de usar a função simples de módulo, precisaria mover todos os dados de todos os servidores quase. Aqui, os dados dos servidores B e C não precisam ser mexidos, só os do A que precisam ser divididos. Os registros com IDs maiores que D e menores que A, continuam no A.

Digamos que o servidor A tenha uma pane qualquer e precise ser removido. E agora? Todo registro que antes cairia no A, pela regra de olhar o próximo servidor em sentido de relógio no anel, então vai passar a cair no B. Só isso. E nenhum dado de nenhum outro servidor precisa ser mexido. Falando simplificadamente é assim que garantimos ter a menor quantidade possível de dados sendo movidos quando a infraestrutura muda. A idéia é mover a menor quantidade de dados quanto possível quando precisamos adicionar novos servidores.

Tem várias nuances nessa estratégia. Por exemplo, quando da remoção de um Nó, pode acontecer de outro Nó acabar acumulando dados demais. Pra evitar isso, cada Nó pode ter múltiplos hashes aleatórios que o colocariam em múltiplas posições no anel, daí os dados poderiam ser melhor rebalanceados. Se ficou interessado, depois leia a documentação a respeito em sites como do Cassandra ou no paper do DynamoDB da Amazon.

Dizendo assim parece fácil, mas em DynamoDB por exemplo, você tem que entender o conceito de chave de partição e chave opcional de ordenamento. Dados com a mesma chave de partição caem na mesma partição, obviamente. O problema é se quisermos fazer uma pesquisa que precisaria buscar dados em múltiplas partições. Pra isso tem comandos com o “Scan”, mas isso é uma operação bem mais custosa do que pesquisar dentro de uma mesma partição.

Portanto a estratégia de partição precisa estar muito bem definida no começo, senão vai ter obstáculos de não conseguir fazer pesquisas rápidas quando precisar. As coisas não são automáticas, trocamos conveniência por performance. Num banco relacional, onde normalmente fica tudo junto, é só rodar um comando SQL e temos o que queremos rápido. Num sistema distribuído as coisas estão, duh, distribuídas, e precisamos levar isso em consideração.

No DynamoDB, que é oferecido com um serviço da AWS, precisamos entender bem o comportamento da nossa aplicação, não só pra não dificultar operações depois, mas porque a cobrança também não é simples. Não se paga por gigabyte armazenado, por exemplo. Precisa calcular a quantidade de escritas por segundo. A quantidade de escritas por segundo durante um pico. A duração de cada operação de leitura, porcentagem de capacidade de leitura que quer deixar reservado, o nível de consistência das leituras, quantas quer que sejam fortemente consistemente, quantas fracamente consistentes.

Por exemplo, na calculadora online deles, o preço por gigabyte, na região US east, é de meros 25 centavos por mês. Sucesso então? Não, com 10 escritas não transacionais, 100 escritas por segundo em horário fora de pico, 400 escritas por segundo em horário de pico, 72 horas operando em pico durante o mês, com capacidade reservada de escrita pra um ano, pode somar mais 23 dólares por mês e 150 dólares que precisa pagar a vista logo no começo pra reserva.

Daí continuando com os valores padrão pra leitura, só pra não entediar, mais 3 dólares por mês e mais 30 dólares upfront à vista. Então, por mês nessa configuração vai pagar uns 26 dólares, mais 180 dólares à vista na entrada. E essa configuração é a mais basiquinha, pra um app pequeno.

Na categoria de bancos de dados NoSQL oferecidos como serviço, ou seja, que não precisamos saber como configurar e dar manutenção na infraestrutura, tem diversas outras opções, como MongoDB Atlas ou Google Firebase. Firebase é bem popular pra aplicações pequenas, porque até 1 gigabyte de mensagens, até 1 gigabyte de armazenamento, 5 gigabytes de cloud storage, o custo é gratuito. Já um MongoDB Atlas você paga até que “barato” a 10 centavos por milhão de operações de leitura, ou o recomendado 57 dólares por mês pra solução dedicada de 10 giga até 4 terabytes de armazenamento.

Não é simples calcular o real valor que vai pagar, tem dezenas de parâmetros pra considerar, como quantidade de invocação de funções e gigabytes por segundo ou minutos de cloud build ou gigabytes transferidos pela rede e mais. O preço vai variar de acordo com o sucesso ou fracasso da sua aplicação. Quanto mais “barato” ficar, mais fracassado é seu app, quanto mais sucesso fizer, mais caro vai ficar. No começo parece uma grande vantagem, mas justo quando fizer sucesso e achar que vai ganhar bastante, é também quando eles vão te cobrar mais caro. Essa é a faca de dois gumes de serviços que você não gerencia. Uma hora a conta chega.

Isso sem contar o custo do desenvolvimento e manutenção da sua aplicação. Quanto mais exótico for um banco de dados, mais difícil vai ser encontrar profissionais qualificados ou treinar em casa. Só porque um banco é exótico, não significa que resolve seus problemas. Em muitos casos, alguém pode escolher o Google Firebase pelo hype mas na realidade o desenvolvimento teria ficado mais barato se tivesse escolhido, digamos um MongoDB Atlas.

Ambos Firebase e MongoDB tem a flexibilidade de lidar com documentos estilo JSON, sem precisar se prender à estrutura mais rígida de um schema de banco de dados relacional. Mas só dizer JSON não significa que são iguais. MongoDB permite lidar com documentos mais complexos, embedded arrays, sub-documentos. O modelo do Firebase é bem mais simples.

Mas o Firebase tem atualizações em tempo real, que é importante pra quem desenvolve aplicações mobile. Mudanças no banco podem ser empurradas como notificações direto pros usuários em tempo real. MongoDB não tem isso nativo. Dá pra colocar mas dá mais trabalho, portanto é mais custo de desenvolvimento.

Por outro lado, se quisermos fazer pesquisas mais complexas, MongoDB tem uma linguagem de queries mais avançada, incluindo coisas como joins e índices secundários. Firebase tem capacidades de query, mas limitadas. Da mesma forma, transações. Todo mundo foge de banco relacional, mas todos adoram ter transações e dados fortemente consistentes. MongoDB tem mais suporte a transações do que Firebase. De novo, se quiser algo semelhante a transações no Firebase, o custo de desenvolvimento sobe. E se transações é realmente importante, talvez um banco relacional como AWS RDS tivesse sido melhor, em primeiro lugar.

Mas a vantagem de serem “as a service” quer dizer que tanto MongoDB Atlas quanto o Filestore do Firebase tem escalabilidade e replicação automáticas em múltiplas regiões pra alta disponibilidade. Ou seja, se throughput de operações e garantir que nunca fique fora do ar seja primordial, ambos podem ajudar com isso. Mas você vai pagar por isso, e não vai ser barato. Como expliquei, o modelo de precificação é complexo. Precisa seriamente gastar tempo pesquisando e avaliando muito bem o que acontece não só agora, que sua aplicação tá no começo, mas daqui seis meses se fizer sucesso.

Não tem como eu explicar todos os bancos de dados oferecidos como serviços hoje. A Amazon é a mais famosa. Todo mundo escolhe o AWS RDS pra soluções de MySQL ou Postgres como serviço, mas o Google também tem o Cloud SQL como concorrente. Vai depende de precificação e funcionalidades que pra você podem ser importantes. Além deles tem o Azure SQL Database e acho que até a Oracle oferece o banco de dados SQL deles como serviço.

Pra complicar a vida, a própria Amazon oferece produtos similares na mesma plataforma, como o Apache Aurora que parece com RDS. Aurora é um produto superior de banco de dados MariaDB, Postgres, SQL Server, Oracle, tem maior garantia de disponibilidade, dobro da performance no mesmo perfil de hardware, mais facilidade de escalabilidade, opções de backup, replicação, porém, obviamente custa mais caro. Ou seja, tem SQL pra todos as necessidades e capacidade de pagamento.

Digamos que você é um apologista de NoSQL, não quer mesmo SQL. Daí tem o MongoDB Atlas e Google Firestore que já falei, mas temos mais opções. Pro mundo enterprise, a SAP oferece o HEC que é o HANA Enterprise Cloud. Tem a ScyllaDB que oferece uma versão de Cassandra deles e tem o AstraDB da DataStax que também é Cassandra como serviço. Isso sem contar o Heroku que oferece Postgres como serviço, Redis como serviço. E em termos de cache, Memcache e Redis, a AWS tem o Elasticache como já falei. Tem serviços pra todo mundo, é só conseguir pagar.

Mas, pra você que é iniciante em programação, não se deixe enganar por hype de NoSQL. A gente vem discutindo esse assunto desde pelo menos 2008. E eu posso te garantir algumas coisas: não existe consenso, pelo simples fato que cada banco de dados tem pontos fortes e pontos fracos, cada um serve pra situações diferentes. Pra aplicações bem pequenas, meio que tanto faz se vai escolher um banco relacional SQL como um MariaDB ou Postgres ou se vai direto pra um FireStore da vida. Você tem poucos dados, tem poucos problemas pra lidar.

A primeira versão de qualquer coisa que fizer sempre vai ser isso: versão 1.0. Só quando tiver usuários de verdade, dados de verdade, receita e faturamento de verdade, só aí vai realmente entender o que precisa. E se ficar limitado a usar só uma ferramenta pra tudo, em breve vai ter tanto problema, e vai ignorar que existem já soluções pra cada problema, que corre o risco de fracassar por ignorância.

Na dúvida, a solução mais comum é a mesma: AWS RDS com Postgres ou MariaDB, que é o que a grande maioria dos frameworks web usam, como Ruby on Rails. Django, Laravel, Spring. Daí uma solução de cache usando Redis ou Memcache, e pra isso tem AWS ElastiCache. E finalmente jobs assíncronos, seja com Kafka, seja com AWS SQS. Isso resolve 90% dos seus problemas. Se precisar de alguma coisa de documentos schemaless em JSON, um Postgres já suporta isso nativamente. Quer só fazer um protótipo, vai de Firebase.

Se por acaso estiver na rara categoria de Big Data, significa que você não é uma micro empresa, ou um freelancer. Já é uma empresa média. Aí é outra categoria, já vai olhar pra Aurora, DataStax, e soluções pra Data Science como Apache Spark, Hadoop e muita coisa customizada. Vai ter profissionais experientes de infraestrutura de devops. Essa categoria não é pra amadores. Por isso, se for iniciante, não se preocupe com isso tão cedo. Você não é o Netflix.

No fim do dia, entender bancos de dados, sejam relacionais, sejam NoSQL, significa entender o problema que se quer resolver primeiro. Daí aplicar fundamentos de ciências da computação. Árvores, estruturas de dados, redes, sistemas de arquivos, sistemas operacionais, fundamentos de criptografia. Ficar acompanhando discussões inúteis em fios de Twitter da bolha dev, só vai te confundir, nunca tem nada de útil e você vai ser mais um maria-vai-com-as-outras. Se atenha a pesquisar documentação oficial de cada coisa.

A grande maioria dos programadores iniciantes hoje tem o mesmo problema de ignorar fundamentos, ignorar os problemas que se quer resolver, e escolher baseado em likes. Influencer nenhum sabe o seu cenário particular. Óbvio que vai dar ruim. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal, e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais.

Não, AGI não está próximo de acontecer.

Quais são os limites da atual tecnologia de transformadores generativos pré-treinados, vulgo GPT? O que são os tais “modelos” que eles usam? O que são os tais “parâmetros”. Porque as IAs parecem humanas nas respostas? IAs vão substituir programadores?? Como é possível conseguir rodar um clone de ChatGPT na sua própria máquina, totalmente offline?

Vamos responder tudo isso e muito mais.

Capítulos

• 00:01:07 - CAP 01 - Minha IA PESSOAL e OFFLINE - text-generation-webui
• 00:06:37 - CAP 02 - Introdução a MODELOS - Como IA Aprende?
• 00:10:09 - CAP 03 - Auto-Corretor de Teclado de Celular - Cadeias de Markov
• 00:15:34 - CAP 04 - 170 TRILHÕES de parâmetros - Maior que nosso cérebro?
• 00:20:28 - CAP 05 - De Markov a IA - O que são Tensors?
• 00:30:53 - CAP 06 - A Revolução da Auto-Atenção - O que são Transformers?
• 00:35:24 - CAP 07 - Hardware pra Treinar IA - NVIDIA
• 00:42:09 - CAP 08 - Parâmetros e Sinapses são equivalentes? - Quantização
• 00:49:42 - CAP 09 - Estamos próximos de AGI? IAs são Inteligentes?
• 00:52:10 - CAP 10 - Controlando Criatividade de IAs - Temperatura
• 01:00:27 - CAP 11 - A Avó do ChatGPT - Eliza
• 01:04:29 - CAP 12 - IAs que fazem Imagens - Diffusion
• 01:09:31 - CAP 13 - Discutindo PROMPTs - LangChain
• 01:13:08 - CAP 14 - IAs vão matar programadores? Quais os Limites?
• 01:22:15 - CAP 15 - Virando “Programador 10x” com auxílio de IAs - Copilot
• 01:23:47 - CAP 16 - CONCLUSÃO - O começo da BOLHA
• 01:28:18 - Bloopers

Links

• Introducing LLaMA: A foundational, 65-billion-parameter language model (facebook.com)
• NVIDIA/Megatron-LM
• oobabooga/text-generation-webui
• TheBloke/Wizard-Vicuna-30B-Uncensored-GPTQ
• Neural networks - YouTube
• GPT-4 Will Have 100 Trillion Parameters — 500x the Size of GPT-3 | by Alberto Romero | Towards Data Science
• MIT Deep Learning 6.S191 (introtodeeplearning.com)
• DF Direct Special: Starfield Tech Breakdown - 30FPS, Visuals, Rendering Tech + Game Impressions - YouTube
• NVIDIA Made a CPU.. I’m Holding It. - YouTube
• (2) Artem Andreenko 🇺🇦 on Twitter: “I’ve sucefully runned LLaMA 7B model on my 4GB RAM Raspberry Pi 4. It’s super slow about 10sec/token. But it looks we can run powerful cognitive pipelines on a cheap hardware. https://t.co/XDbvM2U5GY” / Twitter
• Émile Borel and the Infinite Monkey Problem | SciHi Blog
• GitHub - codeanticode/eliza: The classic Eliza psychologist program, implemented as a Processing library.
• Stories • Instagram
• TheBloke (Tom Jobbins) (huggingface.co)
• Introduction | 🦜️🔗 Langchain

SCRIPT

Olá pessoal, Fabio Akita

Este é um episódio que eu tava tentando evitar fazer. Primeiro porque acho que vai ser um dos temas onde parte do video vai acabar ficando obsoleto meio rápido, já que as tecnologias de IA estão acelerando e mudando bastante ainda. Segundo, porque eu mesmo nunca trabalhei com IA. Maioria das coisas que explico neste canal, já me envolvi em projetos reais de alguma forma, por isso não é só teoria, é experiência. Mas IA, eu brinquei, mas nunca trabalhei nem fiz pesquisa acadêmica, nem nada disso, por isso nunca me senti adequado pra explicar.

Mas considerando que quase a totalidade de videos feitos sobre o assunto hoje são de pessoas com menos conhecimento ainda, fazendo afirmações cada vez mais absurdas; até eu certamente consigo fazer muito melhor. Pra variar, os oportunistas já saíram lançando cursos e afins. No fim do video vou explicar porque todos são uma droga e você deve evitar. Também vou explicar de novo porque ela não vai substituir programadores. Hoje vou explicar o que de fato é um ChatGPT e onde estamos quando se fala em IA. Então vamos lá.

(…)

Esses dias resolvi brincar de IA, o objetivo era ter o meu próprio ChatGPT, rodando offline, totalmente local, na minha máquina, sem conectar com nenhuma API de terceiros como da OpenAI. Isso ficou fácil porque agora existem diversos esforços da comunidade de código aberto, em particular projetos de Open LLM, ou Large Language Models, que é a categoria de IA onde se encontra um GPT.

Esses esforços ganharam força quando a Meta decidiu abrir seu modelo Llama em fevereiro de 2023. As big tech tem diversos modelos prontos, cada um pra algum uso específico, desde respostas gerais ou mais focados em código e assuntos específicos. Por exemplo, a OpenAI tem os modelos GPT 3.5, GPT 4, Codex. A Microsoft tem o Zero, ou Megatron em conjunto com a NVIDIA. O Google tem modelos como o BERT, Palm, LaMDA, Minerva e outros.

A Meta, de novo, tem o OPT, Galactica, METALM, LLaMA. Alguns desses modelos são citados em papers mas são fechados, como o novo BARD do Google ou o próprio GPT 4 da OpenAI. Mas o lançamento do LLaMA ao público foi um evento importante e a Meta parece que liberou vários outros como o OPT e Galactica. A primeira parte do video de hoje vai ser entender o que diabos são esses modelos.

Isso foi em fevereiro, este video tá saindo em junho, só 4 meses. E de lá pra cá a comunidade usou o LLaMA pra criar derivados mais otimizados e menores pra rodar em computadores menos parrudos. Surgiram diversas variantes como Alpaca, Vicuna, GPT4ALL, Koala, Dolly e dezenas de outros. Literalmente dezenas. O site HuggingFace, que é um repositório de modelos e ferramentas pra inteligência artificial, tem listado uns 200 modelos diferentes.

O que dá pra fazer com esses modelos abertos? Deixa eu mostrar. Eu queria um ChatGPT pessoal, offline, que ninguém sabe o que tô conversando com ele, sem filtros, sem controle, sem nada. Só eu e a ferramenta. Existem vários projetos abertos que implementam interface web similar ao ChatGPT, onde posso digitar perguntas, ver as respostas da IA, e ficar conversando com ela, sem precisar estar conectado na internet. Olha só esse exemplo.

(… screencast text-generator …)

Se assistiram meu episódio sobre games em máquina virtual, sabem que tenho uma máquina que alguns consideram “parruda”, um AMD 5950X de 16 cores, 32 threads, rodando a uns 4 gigahertz por core. Mais 64 gigabytes de RAM DDR4. Uma GPU NVIDIA RTX 3090 com 24 gigabytes de memória GDDR5. Fora meu NAS Synology de 60 terabytes, conectado em rede 10 gigabits. Meus testes foram feitos numa máquina virtual QEMU rodando Ubuntu normal, com passthrough de PCI pra ter acesso direto à GPU NVIDIA. Todos os detalhes sobre essa QEMU eu mostrei no video de Games em Máquina Virtual.

Sem nenhum motivo em particular, escolhi o projeto aberto “text-generation-webui” que é uma aplicação web escrita em Python. Ela simula a interface web de chat do ChatGPT. Por baixo, carrega bibliotecas como bitsandbytes, pytorch e outros que vou explicar depois. Daí podemos baixar modelos e fazer ele carregar um deles. No caso estou rodando Vicuna 30b quantizado. De novo, já vou explicar o que isso significa. Dizem que tem qualidade parecida com GPT 4 mas pra mim pareceu mais um GPT 3. As respostas que consigo no GPT 4 ainda são mais completas do que nesse Vicuna.

Mas mesmo assim é impressionante. Estão vendo? Estou conversando de boas. E não está conectando com nenhum serviço online de ninguém, nem da Microsoft, nem da OpenAI, nem do Google. Tudo rodando offline, local, dentro da minha máquina virtual. Vou repetir, porque quando postei sobre isso no Instagram, muita gente ficou confusa. Sim: dá pra rodar um programa similar ao serviço de ChatGPT da OpenAI num computador normal. E não se trata de uma demonstração hello world, realmente funciona. Não precisa de um monte de servidores parrudos pra conseguir isso. Ué, mas eu achava que precisava ter o tamanho de uma Microsoft ou Google pra fazer isso, o que mudou?

A exigência de hardware depende da complexidade do modelo. Como falei, estou usando Vicuna de 30 bilhões de parâmetros, mas existem modelos menores, como o próprio Vicuna de 7 bilhões de parâmetros, ou a Ada da Microsoft, de só 350 milhões. Se o modelo for pequeno o suficiente, é possível até rodar num bom smartphone Android ou um Raspberry Pi com um upgrade de RAM. O tamanho do modelo é um dos fatores que pode afetar a qualidade das respostas, portanto quanto menor o modelo, mais simples seriam as respostas. Simplifiquei sobre “tamanho”, guardem essa informação que já vou explicar mais.

Deixa recapitular um pouco. O que diabos é isso de modelo? Honestamente, eu mesmo não sei dizer em todos os detalhes, pra isso precisaria ter estudo e treinamento em inteligência artificial, em particular redes neurais. Muita gente aprendeu isso em optativas ou iniciação científica na faculdade de ciências da computação. Não vou tentar dar explicação acadêmica, mas sim dar uma intuição pra maioria de vocês conseguirem ter uma imagem na cabeça. Acadêmicos, sejam compreensivos, e se quiserem complementar, sintam-se a vontade nos comentários abaixo.

Pense em redes neurais como uma simulação do aprendizado que acontece no nosso cérebro. Sabemos que temos neurônios. Aprendizado e memória acontecem quando temos sinapses, conexões desses neurônios, ou comunicação, ou melhor “ativação de um neurônio”, que é como se ele escolhesse um caminho dentre muitos. Um neurônio pode ter milhares de conexões, dizem que umas 7 mil. De novo, explicação grosseira. Mas é mais ou menos isso que temos em redes neurais. Assista os videos do canal 3Blue1Brown sobre redes neurais pra entender em mais detalhes.

No caso específico de texto, poderíamos pensar que a forma de fazer computadores aprenderem a interpretar e gerar texto seria cadastrando regras gramaticais, ortográficas, vocabulário, dicionários, e assim ele conseguiria construir frases gramaticalmente corretas. Mais ou menos como você pensa que é o jeito certo de aprender uma língua nova como inglês ou francês num curso qualquer. Esse parece ser o jeito intuitivo, certo?

Mas se assistiu meu video de Como eu Aprendi Inglês e a minha live com o Matt sobre aprender japonês, já sabemos que não é assim. Não se trata de decorar dúzias de regras. Nem no aprendizado em geral, nem em inteligência artificial. Não existem “regras” como um monte de “ifs”. Pense por dois segundos: quando foi a última vez que você escreveu um texto 100% gramaticalmente e formalmente correto? Concorda que um texto assim seria super estranho? Sem gírias, sem maneirismos, sem coloquialismos, com palavras consideradas rebuscadas. Exatamente o que associamos com um robô falando.

Já falei isso nesses outros videos, mas vou repetir: como você aprendeu português? Foi lendo um livro do tamanho da Bíblia, lotado de regras gramaticais? Quando tinha 1 ou 2 anos de idade? Como um bebê que nasceu nos Estados Unidos aprendeu inglês? Como um bebê que nasceu na China aprendeu chinês? Nenhum deles usou nenhum livro, nenhum curso, nenhuma regra. Simplesmente passaram um tempão ouvindo os pais e pessoas ao redor e começaram a repetir o que ouviam. Bem errado no começo.

Todo mundo vai dando feedback. Quando o bebê tinha uma intenção, sei lá, dizer que está com fome. Ele tentava juntar palavras que já tinha ouvido antes e que parecia descrever o que queria. Se os adultos ao redor dessem comida, é o feedback que o que falou parece que faz sentido. E assim ele vai associando as combinações de palavras com comportamentos. Vai refinando seu aprendizado. Fazendo novas sinapses, novas conexões. Pouco a pouco melhorando a comunicação e se fazendo entender melhor. 

A grosso modo é como seria o que chamamos de treinamento supervisionado, no mundo de inteligência artificial. Nós não programamos regras gramaticais nem cadastramos palavras num banco de dados manualmente e ficamos fazendo “ifs” pra montar frases. Em vez disso começamos com um corpo de dados gigante. Por exemplo, todos os artigos da Wikipedia, todos os códigos abertos disponíveis no GitHub, todos os papers acadêmicos disponíveis publicamente, todos os livros digitalizados num Google Books. Bastante texto. Dezenas ou centenas de gigabytes de texto puro.

Pra entender isso, deixa eu fazer uma tangente e explicar um conceito relacionado que não é, em si só, inteligência artificial, mas faz parte da matéria. Na faculdade de ciência da computação, se aprende sobre processos estocásticos, que estuda aleatoriedade, probabilidades, ou melhor, a evolução de um sistema ou fenômeno ao longo do tempo de forma probabilística. Ele descreve o comportamento de um sistema ou quantidades que mudam aleatoriamente ao longo do tempo. Em particular quero falar de Cadeias de Markov.

Não estou falando que o ChatGPT não é uma Cadeia de Markov, é só pra ilustrar um ponto. Cadeias de Markov é uma das formas de representar e analisar sequências de eventos, ou estados, onde a probabilidade de transicionar de um estado pra outro depende somente do estado atual, é um sistema sem memória ou backtracking, sem considerar a sequência de todos os estados anteriores, só o último. Em resumo é um conjunto de estados e probabilidades de transição. Se pareceu grego, vamos ver um exemplo prático.

Digamos que em vez de ter gigabytes de textos como descrevi antes, nosso corpo de treinamento sejam só 3 frases em português: “Eu gosto de comer maçãs.”, daí “Ela gosta de jogar tênis.” e finalmente “Ele prefere ler livros.”. Podemos construir um modelo baseado nessas frases, onde os estados são palavras, ou tokens, e as transições entre estados representam a probabilidade de mover de um token pra outro. Vamos construir esse modelo simplificado.

Os tais estados podem ser só as palavras, tokenizadas ou quebradas a partir dessas frases, daí teríamos essa lista de palavras, “Eu”, “gosto”, “de” etc. 

1. Eu
2. gosto
3. de
4. comer
5. maçãs
6. Ela
7. gosta
8. jogar
9. tênis
10. Ele
11. prefere
12. ler
13. livros

As transições são as probabilidades. Esses são exemplos, mas digamos que a transição do token, ou estado “Eu” pro estado “gosto” é probabilidade 1, ou seja, 100%. Mas a transição do estado “de” pra “comer” é 0.5 ou 50% porque poderia ser pra “jogar” que é 0.5 também. Pra ficar claro, na primeira frase temos “de comer”, mas na segunda frase tempos “de jogar”, por isso a partir do token “de” temos duas possibilidades, 50% de chance pra cada.

Como temos poucas frases de treino, as transições são quase 100% de uma palavra pra outra, porque esse modelo só conhece 3 frases. Num treinamento de verdade com gigabytes de textos, teríamos trilhões de possibilidades diferentes e probabilidades pequenas e fracionadas, como 0.001234 bla bla. 

Finalmente, digamos que começamos a digitar um texto e queremos que esse modelo continue completando a frase pra gente. Podemos usar o modelo da cadeia de Markov pra prever o que seria a palavra mais provável baseado nas probabilidades de transição que vimos na lista anterior. Por exemplo, começo digitando “Eu” e a probabilidade da próxima palavra ser “gosto” é 100%, então é isso que ele dá de previsão. Se digitar “Ele”, a probabilidade segundo a lista é 100% pra “prefere”.

- De "Eu": gosto (1.0)
- De "gosto": de (1.0)
- De "de": comer (0.5), jogar (0.5)
- De "comer": maçãs (1.0)
- De "maçãs": Eu (1.0)
- De "Ela": gosta (1.0)
- De "gosta": de (1.0)
- De "de": jogar (0.5), ler (0.5)
- De "jogar": tênis (1.0)
- De "tênis": Ela (1.0)
- De "Ele": prefere (1.0)
- De "prefere": ler (1.0)
- De "ler": livros (1.0)
- De "livros": Ele (1.0)

Por causa de smartphones, todo mundo já viu isso em ação de verdade. É a funcionalidade de auto-correção que tem em todo teclado. Olhe neste exemplo, começo digitando uma palavra e o teclado sozinho vai sugerindo a próxima palavra, e podemos só aceitar a sugestão. E ele vai sozinho completando a frase. Claro, se ficar fazendo só assim, a frase vai ficando meio sem sentido nenhum, mas ele consegue gerar uma frase que mais ou menos parece um humano que escreveu, não acha?

Vou repetir: isso é uma explicação simplificada, tem várias outras técnicas em cima de cadeias de Markov, mesmo pra um tecladinho simples de iOS ou Android. Mas em linhas gerais, pense que em vez de 3 frases, o modelo desses teclados foi pré-treinado com milhares de frases. O modelo é essa lista de combinações de palavras e as probabilidade da próxima palavra, dada uma palavra anterior. Essas probabilidades é o que chamamos de “pesos”. E mais importante: em nenhum momento usamos quaisquer regras hard-coded de gramática ou ortografia ou ifs ou templates. Ele vai completando a frase puramente usando esses pesos, aprendidos no treinamento, nada mais.

Agora vamos voltar pro ChatGPT ou pra minha versão local do text-generation com Vicuna. Vocês nunca acharam estranho que as respostas sempre demoram e ele vai escrevendo uma palavra de cada vez? Alguns poderiam achar que é só uma animação arbitrária pra fazer parecer que o ChatGPT é uma pessoa digitando. Mas deixa eu rodar uma versão fora da interface Web, na linha de comando mesmo. Prestem atenção.

(… screencast command line fastchat …)

Pra ficar mais claro, vou colocar do lado o monitoramento da minha GPU, a ferramenta da nvidia chamado “nvidia-smi” que faz o monitoramento dos recursos sendo usados na GPU. Notem que durante a composição da resposta, a GPU está em uso constante, processando alguma coisa, sem parar. Não sei porque usa só 50% do processamento disponível, mas de qualquer forma, a resposta não é instantânea. Não é uma animação feita só pra fazer graça, é que ele demora isso mesmo palavra a palavra. Cada palavra nova que vai aparecendo está gastando processamento da GPU. Se levou 5 segundos pra dar a resposta, foi 5 segundos que a minha GPU ficou processando sem parar.

Conseguem ver as similaridades entre o auto-corretor do seu tecladinho de celular e o processo de resposta do ChatGPT? Internamente ele está fazendo algo similar a procurar probabilidades na cadeia de Markov. Mas claro, o modelo de GPT, LLaMA, Vicuna, Bard, e outros, é mais complicado que um mero modelo de Markov. Vamos entender.

Quando as primeiras notícias anunciando o ChatGPT saíram, gerou muita confusão, que persiste até hoje. Por exemplo, quando o ChatGPT 4 foi anunciado, eles mencionam, “uau, o ChatGPT 3.5 tinha 175 bilhões de parâmetros mas o ChatGPT 4 tem incríveis 100 a 170 TRILHÕES de parâmetros”. A única coisa que os jornalistas e vocês entenderam foi “uau, bilhões pra trilhões de … whatever … trilhões é absurdamente maior que bilhões, então o GPT novo é milhões de vezes melhor e o GPT 5 vai ser mais milhões de vezes melhor”. E é assim que todo mundo mente e se auto-engana com números, sem saber o que significa.

Esse meu Vicuna, rodando localmente na minha máquina, tem meros 30 bilhões de parâmetros. Puuuts, quer dizer que ele deve ser pelo menos 5 vezes pior que o ChatGPT antigo, né? Nem chega aos pés do GPT 4. Só que se olhar alguns artigos que descrevem o Vicuna menor, o de 13 bilhões de parâmetros, muitos declaram que rodando diversos testes, os mesmos que a própria OpenAI usa pra avaliar o GPT deles, dizem que o Vicuna 13B chega a 90% do nível de qualidade do GPT 4 ou Google Bard. E o Vicuna, sendo derivado do LLaMA do Facebook, nesses mesmos testes, ultrapassa o LLaMA original. Como pode isso?

Antes de mais nada, o que diabos são esses tais parâmetros? No contexto de machine learning, parâmetros se referem aos pesos que o modelo aprende durante o processo de treinamento. De forma simplificada e grosseira, lembra a lista de probabilidades de transição de estados da cadeia de Markov que mostrei no exemplo? Aquilo poderíamos chamar de parâmetros. No nosso treinamento com só 3 frases, gerou um modelo de 16 parâmetros. Pense numa lista como aquela só que bilhões de linhas. 13 bilhões ou 30 bilhões no caso do Vicuna, ou 170 trilhões no caso do ChatGPT 4.

E lembra como no exemplo, dado uma palavra, podemos ir na lista de probabilidades e ver qual poderia ser a próxima palavra? A grosso modo, é como GPT ou Vicuna fazem. Só que em vez de considerar só a palavra anterior e procurar a próxima, ele vê quais foram as palavras anteriores e leva todas em consideração pra tentar prever a próxima palavra. Lembra como minha GPU fica processando sem parar enquanto monta a resposta? É isso que está fazendo: pesquisando no modelo pela próxima palavra, mas considerando parte ou todo o texto anterior, incluindo as palavras que ele mesmo sugeriu, vai ficando cada vez mais pesado. Por isso demora.

Antes que o pessoal acadêmico me crucifique, é melhor eu me corrigir aqui. Eu repeti várias vezes “a grosso modo”, “a grosso modo”, porque o modelo do GPT não são probabilidades de pares de palavras, daquele jeito bonitinho como no exemplo. Intuitivamente, poderíamos pensar que quando se quebra um texto longo, teríamos conjuntos de “palavras”. Mas vamos recordar a metáfora do bebê aprendendo?

Todo mundo já deve ter percebido que um bebê não ouve um adulto falar uma palavra e sai repetindo bonitinho igualzinho, certo? Parte da diversão é justamente ver ele falando errado no começo e ir ajustando. O bebê tenta reproduzir o que ele “acha” que ouviu. Daí você dá o feedback negativo e ele vai tentando de outras formas, até uma hora acertar. No mundo de machine learning e deep learning, podemos usar isso como metáfora. No treinamento ele não isola palavras, isola “patterns” de funcionalidades, ou features, do material de treinamento. 

Fora de IA, no mundo de full-text search, ou em processamento de linguagem natural, temos ferramentas como Elasticsearch ou Apache Solr, que expliquei no episódio do Twitter. Eles não quebram os textos indexando palavras, mas sim grams. Quem já leu a documentação deve ter visto o termo n-gram, que são sequências de “n” itens ou tokens. Pode ser uma palavra inteira, mas pode ser só parte de uma palavra. Uma sequência de só uma letra seria um unigram, duas letras um bigram, três letras, trigram e assim por diante.

Quando indexamos texto, é mais útil indexar n-grams do que palavras inteiras, é o que nos permite fazer coisas como achar palavras “parecidas” ou que “soam” parecido, que tem mesmo sufixo ou mesmo prefixo, como conjugação de verbos. Mesma coisa com o teclado de auto-correção, ele indexa n-grams. Por isso você digita a pesquisa tudo errado num Google, mas ele diz no resultado “você quis dizer X”. O mundo de indexação de textos é todo baseado no conceito de n-grams. Vale a pena estudar isso depois.

Quer dizer que o tal modelo do GPT são pesos em cima de n-grams? Infelizmente também não é assim fácil. Eu mencionei n-grams só pra explicar como podemos dividir palavras de outras formas não intuitivas. Agora, o problema com sinapses no nosso cérebro ou redes neurais é que os pesos não são aplicados em cima de idéias discretas, como palavras ou letras ou imagens inteiras. De novo, pra entender tecnicamente como redes neurais funcionam, procure material de universidades como do MIT, Stanford ou lugares assim, e de novo, acadêmicos, peguem leve comigo.

No fim do dia, um modelo é como se fosse um banco de dados, contendo probabilidades ou pesos de um elemento pra outro elemento. Parecido com o exemplo da auto-correção. Mas o principal é que não são necessariamente palavras, não são também só n-grams, pode ser qualquer tipo de pattern que foi identificado no aprendizado. Pode ser uma letra pra uma palavra. Pode ser um bigram pra um trigram. Pode ser muitas coisas. Por exemplo, poderia ser “ef” pra “yw” probabilidade 0.01234. O que isso significa?

Isoladamente não significa absolutamente nada. Ela só vai fazer sentido dentro de uma rede de pesos. A probabilidade final é uma composição de múltiplos passos pelos nós dessa rede. O modelo não é uma lista, provavelmente é mais como um espaço vetorial multi-dimensional, tipo matrizes de matrizes. Eu expliquei espaços vetoriais no episódio do Twitter também. Similaridade de Cosseno, Álgebra Linear, lembram? De novo, pra visualizar, não pense num modelo como sendo uma lista, como um array simples. Pense como um array de arrays, de arrays. Multi-dimensional.

Se multi-dimensional não é intuitivo pra vocês, pense num elemento simples, tipo uma variável de tipo inteiro. Isso é o que chamamos de valor escalar, com zero dimensões. Representa um único valor. Agora, um array de escalares, como um array de inteiros. Isso é vetor, uma lista de uma única dimensão. Em seguida, em vez de escalares, se eu fizer um array de arrays, onde cada elemento do array é outro array, e esse array for unidimensional, agora temos uma matriz, que é um retângulo, ou uma grade de valores escalares.

Finalmente, e se esse array interno também tiver arrays como elementos? Agora temos um array de arrays de arrays, tridimensional. E podemos ir adiante, esse último array também pode ter arrays de elementos, que tem arrays de elementos, que tem arrays de elementos, aí temos matrizes multi-dimensionais ou mais corretamente, tensores de alto ordenamento ou tensores n-dimensionais.

Aliás, tudo isso que eu expliquei são tensors, sabe, do tal Tensorflow do Google? Um escalar é um tensor de zero dimensões, um vetor é um tensor de uma dimensão, uma matriz é um tensor de duas dimensões e acima disso é um high-order tensor ou n-dimensional tensor. Então, voltando pro tal modelo do GPT ou Vicuna, não pense como no exemplo simples do auto-corretor, que foi somente um vetor, um array unidimensional de pesos. Pense que esses pesos estão estruturados em tensores n-dimensionais.

Todos esses conceitos que vim explicando não são a ponta do iceberg. São a raspa da ponta do iceberg. Pode parecer que quero dizer que um ChatGPT não é mais que uma cadeia de Markov, só que maior. Não é isso, é só uma metáfora pra explicação. Deixa eu tentar explicar qual foi a tal “revolução” que permitiu o salto de um mero auto-corretor pra um ChatGPT. Mas entenda: redes neurais e deep learning existem faz décadas. A comunidade de ciências da computação vem fazendo descobertas e refinando as tecnologias faz muito tempo. Não foi do nada que isso apareceu.

Seguindo o exemplo do auto-corretor, deve ser fácil de perceber um dos problemas: ele só usa a palavra anterior pra tentar descobrir qual a próxima palavra. Por isso muito rapidamente a frase fica sem sentido. Dá impressão que foi um humano que escreveu, mas um humano bem burro. É diferente de um punhado de palavras completamente aleatórias, mas as frases que gera, são bem inúteis. Quanto maior tentar fazer a frase, pior vai ficar.

Claro, o certo é que a próxima palavra leve em consideração não só a palavra anterior, mas todas as palavras anteriores, pra manter a coerência. É isso que poderíamos chamar de backtracking ou recurrency. Isso tem que ser levado em conta durante o treinamento. Não basta quebrar o texto em palavras e só fazer o peso da palavra seguinte. Tem que ser o peso da palavra seguinte dado as palavras anteriores. É aí que nasce coisas como RNN ou Recurrent Neural Networks.

RNNs foram desenhados pra lidar com sequências de tamanhos variados, como sentenças, dados de séries de tempo, sinais de discurso. Eles conseguem processar inputs, como texto, um passo de cada vez e ao mesmo tempo mantendo um estado interno escondido que mantém informações dos passos anteriores. Ou seja, ele mantém memória durante o aprendizado. É como a gente aprende também.

Uma coisa é aprender, por exemplo, a palavra “foda”. Dependendo do contexto pode significar coisas diferentes. Pode ser que signifique “puts, que foda esse macbook novo” ou seja, positivo. Ou pode ser “puts, que trampo foda de difícil”, ou seja, negativo, e várias outras variações. Precisamos de contexto, e contexto precisa de memória pra gerar pesos diferentes pra contextos diferentes. Consegue imaginar o trampo de processar pensando dessa forma?

RNNs usam técnicas como BPTT ou Backpropagation Through Time, literalmente propagação reversa através do tempo, pra computar gradientes e atualizar os parâmetros do modelo. Então não é um processamento que você pega um texto, lê só uma vez do começo ao fim e já gera um modelo, escrito linearmente do começo ao fim. Tem que ficar voltando pra trás no modelo pra ajustar. E já que é pra dificultar, em todo paper de IA por aí vamos esbarrar nesse termo “gradiente”. Deixa eu resumir.

Gradiente se refere à derivada da loss function, função de perda, ou de custo. Puts Akita, eu nunca vou usar Cálculo na vida, é perda de tempo. Bom, eis um pequeno exemplo. Pra que serve derivada? Ela serve pra medir a taxa de mudança de uma função. Em resumo, a derivada nos diz como o resultado de uma função muda à medida que fazemos pequenas modificações nos valores de entrada. Lembra de física cinemática no colegial? Fórmula pra saber o espaço ao longo do tempo? Fórmula de Velocidade ao longo do tempo? A de velocidade é derivada da fórmula de espaço, porque velocidade é a taxa de mudança da fórmula de espaço ao longo do tempo. Aceleração é a taxa de mudança da fórmula de velocidade. 

Em particular, gradientes em cálculo de múltiplas variáveis é um vetor que aponta na direção da ascendente mais íngreme da função. Isso é super importante em otimização de algoritmos, como gradient descent, ou descida de gradiente, que iterativamente atualiza os parâmetros pra encontrar a função de custo mínimo. Dado que gradientes nos ajudam a entender a taxa de mudança de resultados de uma função, podemos usar pra encontrar os pontos de máxima e mínima, pra otimização. E esse conceito é importante em otimização de machine learning.

Em Machine Learning tem um troço que chamam de “loss function” também conhecido como função de custo, que é uma função matemática que quantifica a discrepância entre resultados previstos de um modelo com os valores de verdade. Lembrando, uma das formas de treinar é dar um monte de dados de treinamento, daí pedir pro modelo devolver respostas a várias perguntas e ver se as respostas estão corretas. Justamente pra calibrar o aprendizado. Lembra do bebê aprendendo a falar e olhando pra nossa cara pra ver se a gente entendeu? Tipo isso.

O objetivo do tal treinamento é ver quão bem um modelo performa determinadas tarefas. A escolha de qual função de custo usar depende do problema que queremos resolver, como regressão, classificação, geração de sequências. Por exemplo, em tarefas de regressão, uma função de custo popular é o MSE ou mean squared error, erro quadrado mediano, ou o MAE que é mean absolute error, erro absoluto mediano. Em tarefas de classificação tem custo de entropia cruzada e assim por diante. O importante é entender que treinamento não é um troço aleatório. Tem funções de métrica e controle pra calibrar e otimizar.

Durante o treinamento, os parâmetros do modelo são ajustados pra minimizar essa função de custo usando algoritmos de otimização como o “gradient descent”. Agora vocês entendem uma das formas que cálculo influencia a qualidade do treinamento de um modelo de rede neural. Pra hoje, pense em rede neural como uma caixa preta, que nem uma função que você programa na sua linguagem de programação. Ela tem variáveis de entrada e algum retorno. A entrada seria as tais toneladas de textos pro treinamento. Daí no meio, nessa caixa preta, esses dados são processados de alguma forma, e o retorno vai ser o tal modelo multi-dimensional.

Essa etapa no meio é o processamento dos textos e materiais de treinamento que passamos. Processos como tokenização que é quebrar o texto em listas de sequências de palavras. São uma série de transformações pra massagear esses dados em diversas camadas escondidas. Essas transformações envolvem cálculos, por exemplo, soma ponderada. Cada neurônio de uma camada escondida recebe inputs de uma camada anterior. A cada input é assinalado um peso. O neurônio computa a soma ponderada dessas entradas, onde os pesos determinam a significância da contribuição de cada input pra saída do neurônio.

Daí a soma ponderada pode ser passada pra uma função de ativação, que introduz não-linearidade e determina a saída da função. Não linearidade e sistemas complexos é um assunto gigantesco, nem vou tentar explicar. Mas pra ter intuição pense assim: você tá acostumado a pensar em sistemas lineares. Por exemplo, se 1 litro de gasolina dá pra andar 15 quilômetros, então 10 litros de gasolina vai dar 150 quilômetros. Mas não-linearidade é que nem tentar prever o tempo. 

Só porque temos 80% de humidade no ar e no passado vimos que isso indicava uma chuva de, sei lá, 20 milímetros. Não quer dizer que se eu medir hoje 80% vai dar os mesmos 20 milímetros. Pode ser 40. Pode ser zero. Tem uma rede de outras variáveis, algumas mensuráveis, algumas desconhecidas, uma influenciando a outra. Variáveis minúsculas podem amplificar resultados completamente inesperados.

É o famoso caso da Borboleta de Lorenz. Aquela história que uma borboleta bate as asas no Brasil e tem um tsunami no Japão. Não foi a borboleta que causou o tsunami, não é linear, não tem causalidade direta. Mas quer dizer que essa minúscula contribuição, somado a milhares de outras, “pode” ter causado o tsunami. 

Depois parem pra ler sobre Teoria do Caos, é fascinante, e o mundo real é cheio de efeitos não-lineares. E levamos isso em conta em redes neurais. Nosso cérebro tem aprendizado não-linear, e é o que tentamos simular com redes neurais. Agora, Deep Learning, como o próprio nome diz é aprendizado profundo, e profundidade se refere a várias camadas de aprendizado. Aquela função caixa preta que eu mencionei? Imagine várias delas em série, uma chamando a outra, várias camadas de profundidade. Lógico, explicação simplificada, mas só pra dar uma noção.

Enfim, a parte importante é que processar texto em deep learning usando técnicas como RNN e BPTT seria absurdamente caro, pra manter toda a memória e fazer todo esse backtracking na força bruta. É aí que entra o famoso paper do Google, “Attention is All You Need”. Literalmente “Atenção é Tudo que Você Precisa”, publicado por Vaswani e equipe em 2017. É o paper que introduz a arquitetura de Transformers, os famosos transformadores que permitiram esta geração de LLMs como GPT.

Em pouquíssimas palavras, ele introduz o mecanismo de self-attention, ou auto-atenção, também conhecido como atenção escalada de produto escalar. Eu expliquei produto escalar no contexto de espaços vetoriais no episódio do Twitter. Não vou explicar de novo. Mas esse mecanismo permite o modelo pesar a importância de diferentes posições na sequência de entrada, possibilitando capturar efetivamente as dependências longas. Eu sei, é difícil de entender isso, e também de explicar. Mas lembra como RNN precisa manter um estado em memória pra lembrar o contexto? Self-attention é uma otimização disso.

Em vez de ser recurrent neural network, ele passa a poder usar feed forward neural network. Da forma como eu entendo, em vez de um processo onde você dá um passo pra trás antes de poder dar um passo pra frente, agora é só passos pra frente, feed forward. O que possibilita isso é o tal mecanismo de auto-atenção. Elimina a necessidade de recorrência ou convolução. E ainda permite paralelizar o processamento. Antes, como o passo seguinte dependia do passo anterior, tinha que ser feito em série, em sequência linear. Parte da dificuldade de conseguir rodar coisas em paralelo é eliminar as dependências que amarram o passo seguinte com o passo anterior. Isso vale não só pra IA mas qualquer coisa.

Tornando o processo feed forward, evitando convolução, podemos paralelizar o processamento. O que levaria, chutando, um ano pra treinar, poderia ser feito em um mês. O importante é entender que essa arquitetura de transformers é uma otimização massiva. É mais ou menos o tipo de impacto que você vê num desenvolvimento web comum quando coloca um índice numa tabela gigante, ou quando coloca um cache na frente do banco de dados e ganha 5x ou 10x a performance. Independente de como funciona no detalhe, o importante é entender que foi um salto grande. 

Toda hora eu fico falando que os acadêmicos vão me matar vendo essas minhas explicações grosseiras, mas eu mesmo fico doído de ficar toda hora falando “a grosso modo”, “simplificando”, “em metáfora”, porque cada parágrafo que falei até agora são dúzias de papers e formalidades matemáticas. Estou tentando trazer um pouco desse vocabulário, pra vocês entenderem que não é um chute do nada, mas também reduzir em poucas palavras que ajudem a dar uma intuição. Pra maioria de nós, os detalhezinhos não importam tanto. Tem mais valor ter a noção desse processo, em linhas gerais, pra entender que não é mágica. Principalmente: qual o limite dessa mágica.

Mas com tudo isso que falei, vamos tentar entender o que é o ChatGPT então. Como é um projeto proprietário, fechado e secreto da OpenAI, temos que acreditar nas informações que eles disponibilizaram. Então sempre leiam isso com vários quilos de sal. Isso dito, parece que o treinamento foi baseado num corpo de aproximadamente 570 gigabytes de texto. Quais textos exatamente? Não sabemos, mas eles mencionam Wikipedia, artigos de pesquisa e papers, websites e outras formas de conteúdo escrito na web, com um limite até 2021. Isso é arbitrário.

Pessoalmente, achei pouco texto, eu teria chutado mais. Mas 570 gigabytes só de texto puro é bastante coisa na real. Por exemplo, a Wikipedia inteira dá um total de 21 gigabytes, e isso eu acho que é contando com o HTML que monta as páginas. Se filtrar e limpar só os textos puros vai ser bem menos. Mas digamos que seja 21 gigabytes. Precisaria de mais de 30 Wikipedias inteiras pra completar os 570 gigabytes de dados de treino. É um volume respeitável.

Esse tanto de texto, dizem que deu um total de 300 bilhões de “palavras”, entre aspas, mas acho que o jornalista entendeu errado. Um dicionário de inglês, como o Merriam Webster online não tem meio milhão de palavras. Acho que são 300 bilhões de tokens, que incluem palavras, mas também n-grams como falei antes, e seja lá quais outros patterns o deep learning identificou nesse material. Daí passa por semanas fazendo todo o processo que falei de transformação. Esse processo, que levaria meses, agora parece que dura mais ou menos um mês rodando em não sei quantos servidores usando hardwares como os agora famosos NVIDIA Grace-Hopper, os GH100.

Lembra que falei que, internamente, não estamos lidando com valores escalares e sim com tensores multi-dimensionais? CPUs como um Intel ou AMD que roda no seu PC, mesmo os M1 ou M2 da Apple, são chips com instruções feitas pra cálculos em cima de valores escalares. Uma função de soma pega dois valores inteiros de 64 bits e cospe um resultado inteiro de 64 bits. Eu explico como isso funciona nos episódios de emuladores como o do Super Mario, com processadores de 8-bits, depois dêem uma olhada.

CPUs modernas incluem instruções pra lidar com vetores, instruções SIMD, Single Instruction, Multiple Data, literalmente uma instrução pra múltiplos dados. Começou com as instruções MMX dos primeiros Pentium nos anos 90. Hoje temos conjuntos de instruções como SSE4 ou AVX-512. Pra ter a intuição, em vez de uma função que recebe um inteiro, pense numa outra função que recebe dois arrays, soma os dois arrays, e cospe um array resultante, tudo numa única instrução.

GPUs, diferente de CPUs, não tem capacidade de rodar qualquer programa genérico. Lembram do meu episódio de Turing Complete? A grosso modo, uma máquina de Turing é basicamente qualquer programa. Em particular, pra ser Turing Complete, pra ser um computador moderno, ele precisa ser capaz de rodar um programa que consegue simular ser um computador. Como exemplo mais óbvio pense uma máquina virtual. Ele nem precisa conseguir rodar na prática, mas tem que ter a capacidade teórica. Num CPU ARM M2 da Apple, é possível simular uma CPU Intel usando o Rosetta. E esse programa de Intel roda achando que tá num PC de verdade. Isso é possível porque um CPU ARM M2 é Turing Complete.

Já uma GPU não tem essa capacidade. Diferente de CPUs, que são genéricos, e podem simular qualquer coisa, mesmo que lento, uma GPU é um hardware especializado, pra executar um conjunto pequeno de tarefas bem definidas. Uma GPU não consegue rodar um sistema operacional genérico, nem simular ser outra GPU, tipo um AMD Radeon tentar simular ser um NVIDIA RTX. Não funciona assim. Quando existe camada de abstração, quem cuida disso é a CPU. A GPU é boa numa única coisa: fazer cálculos de vetores e matrizes.

Uma CPU Intel costuma ter sei lá, 8, 16, 32 núcleos com 2 threads cada, rodando a 4 ou 5 gigahertz hoje em dia. Mesmo chips de servidores como um Intel Xeon ou AMD EPIC não tem muito mais que isso de cores. Já uma GPU é diferente. Uma novíssima RTX 4090 tem nada menos que 16 mil núcleos pra shading de CUDA, 128 núcleos pra ray tracing e nada menos que 512 núcleos exclusivos só pra tensors. Uma GPU, diferente de uma CPU, tem milhares de núcleos que rodam em clocks baixos como 1 gigahertz, pra funções altamente especializadas.

O que eu falei que é o resultado do treinamento de deep learning? Um modelo de tensors n-dimensionais. O que foi feito pra calcular tensors multi-dimensionais? GPUs. Processar áudio, processar video, processar polígonos ou voxels tridimensionais, é tudo processamento de matrizes multi-dimensionais. Uma tela de computador ou do seu smartphone, como é representado? Num monitor Full HD, é um array de 1080 colunas, onde cada elemento é um array de 1920 elementos pra cada linha. Se eu quiser escurecer essa imagem inteira? Pode ser uma substração em cada valor desses arrays. Fazemos isso adicionando, ou subtraindo uma matriz por outra matriz, que chamamos de um “filtro” ou kernel.

Numa CPU, você programaria como um loop nas colunas e outro loop nas linhas pra calcular a nova cor, pixel a pixel, seria 1920 vezes 1080 operações, ou mais de 2 milhões de operações. Numa GPU eu passo a matriz inteira e ele calcula tudo numa única operação. De novo, não vou conseguir entrar em detalhes, mas essa é a diferença fundamental.

De curiosidade, um dos maiores problemas dessa arquitetura de CPU controlando GPU é o compatilhamento de memória. Em PCs modernos a CPU tem um conjunto de RAM e a GPU tem um conjunto de VRAM separados. A CPU prepara os dados e tem que mandar pra GPU processar. Daí uma vez calculado, a CPU precisa puxar o resultado de volta pra própria RAM. No frigir dos ovos, essa comunicação é um gargalo.

Não é raro vermos jogos, por exemplo, que perde frames mesmo a GPU não estando em 100%, mas se olhar a CPU, ela que tá em 100%, então vira um gargalo e a GPU fica um tempo parado esperando. Por isso desde a nona geração de consoles de videogames como PS5 e Xbox Series X se falou tanto em loads instantâneos e tecnologias de melhorar esse gargalo, como o Microsoft DirectStorage.

Também é por isso que a estratégia da Apple com os chips M1 e M2 é ser um SoC ou System on a Chip; um único chip que embute CPU, GPU e RAM tudo junto, pra minimizar ao máximo esse gargalo. Juntar tudo no mesmo lugar garante uso mais eficiente de memória e caminho mais curto de comunicação, ajudando a evitar gargalos.

Na velocidade que estamos hoje, a distância da sua CPU Intel pros pentes de RAM é gigante se comparado a soldar tudo junto no mesmo chip como a Apple faz. É um saco porque não dá pra aumentar RAM depois, mas a razão não é porque eles são uma corporação querendo arrancar mais dinheiro de vocês, mas sim porque tirar esse gargalo faz muita diferença.

A mesma coisa acontece na solução pra data centers da Nvidia, a tal arquitetura Grace-Hopper que eu falei, começa com um superchip Grace-Grace, tanto Intel quanto ARM, que eles mesmos desenvolveram, num único pacote com NVLink que é um barramento de altíssima velocidade entre eles, e a alternativa Grace-Hopper que é outro superchip que junta uma CPU Grace com uma GPU H100 Hopper.

São soluções que juntam todos eses chips junto com meio terabyte de memória RAM LPDDR5 de 32 canais. Estamos falando de 96 núcleos de 3 nanômetros. É um monstro. É esse o produto que tem feito as ações da NVIDIA disparar, porque eles encaixam perfeitamente pra acelerar processamento de transformers. Meu PC não é “parrudo”, esse da NVIDIA sim, é a verdadeira definição de “parrudo”, o atual estado da arte em 2023.

É com servidores desse tipo, não sei quantos, que se pega meio terabyte de dados, quebramos em 300 bilhões de tokens, e no final a OpenAI consegue gerar um modelo de GPT 4.0 com os tais 170 trilhões de parâmetros. Conseguem entender melhor agora essa frase? Daí a mídia e os jornalistas ficam assustados e noticiam como o GPT 4 se iguala ao cérebro humano, que tem 100 trilhões em sinapses. Lembram? Sinapses mais ou menos são os pesos ou parâmetros entre neurônios. Agora que entendemos mais ou menos o que são esses parâmetros, vamos discutir a premissa errada: parâmetros não são equivalentes a sinapses do cérebro humano.

Quando se joga números arbitrários assim no título de uma matéria, todo mundo fica empolgado. Vamos entender o erro. Pra começar, nosso cérebro, em média, tem uns 100 bilhões de neurônios. De novo, eu não sou um neurologista, então já assuma que minha explicação vai ser simplificada e de alto nível. Em pesquisa de IA, tentamos igualar neurônios biológicos com neurônios digitais numa rede neural, e falamos em bits, como num computador. Mas pra começar, neurônios não são exatamente binários assim. Um único neurônio é capaz de lidar com múltiplos sinais e conexões. Em termos de sinapse pode ter até umas 7 mil.

Isso acho que seria máximo, mas em média o cérebro é capaz de até uns 600 trilhões de sinapses. Não sei porque, dependendo de onde se pesquisa, falam em 100 trilhões, outros falam em 600 trilhões. De novo, precisa pesquisar um pouco mais a literatura de neurologia pra entender o que isso significa. Mas não é um número absoluto. Tem vários fatores. Doenças como Alzeimer, por exemplo, afeta justamente a capacidade de fazer e manter sinapses.

Em crianças, quando o cérebro ainda é muito mais elástico e não foi limitado pelo crescimento, o potencial é de 1 quadrilhão de sinapses. É um número absurdo, mas mais importante, os 170 trilhões de parâmetros do GPT 4 não se equipara à quantidade de sinapses que nosso cérebro é capaz ainda. Portanto é falso que o GPT 4 já se igualou ao cérebro humano em quantidade de sinapses.

A outra premissa que errada: um parâmetro de modelo de GPT não é equivalente a uma sinapse do cérebro humano, nem de longe. Usamos vocabulário neurológico pra simplificar a descrição em termos de inteligência artificial, como redes “neurais”. É uma metáfora. Em nenhum momento, nenhum cientista da computação vai te dizer que um neurônio de rede neural é idêntico ou sequer próximo de um neurônio biológico. É só uma abstração.

E no caso de IA, parâmetros de modelos de transformers, comparado com neurônios do cérebro. Vamos voltar ao meu Vicuna rodando localmente na minha máquina. Lembram da afirmação do povo que fez testes e otimizou esse modelo? Um modelo Vicuna de 13 bilhões de parâmetros, em muitos casos, chega até 90% da qualidade de respostas de um ChatGPT 4.0 de 170 trilhões de parâmetros. Como isso é possível?

E por isso mencionei não-linearidade e Teoria do Caos. Um único parâmetro isolado, se tentar ler e interpretar, não tem como inferir nada. Só funciona se estiver combinado com vários outros parâmetros, numa rede. O resultado final depende da interação de múltiplos parâmetros, e por isso se gasta processamento da GPU pra gerar uma resposta. Parâmetros são pesos, probabilidades. E tem várias formas de otimizar isso. Por exemplo, probabilidades pra ter o máximo de precisão podem ser valores escalares de tipo float de 32 bits. É isso que se gera num modelo depois do treinamento.

Porém, pesquisas mostram que podemos truncar esses valores pra float-16 e a qualidade das respostas não cai tão drasticamente. É uma forma de otimização. Simplificando, é parecido com o conceito de música em MP3, que dados das frequências que o ouvido humano não é capaz de detectar são cortados fora. Tecnicamente isso tira qualidade do áudio, mas na prática a maioria dos humanos não sente. Em termos de armazenamento, economizamos 10 vezes o espaço fazendo isso.

Expliquei no episódio de 25 tera pra 5 gigas, onde pegamos uma imagem bruta em bitmap e reduzimos pra um JPEG. A qualidade cai, mas o olho humano sem treinamento, não nota diferença tão grande assim. Otimizações e compressão são formas de simplificar os dados, diminuir a qualidade, de forma que nossos sentidos, sem treinamento, não sintam diferença significativa. Fazemos isso com modelos de IA também.

Reduzir os valores de Float 32 pra Float 16 é uma forma de quantização. Existem várias formas de quantização que são otimizações dos modelos, pra exigir menos processamento pra gerar respostas, sem danificar demais a qualidade. Isso ajuda a conseguir fazer um clone de ChatGPT como o Vicuna, rodar numa máquina caseira como a minha. Parece que minha RTX 3090 já é quase topo de linha, mas não. Por isso expliquei sobre a NVIDIA GH100 que é o tipo de hardware necessário pra rodar o ChatGPT de verdade.

Mas respondendo como um Vicuna de 13 bilhões de parâmetros consegue competir com um GPT 4 de 170 trilhões é porque além de quantização, os algoritmos de auto-atenção tem evoluído também. Em auto-atenção, que acontece no processo de treinamento, cada token numa sequência precisa ser considerado com todos os outros tokens pra capturar dependências e relacionamentos. Tipicamente, auto-atenção é computado dentro de uma janela de contexto, onde cada token é considerado com tokens vizinhos.

Agora tem uma variante chamada “auto-atenção global” onde cada token é considerado independente de posição ou distância, que permite o modelo capturar dependências num contexto mais global. Na prática é assim: custa mais caro pra treinar, mas os parâmetros resultantes no modelo tem mais qualidade. Então com menos parâmetros conseguimos chegar em respostas de qualidade similar. Entenderam? A qualidade de um parâmetro não é universal nem estático, está mudando à medida que aperfeiçoamos os algoritmos de treinamento e estruturas de dados.

Redes neurais, mesmo deep learning com auto-atenção global, ainda são representações rudimentares e grosseiras do nosso cérebro. Pra um GPT ou Vicuna da vida, conseguir escrever um texto com estilo de Shakespeare, precisamos treinar com todos ou quase todos os textos do Shakespeare. Pra conseguir gerar uma música parecida com Mozart, temos que dar o máximo de composições de Mozart quanto possível. O processo de treinamento vai encontrar patterns ou padrões e criar pesos pra eles, registrando no modelo. Mas isso ainda é bem ruim se comparado ao cérebro humano.

Pense você. Se estiver treinando em literatura ou música. Mesmo não lendo nem perto de todas as obras de Shakespeare, mesmo não estudando nem de perto todas as composições do Mozart, rapidamente consegue começar a copiar o estilo deles. Veja você como programador. Não precisou ler todos os códigos já feitos em React pra começar a escrever códigos. Bastou uns 2 tutoriais. Nosso cérebro consegue aprender muito melhor que um transformer, com muito menos dados, e produzir resultados similares ou melhores dentro de um mesmo determinado assunto. IA hoje em dia ainda depende muito de força bruta.

Desde que o LLaMA foi lançado em fevereiro de 2023, estamos só em junho e já temos dezenas de modelos diferentes, com vários níveis de quantidade de parâmetros, caindo desde 65 bilhões até só 7 bilhões, com vários tipos de otimização como GPTQ pra quantização, ou Float 16. E isso permite rodar algo parecido com esse meu Vicuna local, num Android ou até num Raspberry Pi.

É o que eu acho ideal: um transformer rodando localmente, offline, sem compartilhar nenhum dado pessoal meu, nenhuma conversa, com nenhuma corporação por aí. Quanto menos dados meus eu tiver que dar pra alguém, melhor. Especialmente se esse alguém não me paga por isso. Pelo contrário, pra usar OpenAI eu preciso pagar assinatura. E sabe-se lá o que fazem com minhas conversas.

Bacana, significa que se o jornaleiro fala que o GPT 4 é próximo já de um ser humano, e os nerdolas das ciências da computação já compactaram e tornaram eficientes até esse ponto do VIcuna. Então já era. Tá fácil fazer a Skynet né? Afinal, GPT 4 já consegue escrever código de programação. Basta eu carregar o código do GPT 4 e mandar ele melhorar o código e gerar o GPT 5. Daí eu pego o novo GPT 5 e faço ele fazer uma versão melhor, o GPT 6, e assim sucessivamente, até eu ter o Gigachad GPT T-1000 Skynet que vai dominar o mundo, certo?

Errado. No final do dia, um GPT 5, 10, 20, continua não sendo mais que um auto-corretor do seu teclado em versão maior. Tirem da cabeça a noção de que é uma “inteligência”. Ela não é inteligente. Tentar definir inteligência é um buraco de coelho profundo demais, vai ter gente masturbando filosofia aqui até o fim dos tempos e ninguém vai chegar numa conclusão. Vamos só assumir que até hoje não temos uma definição exata de “inteligência humana”. Na verdade, quando chamamos de “inteligência artificial” só quer dizer que os resultados, pra um ser humano, podem “parecer” com algo inteligente, mas não que de fato “é” inteligente. Entendem a diferença?

Não ter uma definição exata é ruim, porque não temos um plano exato de pra onde ir. Na neurologia de verdade, apesar dos avanços, não temos uma receita exata de como neurônios e sinapses funcionam 100%. Temos uma boa idéia. Muita coisa ainda é especulativo. Mas podemos dar alguns chutes educados baseado em tudo que falei até agora. E aqui vai ser minha opinião pessoal. Se alguém tiver pesquisas que discordam, sintam-se à vontade pra linkar nos comentários abaixo. Opinião por opinião, cada um pode ter a sua. A maioria parece estar pulando rápido demais pra religião do AGI e eu vou ser advogado do diabo e dizer porque isso não está nem perto de acontecer.

Vocês entenderam até aqui? Quando vamos na interface Web do ChatGPT ou Vicuna ou qualquer outro derivado e escrevemos o tal do prompt, a pergunta, damos uns segundos, e ele nos trás uma resposta. Mas na realidade não é isso. O que vem na verdade é uma continuação do texto do prompt. Tem uma diferença importante aqui: ele não está tentando te responder. Acontece que com os parâmetros treinados do modelo, a probabilidade maior das próximas palavras é se parecer com uma resposta. Essencialmente o que está acontecendo é similar ao auto-corretor do teclado do seu celular: dado o texto que acabou de digitar, quais palavras tem mais probabilidade de serem continuação?

Entendam essa sutileza. Por isso falo que não é uma “inteligência”. GPT ou Vicuna não são pessoas e nem entidades com cognição tentando se comunicar. É meramente um completador de textos, ou mais tecnicamente, um transformer pré-treinado generativo, um gerador de texto. Uma pergunta, ou prompt, é um texto que se digita na expectativa que o modelo consiga continuar completando. É por isso que o texto da resposta vai aparecendo aos poucos, não é uma animação arbitrária, é igual você ficar clicando na próxima palavra sugerida pelo teclado.

Um dos parâmetros que afeta essa continuação se chama temperatura. Nós não temos controle da temperatura do ChatGPT pela interface Web, mas no Bing da Microsoft tem esses controles de mais balanceado, mais preciso ou mais criativo. E no meu Vicuna tenho esse campo numérico. Novamente, do jeito que todo mundo escreve, parece que estamos configurando uma pessoa pra ser “mais criativa”. Mas isso é só parte do showzinho. Um transformer não é mais ou menos criativo, ele é mais ou menos “aleatório”. 

Temperatura controla a aleatoriedade do complemento de texto sendo gerado, o que você chama de “resposta”. O modelo assinala probabilidades pra cada possível token, que são candidatos pra ser a próxima palavra na sequência. Alta temperatura, valores maiores do que “1.0”, significa que o modelo assinala probabilidades similares a um conjunto maior de tokens. Se vários tokens tem probabilidades parecidas, as respostas podem variar mais quando se repete a mesma pergunta. Quanto maior a temperatura mais você vai “achar” que ele tá sendo mais criativo, mas também aumenta a probabilidade dele começar a dar respostas sem sentido.

Temperatura média, entre 0.5 a 1.0, é a resposta “balanceada” do Bing. Mesma coisa que alta temperatura mas ele assinala probabilidades similares pra um conjunto menor de tokens, controlando um pouco mais o que se perceberia como “criatividade”. Baixa temperatura, que é abaixo de 0.1, faz o modelo assinalar probabilidades similares pra palavras que realmente tinham mais chances de ser o próximo token. Isso faz a resposta parecer mais focada, determinística, previsível.

Respostas sem sentido, muitos chamam de alucinação. Eu não gosto desse termo, porque implica que se alucinação é temporária nas respostas, então no resto do tempo ele está sendo sóbrio ou racional. E não está. Todas as partes das respostas foram geradas mediante probabilidades do modelo. Eu só ajusto a quantidade de de aleatoriedade nos candidatos pra próxima palavra. Nada mais, nada menos. Ele nunca alucina, assim como nunca é sóbrio. Ele não é uma entidade consciente pra ser nenhuma das duas, é só um programa obedecendo probabilidades armazenadas num modelo.

Entenda, no frigir dos ovos, “criatividade” no mundo de transformers, é só uma métrica de aleatoriedade. Não tem nada a ver com criatividade humana. Assim como inteligência artificial não tem nada a ver com cognição de verdade. Transformers, e todo tipo de machine learning ou deep learning, são meros sacos de probabilidades. Eles não tem de fato cognição pra pensar “huumm, os dados dizem que a probabilidade desse evento é X, mas realmente faz sentido? tem alguma coisa que eu não estou percebendo? Deixa eu parar pra pensar”, que seria o que um ser humano inteligente consegue fazer. Transformers não refletem, só cospem exatamente o que as probabilidade do treinamento do modelo dizem pra ele cuspir, e nada mais.

Quando um transformer consegue pegar uma equação e achar a resposta, ou pegar até a planilha de balanço de uma empresa e dizer se está indo bem ou mau. Ela não está sendo inteligente. Simplesmente existem probabilidades no modelo que levam à resposta porque materiais que ele usou de treinamento tinham já a resolução de equações parecidas.

Da mesma forma que eu disse que não existe um monte de “ifs” de regras gramaticais pra conseguir escrever textos, também não tem um monte de “ifs” de regras matemáticas pra fazer contas. Sempre volte à imagem daquela lista de pares de palavras e probabilidades do exemplo do teclado com auto-corretor. Aquilo é tudo que ele tem. Um conjunto gigante de probabilidades. Toda resposta que te dá, por mais inteligente que pareça, não teve nenhum tipo de raciocínio ou lógica ou inferência, nem nada, só probabilidades.

Um texto gerado por um transformer às vezes pode parecer “simpático”. Se você for uma pessoa carente, vai parecer que o transformer responde se importando com você. Mas nada disso é intencional, é você projetando nele o que gostaria que ele fosse. Todo mundo faz isso com animais de estimação. Isso se chama “antropomorfismo”. Você pode atribuir emoções humanas pra animais ou objetos inanimados. Tem gente que jura que uma escultura sorri pra ele quando passa na frente. Obviamente não. 

Um exemplo simples disso são nuvens no céu. Vira e mexe você olha pro céu e vê claramente uma escultura nas nuvens. Dependendo da sua inclinação ideológica poderia pensar. “Uau, Deus realmente é criativo, olha que obra maravilhosa nos céus que ele está me dando”. Ou “Uau, a mãe natureza é especial, mãe Gaia continua a demonstrar sua genialidade criativa até nos céus”. Ou “Uau, a droga que eu acabei de tomar é da hora …” Só esse último pode estar certo.

O fato é que a nuvem em si não está em formato de nada. Se passar um avião por cima da mesma nuvem, não vai ver nada, ou vai ver outra imagem. Da posição que você está, na sua cabeça, suas sinapses pré-treinadas sugerem que você está enxergando a sillhueta de algum objeto ou animal que já viu antes. É um efeito colateral da nossa cognição. Poderíamos chamar de bug. É seu cérebro primitivo. O cérebro rápido, automático e meio burro.

Ninguém moldou essa nuvem, ela aleatoriamente acabou numa determinada posição, que parece ter um determinado formato. Não houve intenção. Foi aleatório. Eu diria que a IA tá pouco se fodendo pra você, mas isso implicaria que ela tem consciência. Ela nem está se fodendo pra você. Ela não pensou em você. Mesma coisa com um transformer. Ela não tem consciência, ela simples é. Uma mera ferramenta. Uma chave de fenda que sabe cuspir palavras segundo uma matriz de probabilidades. Nada mais, nada menos. Por acaso você está olhando pra chave de fenda e achando que está sorrindo pra você. Não está. Isso diz mais sobre seu estado emocional do que sobre a ferramenta.

Significa que ela não tem insights, não tem momento “eureka” de descobrimento de coisas novas. Ela só é capaz de sugerir uma palavra, depois das outras palavras que vieram antes, seguindo uma tabela de probabilidades que vieram do treinamento feito com gigabytes de texto. De vez em quando, dá impressão que ela “criou” algo que não existia, mas não é criação, é aleatoriedade, pura sorte. É a nuvem no céu. Não é um processo repetível e ela não sabe refletir algo como “uau, isso que eu inventei é da hora, nunca tinha visto antes”. Ela não tem emoções pra conseguir dizer “uau”.

Se você der o código de uma IA feita com RNNs como falei antes pro GPT 4 analizar, ela não vai magicamente conseguir chegar no paper de transformers. Se esse paper não estava no material de treinamento, ela não vai concluir sozinha que esse era o próximo passo. Portanto ela é incapaz de conseguir chegar num GPT 5. Novas descobertas precisam ser feitas por humanos, documentadas, alimentadas no treinamento da IA e só aí ela vai saber cuspir o texto desse paper. Ela é incapaz de usar o que aprendeu pra gerar descobertas novas de forma intencional. 

Existe uma historinha que é chamado do Teorema dos Macacos Infinitos. O teorema sugere que se tivermos um macaco apertando teclas numa máquina de escrever por uma quantidade infinita de tempo, quase com certeza vai conseguir digitar qualquer tipo de texto, incluindo todas as obras do Shakespeare. Na prática, estamos falando de uma quantidade tão absurda de tempo que seria impossível até de vocês terem noção, estamos falando provavelmente de mais tempo que a idade atual do Universo desde o Big Bang. Mas é um conceito que demonstra que sim, sem nenhuma inteligência, só com aleatoridade, dado um tempo absurdo, uma hora tudo que já produzimos vai aparecer. Sem nenhuma intenção, só via aleatoriedade.

É uma história pra dar noção de conceitos como infinito e aleatoriedade. Essa história é creditada ao matemático francês Felix Émile Borel, de 1913. Ou seja, desde o começo do século XX já se tinha essa noção que muitos de vocês, mais de um século depois, ainda estão com dificuldades de entender. GPT e derivados são macacos modernos dessa história. Só que em vez de totalmente aleatório, demos um modelo de probabilidades pra facilitar o trabalho dele, só isso. Mas chamar de macaco é meio ofensivo, pro coitado do macaco, que ainda é mais inteligente que qualquer IA. 

Falando em século passado. Deixa eu aproveitar pra voltar lá atrás na história das inteligências artificiais. O estudo de algoritmos e técnicas que contribuem pra esse campo existe desde os anos 50 pelo menos. Mas nos anos 70 surgiu um programa que até hoje ainda deixa os desavisados meio surpresos. O nome do programa é Eliza. Existem várias versões, inclusive rodando online. Dêem uma olhada.

(… screencast eliza …)

Como podem ver, é um chatbot também, que nem o ChatGPT. E parece uma pessoa bem desconfiada, fica dando umas respostas meio grossa. Weebs de anime chamariam ela de “tsudere”. Mas se hoje povo fica empolgado com ChatGPT respondendo, imagina isso nos anos 70. Só pra dar contexto, isso é antes da revolução dos microcomputadores de 8-bits como Commodore ou Apple II. Isso é antes da Microsoft ou Apple existirem. Nem internet existia ainda. Quando eu rodei uma versão de Eliza pra DOS lá no começo dos anos 90, lembro que fiquei fascinado e pensando como eu faria a minha própria versão. E aí vocês podem se perguntar, “caraca, mas como era possível ter isso nessa época??”

Bom, quem faz ciências da computação ou programa um pouco, já deve ter entendido o funcionamento. O modelo é super simples. É baseado inteiramente em pattern matching. Basicamente encontrar palavras-chave, ver se tem uma resposta pré-programada, e montar essa resposta, na mão. É um sistema de templates. Quando eu digo “na mão”, aqui sim, ao contrário de modelos de transformers, é realmente um monte de “ifs”. Quem já montou agentes ou robozinhos, tanto de chat de suporte ou email marketing, já fez coisa similar pra respostas automáticas. É um bom exercício de faculdade pra iniciantes.

No GitHub vai achar várias versões. Veja esta, é uma versão feita em Java. E vamos ver o tal “modelo” entre aspas. É uma lista de chaves e valores, e os valores, como podem ver, são frases pré-prontas. Por exemplo, se durante o chat você se desculpa e escreve algo como “I’m sorry”, ele quebra essa string, encontra a palavra “sorry” e nesta lista olha só, tem 3 respostas pré-programadas. Ela pode te responder “Por favor, não se desculpe” ou “Desculpas não são necessárias”. E vai escolher aleatoriamente, pra não parecer que tá se repetindo.

Só isso já é suficiente pra passar no Teste de Turing, que é um teste feito pra identificar quando uma inteligência artificial consegue enganar um ser humano numa breve conversa. Eliza é a avó espiritual do ChatGPT. Mas o ponto em apresentar a Eliza é pra vocês verem que pra enganar seres humanos, não precisa muito. Por alguma razão, nós seres humanos, somos muito fáceis de enganar e somos propensos a acreditar em qualquer coisa. Acho que somos animais com fé excessiva. É um ponto forte, mas é um enorme ponto fraco também. Eu pessoalmente sou cético, mas aí me chamam de “do contra”, vai entender. Vou continuar não sendo o trouxa, só isso.

Um ChatGPT, se eu quisesse simplificar bastante, não é muito diferente da Eliza, em conceito. É um programa que usa um modelo, um dicionário de probabilidades, que mostra frases de acordo com o que se digitou antes, roboticamente, automaticamente, pegando palavras cujos valores de probabilidade fazem mais sentido dado as palavras anteriores. Não existe nenhuma emoção envolvida. Não existe simpatia, não existe compaixão, não existe amargura. Nada. Não tem uma linha de código, nem de dados no modelo, que representam qualquer emoção. É apenas uma calculadora, que em vez de devolver números, devolve conjuntos de palavras. Só isso.

Mas e as IAs que geram imagens inéditas? Vide o próprio Dall-e 2 da OpenAI, vide o Midjourney, vide o Stable Diffusion, vide os novos plugins de geração e ajustes de imagens proprietário da Adobe, que começaram a ser distribuídos no Creative Cloud. Classificação de imagens e geração de novas imagens são campos diferentes dentro de inteligência artificial. Só pra não perder o gancho, deixa eu jogar na mesa mais alguns conceitos.

Um campo que existe desde pelo menos os anos 80 é o estudo sobre CNNs. (piada) Não, não, não é esse, é um CNN útil. Convolutional Neural Networks, que é um modelo que dizem que é bom pra processar dados que se parecem com grades, como uma grade de pixels, que é como representamos uma imagem. As tais camadas convolucionais, não sei se é assim que fala em português, aplicam vários filtros ou kernels, aos dados de pixels pra criar um mapa de funcionalidades. 

Em resumo, esses filtros extraem características da imagem. O equivalente a tokenizar um texto e gerar palavras ou n-grams. Mas CNNs ficaram super famosos só depois de 2012 quando saiu a AlexNet de Alex Krizhevsky, Ilya Sutskever e Geoffrey Hinton. (piada) Arregacei os nomes, mas beleza. Era um concurso que todo ano o vencedor ficava um pouco melhor do que o do ano anterior. Mas em 2012, o salto foi uma ordem de grandeza melhor. Não lembro os números, mas faz de conta que todo ano os melhores algoritmos conseguiam identificar 85% das imagens, no ano seguinte, 86%, aí do nada deu um salto pra 99%. Isso gerou um enorme interesse na comunidade de pesquisa em cima de classificação de imagens.

Em paralelo, em 2014 surgiu o conceito de GANs, Generative Adversarial Networks ou redes generativas adversárias, desenvolvido pelo Ian Goodfellow e seus colegas. Foi um avanço no conceito de geração de imagens. De forma simplificada é como se fossem duas IAs uma competindo com a outra. Um gerador cria imagens e um discriminador avalia. Por exemplo, digamos que quero gerar imagens de gatos, o gerador faz as imagens, e o discriminador tenta identificar se é um gato mesmo. É um sistema que acelera o processo de aprendizado por fornecer feedbacks mais rápidos do que um treinamento supervisionado por humanos.

CNNs e GANs eu mencionei mais pra vocês saberem alguns nomes importantes. Mas o Dall-e da OpenAI não usa GANs, ele usa um derivado do modelo de transformers do GPT só que aplicado a imagens. Assim como geração de respostas de texto, onde ele vai prevendo uma palavras após a outra, levando o contexto anterior em consideração, o Dall-e também usa uma arquitetura de transformers, criando imagens um pedaço atrás do outro. Ou seja, também usa mecanismos de auto-atenção em vez de camadas recorrentes ou convolucionais tradicionais.

Essa não é a única forma de se criar um gerador de imagens. Mais do que o Dall-e, que é fechado, eu gosto mais do Stable Diffusion que, assim como o LLaMA da Meta, também foi liberado publicamente como modelo aberto. Quem me acompanha no Instagram viu quando eu fiquei brincando de usar o Stable Diffusion com outras ferramentas abertas pra fazer remasterização, upscaling de video. Assim eu pegava um video super antigo com qualidade de DVD e conseguia fazer ele redesenhar uma versão 4K. Se não viu isso, veja o destaque “Usando IA” no meu Insta. Enfim, diferente do Dall-e que usa transformers, o Stable Diffusion, como o próprio nome diz, usa um modelo de difusão.

Esse modelo gera imagens simulando um processo aleatório rodando em reverso, ou seja, o processo de geração começa com uma simples distribuição, como um Gaussian noise, literamente um gerador de barulho aleatório mesmo, e vai gradualmente refinando esse barulho, passo a passo, até chegar numa imagem que parece com os dados que o modelo foi treinado. É meio como partir de um punhado de argila, tudo bagunçado, e passo a passo ir esculpindo e refinando, até chegar numa estátua. Esse processo de refinamento é dirigido por uma rede neural que aprende a predizer o próximo passo da difusão. E por isso se chama Stable Diffusion, ou Difusão Estável.

Um site que parece que tem ganhado relevância na comunidade de pesquisa e desenvolvimento de ferramentas e modelos de IA, é o HuggingFace. Ele serve como um repositório. É de lá que podemos baixar os modelos do LLaMA, Alpaca, Vicuna em todos os diferentes tamanhos e formatos. Existem modelos específicos pra texto como o Vicuna, específico pra imagens como o do Stable Diffusion, conversor de texto pra áudio como o Speech T5 do Facebook e muitos outros. O ponto é que não existe uma única inteligência unificada que faz tudo, existem modelos isolados e independentes feitos pra tarefas específicas. Um GPT não sabe converter texto em áudio, isso é outro modelo.

Portanto, quando ver produtos web que parecem uma única inteligência, não é, é um integrador que divide o que você pediu entre diversas inteligências diferentes. O que me leva a outro tema que queria tocar de leve, mesmo porque só comecei a estudar isso recentemente. Eu expliquei como as coisas funcionam, superficialmente, por baixo dos panos. Mas agora precisamos falar do que fica por cima dos panos, o que usuários normais como eu e você enxergam, a interface.

Não só interface gráfica web de chat, mas interface de APIs e tudo mais. Surgiu um framework que tem ganhado cada vez mais relevância na comunidade que está investindo pra construir ferramentas integradas com os diversos serviços de IA que mencionei, como GPT, Bard, Stable Diffusion e outros. Esse framework se chama LangChain. A grosso modo, pense um framework como Django, ou Laravel, ou Rails, ou Spring, mas feito pra construir aplicativos que usam IA.

Eu gostei particularmente da documentação. Pra um projeto de código aberto novo, tem material suficiente de estudo, incluindo pesquisa de papers acadêmicos sendo publicados agora. Em particular queria tocar no ponto de prompts. A moda dos parasitas sangue-suga agora, é criar cursos online de prompts. Já viram por aí? “Vire um Engenheiro de Prompt”. É a coisa mais idiota que já vi.

Seria o equivalente a você se chamar de “Engenheiro de Pesquisa no Google”. Já deixo a dica pra você: não faça nenhum deles. Sem nem olhar, posso garantir que quase todos são pega-trouxa. Lembra aquele ditado? Todo dia um malandro e um otário acordam e vão pra rua, e quando se encontram, rola negócio. Não seja o otário.

Enfim, o LangChain é um framework extenso. Não pense algo simples como um Express de Node.js. Isso tá mais pra um Spring de Java. Tem diversos conceitos, como Models pra interfacear com os diversos serviços de IA, como o ChatGPT. A grosso modo esses Models seriam como um Hibernate, um ORM pra IAs. Mas tem outras abstrações. Tem Agentes. Tem Correntes. Tem Índices, mas uma das partes interessantes é que tem Prompts.

Diferente desses cursinhos idiotas por aí, que ficam mais no esquema “olha só, eu testei uns prompts aqui e vou compartilhar com vocês” ou então povo que fica copiando teorias da conspiração de prompt que surgem no Reddit. De fato existem pesquisas acadêmicas sendo feitas no estudo das melhores formas de se fazer perguntas pra passar pra um transformador generativo como GPT. Lembram o que eu falei? Os transformers só continuam adicionando palavras na frente do prompt que você escreveu. Quanto melhor escrito for o prompt, maiores as probabilidades de se conseguir as respostas que procura. Ele vai conseguir prever melhor as palavras seguintes.

O melhor prompt não é escrever um textão aleatório, mas sim conciso e estruturado. Na documentação eles fazem links pros diversos papers acadêmicos com o estudo pra cada tópico. Eu não levaria 100% a sério, nem todos os papers são consenso, muita coisa é só teoremas e hipóteses. Mas é melhor do que chutes do YouTuber.

Com um LangChain, eu poderia fazer um Model que se integra com o meu Vicuna rodando localmente, daí poderia não depender de serviços de terceiros e também manter a privacidade dos meus dados, já que não preciso compartilhar nada com ninguém. Se alguém tiver interesse de estudar, pesquisar ou até empreender com essa nova geração de transformadores, essas são ferramentas que podem ser muito úteis. Esquece curso idiota que é “duh, olha só como sou inteligente, sei integrar com a API da OpenAI”. Sério, isso é o básico do básico do básico, você aprende em 10 minutos num blog post. Não tem absolutamente nada demais. 

Aliás, um curso de IA que se preza, tem por obrigação ter tudo que eu falei neste vídeo, só que explicado com 10 vezes mais detalhes. Caso contrário não vale seu dinheiro e muito menos seu tempo. Não perca tempo com esses cursos caça níquel. São todos perda de tempo. Veja os links que deixei na descrição do video e estude um a um que no final você vai aprender muito melhor, e de graça. O hype em torno de IA está fora de proporção. Um prato cheio pros oportunistas de plantão.

Pra finalizar, acho que vale a pena voltar na questão que incomoda todo programador iniciante: “mas será que com essa evolução rápida de transformers, não é questão de tempo até ele substituir todos os programadores?”. Eu já tinha feito um video só pra responder isso e recomendo que assistam, mas considerando o que expliquei hoje, vou explicar porque, tecnicamente, isso não vai acontecer.

Primeiro. Um transformer é incapaz de gerar textos sobre assuntos que nunca viu na vida. Isso é importante de entender. Vamos recordar, o que é um modelo, é um banco de dados de tokens retirados dos textos de treinamento e mais importante: as probabilidades de um token pra outro token dentro de uma rede. O modelo não contém o texto original, só pesos.

Vou repetir porque isso é importante: nenhum texto original aparece na sua forma original, dentro do modelo. Pra ter na cabeça pense assim. Já viram que vários livros no final tem algumas páginas com um “índice remissivo”? São todas as palavras importantes que aparecem no texto do livro e as páginas onde aparecem. É que nem um índice rudimentar de banco de dados.

Quando fazemos um prompt e pedimos, sei lá, pra ele citar um trecho da peça King Lear, de Shakespeare. Vai gerar o trecho, se não igual, muito próximo ao trecho do texto original. E isso confunde, pois parece que então, ele tem o texto inteiro guardado em algum lugar. Mas não. Por exemplo, pedi pra ele citar um diálogo entre Albany e Cordelia e corretamente diz que não existe diálogo entre os dois na peça, e sugere outra cena, Ato 4, Cena 2, onde Albany fala com sua esposa Goneril. E segue o trecho exatamente como está na peça. 

Novamente, é muito difícil traçar o caminho exato dentro do modelo, indo de probabilidade em probabilidade pra reverter o processo e descobrir como o GPT conseguiu escrever o texto. Mas podemos dar um chute educado: a sequência de palavras do diálogo tem altíssima probabilidade. Primeiro, no meu prompt tem todas as palavras-chave importantes pro contexto como “Shakespeare”, “Albany” e tudo mais.

Quando ele começa digitando o trecho “You are” no contexto to diálogo, a chance maior é da próxima palavra ser “not”, depois da palavra ser “worth”, depois ser “the” e depois “dust”. São as probabilidades mais altas dessa sequência. Ele não tem o texto original, mas tem as probabilidades, que permitem remontar uma boa parte do texto original.

Até certo ponto, a grosso modo, o modelo acaba servindo como uma versão comprimida dos textos originais, mas com perdas. Quebramos todos os textos em tokens e gravamos os relacionamentos de forma que é possível recuperar alguns desses textos. Mas não podemos garantir que é possível recuperar tudo, porque a mistura de alguns textos similares vai desajustar as probabilidades.

No final teríamos no máximo uma versão mesclada de dois ou mais textos. Quanto mais repetidas vezes um determinado texto aparece em diversas fontes no material de treinamento, maiores as chances de conseguir reconstruir depois. Shakespeare, tendo obras que foram analisadas, discutidas e citadas inúmeras vezes em várias fontes, tem maiores chances de ser reconstruído.  

Sobre mim, Fabio Akita, já vai ser mais difícil, porque no contexto geral da Web, eu sou extremamente pouco citado. Mesmo assim, o GPT 4 até que consegue fazer uma descrição super genérica sobre mim. Fala coisas certas, por exemplo, que sou brasileiro, que fundei a CodeMiner, que palestrei em eventos e ajudei a divulgar Ruby on Rails. Mas aí fala que também ajudei a divulgar metodologias Ágeis, que não é mentira, mas nunca foi um ponto importante.

Ele fala que fui “keynote speaker”, ou seja, que dei palestra de abertura em muitas conferências, o que não é verdade. Ele já começou a misturar informações de outras pessoas similares. Mas isso não é acidente, é porque comparado a um Shakespeare, não tem quase nada sobre mim na Web, e as probabilidades são muito parecidas com outros palestrantes de tecnologia da mesma área.

Por isso também é difícil pra ele citar fontes exatas, porque cada palavra do texto que gera pode ter vindo de um lugar diferente. Não tem como saber exatamente. Pra ter links pra fontes, como o Bing faz, especulo que precisa de um processo em duas ou mais etapas. Primeiro, gerar o texto da resposta, como um GPT faz. Depois, pegar esse texto e fazer uma pesquisa tradicional no Bing antigo. Daí cruzar as duas informações e ver se os textos minimamente batem, e finalmente apresentar juntas, como se a resposta já tivesse saído pronto com os links pras fontes. 

Não é o transformer que dá os links, é um segundo processo separado. Porque o modelo do transformer, em si, não tem como garantir exatamente qual parte veio de onde. Quanto mais um certo assunto tiver textos pra treinar, mais precisas vão ser as respostas. Por isso é mais fácil conseguir informações sobre celebridades, do que sobre alguém como eu ou vocês. No nosso caso, nossas informações vão ser misturadas com de outras pessoas similares, porque as probabilidades não vão ajudar. 

Lembra a temperatura de “criatividade”? Ela garante que, mesmo sem saber a resposta exata, o ChatGPT vai continuar tentando responder baseado nas probabilidades que tem no modelo atual. Mas não tem jeito, toda resposta sobre coisas que não tinha no material original de treinamento, ou tinha muito pouco, vai ser uma alucinação probabilística. Só isso. E vai estar errado. E isso vai acontecer com tudo que for novidade. No dia 1, todo transformer vai ser praticamente inútil.

Outra coisa, mesmo sendo capaz de ler código, explicar código dos outros e gerar códigos, ainda não vai ter a capacidade de gerar um projeto inteiro. Lembra os códigos vazados do Twitch ou o código de ranking do Twitter que eu analisei? Estamos falando de milhares de arquivos, centenas de milhares de linhas de código. Sabe qual é um dos calcanhares de aquiles de toda IA? Backtracking e memória. As respostas costumam ser boa hoje porque ele leva em consideração o texto anterior. Em partes.

Existe um limite de quanto consegue voltar atrás no texto anterior. No caso do GPT 3 e 4 atual, ele se limita a enxergar uma janela de contexto de no máximo 2048 tokens. E as respostas também tem um limite. Quanto mais longo for esse limite, mais caro fica pra processar o resultado seguinte do gerador de palavras, maiores as chances dele começar a “esquecer” o contexto e muito maiores as chances de rapidamente perder a coerência de respostas longas.

Entendam: o GPT atual não tem capacidade de ler mais que 2048 tokens. Então jogar o código inteiro da kernel do Linux pra ele analisar, por exemplo, é impossível. E pedir pra ele escrever um código desse mesmo tamanho, é mais impossível ainda. Lógico, nada é impossível, mas é altamente improvável. No meu Vicuna rodando local, tem essa tela de configuração pra justamente configurar o tamanho da janela de contexto e de resposta. E não é um número muito grande não,

Num teste não científico, tentei abrir duas janelas do projeto text-generation que é a interface web que estou usando em cima do Vicuna. Não sei se é uma precaução da interface web ou uma limitação do próprio Vicuna por baixo, mas só tem capacidade de responder uma pergunta de cada vez. Se eu abrir outro navegador e tentar fazer outra pergunta, enquanto na outra janela ele ainda não terminou de responder a primeira, vai ignorar e não deixa rodar em paralelo.

E mesmo se conseguisse. Só com um único processo de resposta, está consumindo, no mínimo, 50% da minha GPU, consumindo mais de 18 gigabytes de VRAM, e enquanto responde esse consumo continua aumentando. Ou seja, numa máquina como a minha, ele só consegue responder uma pergunta de cada vez. Você está pensando em fazer um serviço online, SaaS, pra vários usuários acessarem? Vai sair super caro, porque só vai possibilitar uma resposta a cada 2 a 5 segundos. Um servidor web pequeno tem capacidade pra responder, sei lá, 1000 requisições por segundo ou mais. Mas um Vicuna está mais pra 0.2 requisições por segundo. É ridiculamente pesado e não escala.

Não lembro que artigo que a OpenAi falava que cada dia de operação do ChatGPT custa 1 milhão de dólares. Sim, 1 milhão, por dia. Mais ou menos faz sentido, dado o custo de GPU necessário pra responder todo mundo. Mas claro, novas técnicas de otimização tem aparecido, como o exemplo de quantização que expliquei antes, mas estamos falando que precisa melhorar ainda umas 10 mil vezes pra ficar economicamente viável pra casos como escrever um livro inteiro de 500 páginas, sem perder coerência, ou escrever um projeto de verdade com milhares de arquivos de código. No estágio atual da tecnologia, isso é impossível.

Essas são só algumas das razões de porque um ChatGPT não vai substituir programadores e outras profissões. A partir de um certo ponto fica tão caro que não compensa, especialmente porque como já expliquei, essa ¨inteligência" não é inteligente, só cospe probabilidades. Não tem criatividade, não sabe tomar decisões baseadas em coisas como custo-benefício ou bom senso. Não vai ter coerência em respostas longas, não tem noção se o código sendo cuspido tem segurança, ou escalabilidade. Ela tem memória menor que um peixinho dourado. 2048 tokens. Mesmo se aumentar 10x esse limite, ainda é super pouco. O script deste episódio tem 15 mil palavras. O ChatGPT é incapaz de escrever meus scripts.

Mas tudo bem, como uma ferramenta de auxílio, é super boa. Trechos pequenos e repetitivos, ou código trivial que facilmente encontramos num stackoverflow repetidas vezes. O estado atual de transformers é mais que suficiente pra acelerar um bom profissional. Hoje é impossível e vai continuar sendo impossível alguém que não é programador conseguir fazer um projeto complexo inteiro. Qualquer um que diga o contrário não tem a menor noção do que está falando. Considere como os algoritmos funcionam e considere os pontos de máximo e mínimo. Não basta dizer “ah, eu tenho esperança, é só ter fé”. Precisamos de números e os números dizem que é extremamente improvável.

Eu uso o GitHub Copilot faz meses. Em vários videos, toda vez que aparece trechos de código, usei a ajuda do ChatGPT ou Copilot. Ambos tem plugins pra vários editores como NeoVim ou VS Code e funcionam super bem. Tem capacidade de ler o código do arquivo que se está editando. Não consegue usar o projeto inteiro de contexto pelos limites que acabei de explicar, mas só de usar o trecho próximo do que está digitando, já ajuda muito. Ou seja, parte do prompt é o código do arquivo aberto naquele momento. 

Pra mim, vale cada centavo. E todo desenvolvedor que quiser ter vantagens de produtividade, deveria considerar usar esses plugins. De novo, não vai conseguir fazer tudo pra você, e por causa da aleatoriedade e alto risco de alucinações, você nunca deve aceitar o código que ele sugere sem ler com muita calma antes. Mas pra tarefas bem braçais, tediosas, onde faríamos muito copy e paste, como fazer testes unitários simples, ajuda. Testem.

Com tudo isso que expliquei, minha conclusão pessoal é que não estamos nada perto do que o povo chama de AGI, ou Inteligência Artificial Geral. A IA que vai superar todas as IAs. A IA que vai pegar o código inteiro do GPT 4 e sozinho gerar um GPT 5 melhorado. O coitado male male tem capacidade de lembrar de um único arquivo de código, que dirá milhares. Mesmo se conseguisse, ele não estará “analisando”. Ele não analisa nada. Ele não sabe analisar. Não sabe as regras de cálculo, as regras de programação. Só sabe juntar pedaços que viu repetidas vezes de muitas fontes, 100% via probabilidades. Quando não sabe, vai pegar as probabilidades mais próximas e cuspir o que der, e vai ser um texto sem sentido nenhum.

Vou repetir: transformers não tem inteligência nenhuma de análise e cognição. Ele não sabe porque 2 mais 2 é 4, só leu muitas vezes que é, e as probabilidades fazem ele repetir isso. GPT quer dizer Transformer Generativo Pré-Treinado. Hoje você entendeu o que esses termos significam. E se ficou até aqui, espero que tenha entendido: por mais impressionante que pareçam os textos que gera, é só um gerador de textos, um auto-corretor de teclado de celular glorificado.

Um gerador de textos nunca vai ser inteligente. Só vai “parecer” inteligente. Assim como o formato de animal que você viu numa nuvem foi totalmente um acidente. Ninguém teve a intenção de desenhar um animal na nuvem, sequer é um animal, é só um formato aleatório. Foi você que escolheu entender assim. 

E foi por isso que no outro episódio de ChatGPT eu afirmei e repito: Seu grau de empolgação com IA é inversamente proporcional ao seu entendimento de IA. Quanto menos entender, mais empolgado vai ficar. Vai acreditar que as ações da NVIDIA estarem a mais de 400 dólares é normal, porque acredita que negócios de IA vão aumentar absurdamente e em breve a ação vai atingir 1000 dólares. Vai investir todo seu dinheiro nisso. Já eu, acho que a ação da NVIDIA está hiper valorizado por puro hype. O preço justo da ação deveria ser abaixo de 300 dólares, e vai voltar pra isso uma hora. Não sei quando vai estourar, mas eu estou precavido.

Não tenho dúvidas que transformers são úteis. Várias ferramentas já estão usando. Em particular o Creative Cloud da Adobe tá tirando bom proveito. A Microsoft vai embutir em Office, Windows e tudo mais. Mas no final é isso que vamos ter: um Alexa melhorado. Um template mais inteligente de Excel. Mas não ache que vai substituir seu Diretor Financeiro e que ele vai conseguir tomar decisões inteligentes. Só parece, por sorte e por acidente. Quem apostar em mais do que isso, nas tecnologias atuais, vai perder.

Pessoalmente eu acho que as tecnologias de transformers e outras que nem mencionei hoje que compõe o que é o GPT, assim como tudo, segue uma curva em S. Passamos pela parte do S que é o crescimento que parece exponencial, mas a curva tem um teto em cima. Quando pulamos de bilhões de parâmetros pra trilhões de parâmetros, vamos começar a ter retornos diminuídos, diminishing returns. Se amanhã sair um GPT 5 com o dobro de parâmetros, sei lá 300 trilhões, não vai ficar duas vezes melhor. Talvez melhore sei lá, 20%. Cada melhoria custa mais caro do que o retorno. Isso é diminishing returns. 

Não existe crescimento infinito, e quanto mais rápido você força, só chega mais rápido no teto. Precisa acontecer novas descobertas, novas invenções que ainda não conhecemos, obviamente, pra ter uma nova etapa de evolução significativa. Enquanto isso não acontecer e só insistir no que temos até hoje, não vai ser muito melhor que isso não. Já estamos perto do limite. E AGI não está no horizonte ainda. É a mesma coisa ficar especulando se estamos pertos de conseguir construir uma USS Enterprise. É irrelevante, beira ficção científica.

Acho que já me estendi demais. Como falei no começo do video, eu não sou nem de longe um especialista no assunto, sequer tenho experiência prática de trabalhar em projetos relacionados. Meu conhecimento até agora é puramente teóricos. Eu só pesquisei o que existe publicado online. Se eu entendi até aqui em poucos dias, quem dedicar algumas semanas vai acabar sabendo muito mais do que eu, muito rapidamente. Não é tão difícil assim. Espero que tenha dado pra quebrar alguns mitos que tinham na cabeça e finalmente tenham conseguido separar o joio do trigo. Se ficaram com dúvida ou quiserem complementar, fiquem a vontade nos comentários abaixo. Se curtiram o video deixem um joinha, assinem o canal e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais.

Assunto delicado mas importante. Muitos não sabem que podem ter transtornos neurológicos como TDAH, Autismo, que podem ser a razão de crises de ansiedade, depressão. E isso pode estar afetando seu aprendizado, sua carreira e seus relacionamentos. Vamos entender o que de fato são esses transtornos, como eles se manifestam, como funcionam e o que você poderia fazer.

Capítulos

• 00:00:00 - Intro
• 00:00:33 - CAP 00 - Por quê? Objetivos
• 00:02:11 - CAP 01 - Definições - Introdução
• 00:04:07 - CAP 02 - Depressão - Você pensa assim?
• 00:06:33 - CAP 03 - TDAH - Introdução a Deficit de Atenção
• 00:10:34 - CAP 04 - Espectros - Transtornos não são binários
• 00:12:31 - CAP 05 - Cérebro - Fisiologia do Transtorno
• 00:17:27 - CAP 06 - Efeitos do TDAH - O que o transtorno faz?
• 00:22:44 - CAP 07 - Motivação - Você Procrastina?
• 00:27:29 - CAP 08 - Ansiedade - Como Lidar?
• 00:30:03 - CAP 09 - Sensitividade à Rejeição - Caminho pra Depressão
• 00:33:33 - CAP 10 - Por que temos esses Transtornos? Teoria Evolucionária
• 00:38:47 - CAP 11 - Genética + Ambiente - O que fazer?
• 00:43:14 - CAP 12 - Qualidades de TDAH? Boas Notícias
• 00:46:24 - CAP 13 - Meu Espectro Autista - Como é pro Akita?
• 00:53:03 - CAP 14 - Conclusão - Próximos Passos
• 01:00:07 - Bloopers

Links

• Paper: Amygdala Abnormalities in Adults With ADHD (https://pubmed.ncbi.nlm.nih.gov/26964869/)
• Paper: The heritability of clinically diagnosed Attention-Deficit/Hyperactivity Disorder across the life span (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4071160/)
• Paper: Genomic analysis of the natural history of attention-deficit/hyperactivity disorder using Neanderthal and ancient Homo sapiens samples (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7248073/)
• Paper: The Emerging Neurobiology of Attention Deficit Hyperactivity Disorder: The Key Role of the Prefrontal Association Cortex (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2894421/)
• Paper: Associations of Irritability With Functional Connectivity of Amygdala and Nucleus Accumbens in Adolescents and Young Adults With ADHD (https://pubmed.ncbi.nlm.nih.gov/34724835/)
• Paper: Anxiety modulates the relation between attention-deficit/hyperactivity disorder severity and working memory-related brain activity (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5581282/)
• Paper: Evaluating Dopamine Reward Pathway in ADHD (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2958516/)
• Paper: Hunter in a Farmer’s World (https://www.longdom.org/open-access-pdfs/hunters-in-a-farmers-world-adhd-and-hunter-gatherers-2332-0915-1000150.pdf)
• Livro: ADHD: A Hunter in a Farmer’s World (https://www.amazon.com.br/ADHD-Hunter-Farmers-Thom-Hartmann/dp/162055898X)
• Livro: Adult ADHD: How to Succeed as a Hunter in a Farmer’s World (https://www.amazon.com.br/Adult-ADHD-Succeed-Hunter-Farmers/dp/1620555751)
• Dr. Tracey Marks (https://www.youtube.com/@DrTraceyMarks)
• HealthyGamerGG Channel (https://www.youtube.com/@HealthyGamerGG)

SCRIPT

Olá pessoal, Fabio Akita

Imagino que o thumbnail deixou vocês preocupados de alguma forma, e tenho certeza que alguns vieram aqui pra saber que merda que o Akita vai cagar regra. Então deixa eu já começar com um enorme disclaimer: este video, de maneira nenhuma, deve servir de base pra diagnóstico de ninguém. Então qual o objetivo?

Quero falar um pouco sobre desordens psicológicas, que é um assunto muito importante, que afeta seu aprendizado, sua carreira, relacionamentos e sua vida em geral. Este video provavelmente vai ser o único onde vou falar sobre esse assunto, então vai ser denso como de costume.

“Porra Akita, você não é psicólogo nem nada, vai cagar regra até nisso?” Tem toda razão de pensar assim! Não é um assunto pra ser discutido sem cuidados. Nada do que vou dizer hoje é recomendação, muito menos substitui consultar um especialista licenciado. Nem este video, nem nenhum que você encontrar online, especialmente nos TikToks da vida, representa qualquer tipo de solução, só informação.

Lifehacks são divertidos de compartilhar, mas a intenção de hoje não é isso também. É aumentar awareness ao problema. Embora eu não goste da palavra em português, é contribuir na “conscientização”. Tentar ajudar a tirar o estigma e alguns mitos. Tudo isso tem base científica e tem toneladas de pesquisa pra entender.

Minha experiência e interesse existem porque ao longo de anos, sempre acabei me relacionando com pessoas neurodivergentes. E eu não gosto de não entender o que está acontecendo. Mais do que isso, eu mesmo sou neurodivergente. Sim, eu fui diagnosticado com T.E.A. transtorno do espectro autista, nível 1, por psicólogo, um ano atrás. Portanto também significa que eu queria entender um pouco mais de como minha própria cabeça funciona.

(…)

Faz anos que esse assunto fica flutuando na minha cabeça. Por um lado, eu sempre sou super cético. Alguns assuntos, categoricamente podemos dizer que é pseudociência, seja astrologia, homeopatia, os MBTI da vida. Sendo eu um boomer, muitos problemas psicológicos e psicologia em geral, na minha cabeça, sempre pareceu encaixar mais com pseudociência que ciência. Tenho certeza que muitos dos meus pares, povo da faixa de 40 anos pra cima, ainda pensam assim. E é um dos motivos que resolvi explicar um pouco disso.

O que está mais na moda falar é TDA ou TDAH, que em inglês é ADHD, o famoso transtorno ou desordem de déficit de atenção. Procurando no YouTube vem centenas de videos sobre isso. Comparando com meu próprio conhecimento antes de pesquisar sobre, sei que é muito fácil entender esse transtorno da maneira errada. Pra começar, todos vocês assistindo, ou são considerados neurotípicos ou neurodivergentes.

Neurotípico é um termo usado pra descrever pessoas cujo desenvolvimento neurológico ou padrões de comportamento são considerados típicos ou “normais” pra determinada idade ou cultura. Vocês não costumam ter diferenças significativas em processamento sensorial, interações sociais ou estilos de comunicação.

Neurodivergente, por outro lado, é um termo usado pra descrever pessoas cujo desenvolvimento neurológico e padrões de comportamento são considerados “atípicos” pra faixa etária ou cultura. Isso pode incluir condições como TEA ou transtorno do espectro autista como no meu caso, ou coisas como TDAH, dislexia e outras condições de processamento cognitivo, sensorial ou emocional.

Importante explicar, coisa que eu também não entendia, que neurodivergência não é uma patologia, uma doença, mas uma variação nas funções neurológicas. Significa dizer que o perfil psicológico é diferente do que é considerado “típico”. Pessoas neurodivergentes sofrem com problemas mas ao mesmo tempo podem ter formas únicas de esforço, perspectiva e jeitos de interagir com o mundo, que tem muito valor. Vou chegar nesse ponto.

O problema é que, sem as informações adequadas, quem sofre disso pode realmente achar que é uma doença. E como não é visível como uma perna amputada, essa pessoa pode sentir muita vergonha, muita culpa. E isso vai evitar que ela procure o tratamento adequado. Todos os transtornos psicológicos são espectros. Significa que não existe um tratamento geral pra todo mundo. Não existe fórmula mágica. E ao sofrer as consequências desses não entendimento, muitos podem cair em problemas maiores depois. Deixa eu ilustrar.

Vamos começar com algumas perguntas. Você costuma ter pensamentos de que não é bom o suficiente? Inclusive no sentido de supervalorizar seus fracassos e subestimar ou desvalorizar seus sucessos? Na sequência, isso te leva a pensar que fracassa tanto que ninguém liga pra você ou vão deixar de ligar pra você? Afinal, porque alguém iria ligar pra alguém fracassado né? Daí você costuma ter a sensação de, “pra que me esforçar”, é melhor ficar sozinho, não? Talvez doa menos. Pior, você se sente constantemente cansado, indisposto, até com aquela sensação que tá meio doente? E aí pensa, lógico, nem eu me aguento comigo mesmo, quem vai querer ficar perto de alguém como eu?

Se pensa até aqui, provavelmente já deve ter pensado algo como “além do mais, ninguém entende como eu me sinto”. E é verdade, muitas das pessoas ao seu redor não tiveram que passar pelo que você passou, mas seu pensamento vai além, você acha que ninguém vai ser capaz de te ajudar, nem mesmo ajuda profissional. Você acha que seu caso é único, seu fracasso vai ser constante, seu esforço parece inútil?

Pior do pior, quando outras pessoas te vêem nesse estado, ficam te falando “vai fazer exercícios, vai comer melhor, vai fazer alguma coisa”, e você vê todo mundo conseguindo fazer atividades que você não consegue e, de novo, isso aumenta sua sensação que é tudo culpa sua, certo? Você se sente culpado de ser incapaz de se tirar dessa situação desesperançosa, e se afasta mais ainda das pessoas. FInalmente, isso te leva à inevitável conclusão de que nada mais importa, nada do que você tenta fazer jamais vai ser suficiente, e claro, você nunca vai melhorar.

Já pensou dessa forma repetidas vezes? Ao ponto de ficar debilitado, sem querer fazer nada, faltando faculdade, faltando trabalho, faltando eventos sociais ou familiares? Ficando o dia todo maratonando Netflix, maratonando TikTok, ou no seu LOL ou Valorant da vida, horas e horas sem parar? Ou simplesmente escondido na sua cama o dia todo? Você está ficando pra trás, todo mundo parece tão distante lá na frente e você sente que não tem o que fazer?

Se sim, é possível que você esteja experimentando sintomas de depressão. Coisas como TDAH, autismo ou outros transtornos, se não forem tratados, podem te levar a pensar dessa forma. E de novo, não estou tentando te dar um diagnóstico, mas se sente assim, no mínimo deveria procurar um especialista, porque ao contrário do que parece na sua cabeça, essa situação é ruim, mas não tanto quanto pensa e o principal, isso não é permanente. Agora deixa eu explicar porque alguns chegam nessa linha de pensamento.

Vamos pegar TDAH por exemplo, transtorno de déficit de atenção. A primeira impressão é que se trata de uma pessoa que tem dificuldade de prestar atenção em alguma coisa. Só que não é isso. Se uma criança é diagnosticada com TDAH, alguns pais podem discordar, porque eles vêem que essa criança consegue ficar o dia inteiro jogando os Fortnite ou Roblox, nem precisa comer, está em hiperfoco. Mas não consegue prestar atenção na aula ou estudos. Então ela não tem déficit de atenção, só é preguiçosa mesmo.

Antes de continuar, deixa eu fazer mais um disclaimer. Existem sim, pessoas que que por diversos motivos se tornam maliciosas, mau caráter, desonestas e tudo mais. Vou pular esses casos, não é esse o foco de hoje. Assuma por um segundo que a criança do exemplo, não tem razão pra ser desonesta. Vou assumir que você assistindo é honesto.

E sim, de fato essa criança hipotética tem capacidade de hiperfoco em algumas atividades e não em outras, e isso é um déficit de atenção. Déficit não significa que ela tem atenção baixa o tempo todo, significa que, comparado com uma pessoa típica, tem uma montanha russa de atenção: algumas vezes super abaixo, algumas vezes super alto, e o principal: não tem controle sobre isso. Por isso é um transtorno ou desordem, não é uma incapacidade.

Algumas pessoas romantizam o tal hiperfoco, mas pra pessoa com TDAH não parece tão legal assim porque não é um super poder que pode ativar quando bem entender. Uma das melhores metáforas que encontrei foi assim: digamos que essa pessoa tem um compromisso muito importante às 6 da tarde. Fodeu. Ela vai passar o dia todo ansiosa com esse compromisso e vai ser incapaz de fazer qualquer outra coisa durante o dia até essa hora. Ou, se conseguir começar a fazer, é possível que esqueça do compromisso original.

Por que? Faz de conta que sua cabeça tem um editor de textos. Os neurotípicos conseguem salvar o documento parcial, deixar de lado, e abrir outros documentos pra trabalhar. Já uma pessoa com TDAH não tem a funcionalidade de salvar. Ou ela mantém o documento aberto até as 6 da tarde, ou se fechar, pode perder. Não é exagero, é assim que funciona.

Todo mundo tem algum grau de inatenção, hiperatividade ou impulsividade, que são características de TDAH. O problema é quando o transtorno afeta negativamente a vida da pessoa, ou seja, ela começa a se tornar incapaz de funcionar como gostaria, vai mal na escola, vai mal no trabalho, vai mal nos relacionamentos. E não é um episódio isolado, onde podemos identificar um momento de estresse, como ser despedido do emprego. É frequente durante a vida, desde a infância. É nesse caso que realmente precisa procurar tratamento.

Uma pessoa que, de vez em quando, esquece alguma coisa, de vez em quando faz alguma coisa impulsiva, de vez em quando fica distraída, isso é normal, é típico. Todo mundo passa por eventos estressantes vez ou outra que levam a isso. Você não “ganha TDAH” só porque passou por uma situação estressante. Tendo sido diagnosticado ou não o TDAH já existia desde que era criança.

E é por isso que TDAH é também um transtorno muito mal diagnosticado. Ao mesmo tempo muita gente que não sofre do transtorno acha que tem, e muita gente que tem, acha que não tem. Um exemplo disso são crianças com QI mais alto. Ironicamente, pessoas mais inteligentes, podem sofrer mais com esse tipo de transtorno. Por exemplo, imagine uma criança com TDAH que é forçada a participar da chatice de uma sala de aula normal. Ela tem dificuldade de prestar atenção.

Aí o professor nota a pessoa desatenta e chama ela pra responder uma pergunta da aula. O aluno se assusta, mas ele já sabe, o TDAH deixou ele distraído, tava mais focado girando caneta nos dedos. Mas ele é altamente inteligente, rapidamente lê a lousa, olha onde o livro do amigo do lado, tenta achar a resposta via pura dedução. Por acaso acerta, o professor faz o “hum”, e volta a dar aula.

Via força bruta, ele bypassou o prejuízo da inatenção. É um jeito dela não ser diagnosticada com tendo TDAH. Pessoas neurodivergentes, não só TDAH, nós costumamos ter diversas técnicas pra meio que “mascarar”, pra passarmos despercebidos num mundo feito pra neurotípicos. É algo que fazemos inconscientemente, como um mecanismo de defesa.

Deixa eu voltar num ponto que falei antes: transtornos psicológicos, no mundo Ocidental, costumam ser percebidos como uma chave de liga e desliga: ou a pessoa tem, ou não tem. É tipo tem câncer ou tem diabetes. É tudo ou nada. E faz sentido, esse tipo de doença, por todo o século XX, sempre foram as prioridades, são problemas literalmente mortais, se não tratados.

Por causa disso, problemas psicológicos sempre foram uma categoria de menor prioridade e menos atenção. Muita pesquisa nova e importante tem acontecido nos últimos 20 anos, ainda é um campo em desenvolvimento. Não sabemos tudo, mas por esse lado, nem coisas como câncer sabemos tudo ainda. Não nos impede de tratar e ter sucesso nos tratamentos. Digo isso pra tomar cuidado porque muitos ainda usam uma cartilha antiquada, de décadas atrás pra falar desses transtornos.

O que sabemos hoje é que esse tipo de transtorno é um espectro, um intervalo, e não um valor discreto. É como no meu caso de autismo. Por muito tempo, na minha cabeça, autismo era como um Dustin Hoffman em Rain man, talvez o mais famoso de todos. O meu grau de autismo não é alto, é o que antigamente se chamava de Asperger, hoje é grau 1 de autismo, o Rainman provavelmente era grau 3. Mesmo esses “graus” são só guias, de novo, não é uma chave com 3 valores discretos. É como um termômetro, o que é quente ou frio? São espectros, uma gradação.

Uma pessoa com TDAH não é alguém 100% inatento, 100% impulsivo e 100% hiperativo. São graus que variam dinamicamente dependendo da situação e diversas condições fisiológicas. E falando em fisiologia, a gente costuma pensar nesses transtornos como algo que é exclusivo dentro da mente da pessoa. Por isso muitos pensam: “só lida com isso e resolve”. Mas o problema é físico tanto quanto é mental. E é aqui que quero quebrar a noção de que isso é tudo um problema inventado. É um problema físico e mensurável. Diversas pesquisas neurológicas já objetivamente mediram, por exemplo, usando ressonância magnética do cérebro.

Falando bem a grosso modo, nosso cérebro não é uma máquina simples e ainda não sabemos tudo dela. Mas já conhecemos o funcionamento de diversas regiões diferentes. Vamos entender algumas. Temos a insula que é uma região do cérebro localizada bem fundo no córtex cerebral, e tem diversas funções como processamento de emoções, habilidade de sentir e entender o estado interno do corpo, cognição social.

Temos a amygdala, que é diferente da amigdala na garganta, que em inglês é tonsil e eu sempre me confundo. No cérebro ela tem estrutura no formato de uma amêndoa, localizada fundo dentro do lobo temporal, e tem um papel importante no processamento de emoções, particularmente medo, ansiedade e agressão. Guarde essa informação, vai ser importante.

O nucleus accumbens é o sistema de recompensa do cérebro, localizado no prosencéfalo basal, responsável pelo processamento de prazer, recompensa e a tal da motivação. Mais pra cima, na região do lobo frontal temos o cortex prefrontal dorsolateral, que se envolve nas funções executivas, como memória de trabalho, a nossa RAM, flexibilidade cognitiva, tomada de decisões.

Finalmente, na frente temos o córtex frontal orbital, também no lobo frontal. Ele se envolve em tomada de decisões, regulação das emoções e comportamento social. Pra ilustrar, imagine que a região da insula e amygdala são responsáveis por te dar medo ou ansiedade.

Alguém estranho se aproxima de você, do nada, no meio da rua deserta, a noite. Adrenalina é produzida em segundos e você sente fisiologicamente: sua pulsação aumenta, sua respiração aumenta, sua visão periférica fecha, pupilas dilatam, você foca. É a reação de fight or flight, seu corpo sentiu uma ameaça, e te coloca em estado de fugir ou lutar.

Mais informação chega no seu cérebro à medida que você reconhece esse estranho, e na verdade era um conhecido seu, que você não tinha percebido. Possivelmente, seu córtex frontal orbital entra em ação e faz a computação cognitiva de mais alto nível, analisando se é mesmo uma situação que oferece risco ou não. E ao decidir que não, pode pedir pra regular a amygdala e desligar o alarme, vamos assim dizer. Não quer dizer que é exatamente assim que acontece, mas de novo, só pra ilustrar como esses componentes poderiam funcionar juntos.

Outra situação é que você quer entrar em forma, resolve fazer uma dieta. Seu centro de gratificação, o nucleus accumbens, junto com o cortex frontal, vão computar e avaliar o que todo mundo chama de “bom senso”. Se comer um doce agora, vou ficar gratificado agora, mas vou me arrepender amanhã. Daí ele põe na balança, e toma a decisão correta de, “ok, não preciso comer esse doce agora”. Pra neurotípicos, esse tipo de reação é normal, você sente uma pequena ansiedade, mas os sistemas de regulação entram em ação e você não tem nenhum tipo de sofrimento extra.

Não é o que acontece na cabeça de um neurodivergente com TDAH. Embora existam diversas pesquisas, ainda não é um consenso sobre exatamente os mecanismos, mas pra simplificar, entende-se que existe uma correlação entre pessoas com TDAH e alguma desregulação de receptores de dopamina em diversas regiões do cérebro. Justamente o neurotransmissor que é produzido quando temos alguma experiência boa, como comer um doce. A produção de dopamina é uma das formas de reinforçar comportamentos que tem benefício pra nossa sobrevivência. É como a gente se auto-treina.

Mas não só isso, dopamina está envolvido em outras coisas como controle de movimentos, em particular movimentos voluntários. Também é importante pra processar informação relacionado a recompensa e punição. E também se envolve na regulação de humor e emoções. Você consegue entender que se isso é desregulado, começa a fazer sentido pessoas que são “desastradas”, ou tem dificuldade de aprender, ou tem mudanças de humor estranhas.

E cuidado que existe outra desordem ligada a mudanças de humor, como desordem bipolar, que é diferente de TDAH e se trata diferente também, nem os medicamentos são os mesmos, aliás, medicamento de TDAH pode piorar bipolaridade. Por isso não devemos nos auto-avaliar e muito menos se auto-medicar.

Problemas graves de desregulação de dopamina tá relacionado a doenças consideradas mais sérias como Parkinson ou Esquizofrenia, vícios, mas em outro grau do espectro, também com TDAH. Outro aviso, cuidado, desregulação de dopamina é um fator, mas não é a causa de TDAH. Some a isso que algumas pesquisas escaneando o cérebro de diversos pacientes notou que de fato, regiões como insula e amygdala tem volume menor, e ao contrário do bom senso, isso pode causar hiperatividade nessas regiões.

Significa que os sinais de medo e ansiedade são amplificados muito além do normal, somado a um centro de recompensa desregulado, e pra piorar, tendo menos influência, menos regulação do córtex frontal orbital, que ajudaria a desligar esses alertas. Assim começa o tal transtorno do ponto de vista fisiológico. De novo, não é um problema inventado, é consequência dessa desregulação química.

Um fato que todos precisam entender é que emoções não existem à toa. Toda emoção são reações químicas e neurológicas que cumprem alguma função de sobrevivência. São ferramentas que foram sendo adaptadas e ajustadas ao longo de centenas de milhares de anos. Sentir medo ou ansiedade são características normais, mas no mundo moderno, esse sistema ainda não conseguiu se readaptar.

Um dos efeitos colaterais é esse déficit de regulação emocional. A pessoa com TDAH tem uma amplificação da sensação de medo e ansiedade em momentos ou situações que uma pessoa neurotípica não sentiria quase nada. Ela pode reagir de forma muito mais agressiva do que o momento exigiria. Isso deixa a pessoa mais irritável também e, claro, essas coisas somadas levam a problemas de relacionamento. Não só romântico, mas familiar, no trabalho.

Entendendo isso vamos imaginar um cenário. Uma criança que ninguém sabe que tem TDAH. Todo mundo tá conversando sobre filmes, sei lá, e essa criança não consegue acompanhar. Pro cérebro dela, começa a entediar rápido, ela se isola mentalmente. A cabeça está viajando em diversos pensamentos e por causa da impulsividade, do nada, ela interrompe a conversa e começa a falar de outro assunto nada a ver, tipo, de videogame. Mas não é que ela quis ser rude porque não tava gostando da conversa. Na cabeça dela acho que nem tava notando que estavam conversando, ela só quis começar a falar, por impulso.

Repita episódios assim ao longo dos anos na escola. Não só inatenção, impulsividade, mas hiperatividade, irritabilidade. Todo mundo acha essa pessoa esquisita. Não convida mais pra eventos sociais. Todo mundo achando ela esquisita, se torna o alvo favorito pra bullying. Essa criança não entende porque é o alvo ou porque acham ela esquisita. Em alguns casos, pode se safar se for do tipo que consegue ser tipo o palhaço da sala, a pessoa engraçada que consegue fazer os outros rirem.

Mais comum vai ser ela começar a notar o padrão. Os bullies só aparecem quando tem outras crianças por perto. Todo bully gosta de uma platéia. Então ela entende que ter pessoas por perto é uma situação de perigo. E isso é reinforçado. Portanto, toda vez que se vê perto de um grupo de crianças, dá meia volta, se esconde. Ela começa a ficar boa em evitar grupos porque o sistema de defesa deixa ela ansiosa perto de outras pessoas. Você se torna um adulto que se considera anti-social, que tem ansiedade perto de estranhos. Eis uma forma de como isso poderia surgir.

Antes de continuar, eu falei anti-social no sentido de se afastar das pessoas, mas não confundir com transtorno de personalidade anti-social que é um padrão de não se importar com as outras pessoas, não ter empatia ou remorso. Esse tipo de transtorno fala de pessoas que são mentirosas, manipuladoras, roubam, agridem, e coisas assim. É completamente diferente. E se pra alguns isso pareceu narcisismo, isso é outro transtorno diferente. E de novo, é por isso que ninguém deve sair se auto-diagnosticando.

Enfim, ansiedade não é só adrenalina alta por alguns minutos. Outra substância importante na reação de fight or flight é cortisol. Se numa situação de perigo no meio da floresta de antigamente, adrenalina é o boost de energia nos primeiros minutos pra você conseguir dar no pé, cortisol é a energia que vai durar 24 horas pra manter você correndo até conseguir se afastar do perigo. Imagina, tem um tigre no meio da floresta, você tem que conseguir fugir sem parar um segundo. Adrenalina e cortisol são justamente os tais hormônios de estresse.

Mas não pára nisso. Correndo no meio do mato cerrado, você vai se arranhar, se cortar, e isso pode infeccionar. Imagina que trágico conseguir correr do tigre só pra morrer depois por infecção? Ao mesmo tempo que os hormônios de estresse ativam, em paralelo seu sistema imunológico também entra em ação. Milhões de células brancas dormentes se ativam e se preparam pra combater infecções.

Mas estamos no século XXI. Hoje não tem uma situação de correr na floresta por horas e se machucar. Sua ansiedade social perto de outras pessoas, tá amplificado, mas felizmente você não vai se tornar comida de tigre. Mas e o cortisol e sistema imunológico que ativaram? É só se acalmar que desligam e tá tudo bem? Ah, se fosse fácil assim.

O cortisol extra vai garantir que você não vai conseguir dormir. Insônia, pode causar hiperatividade no meio da noite. Só que você precisa dormir, porque precisa acordar cedo pra faculdade ou pro trabalho. Agora fodeu. Sua ansiedade aumenta porque não consegue dormir. Quanto mais ansioso ficar por não conseguir dormir, mais acordado vai ficar, e é uma sensação amplificada, e com desregulagem, ou seja, difícil de desligar. E é por isso que pessoas hiper ansiosas tem dificuldades de dormir.

Mas a má notícia continua, o sistema imunológico foi ativado, tá pronto pra lidar com machudados e infecções, que não acontecem. Ele vai começar a atacar você mesmo, causando inflamação e danos em tecidos. Sabe problemas digestivos, gastrite, manchas ou machucados por sua pele? Pode ser isso. É seu sistema atacando você mesmo.

E finalmente, essas respostas também modificam seu metabolismo, podendo te tornar resistente a insulina, aumentando o armazenamento de glicose como células de gordura, fazendo você ganhar mais peso do que deveria. É seu corpo te preparando pro pior no meio da floresta, só que você não vive no meio da floresta. Muitos de vocês que sofrem desses transtornos podem ter problemas físicos que aparecem do nada, mas está tudo relacionado. Entenderam como uma coisa pode ligar na outra?

TDAH é uma disfunção do sistema executivo no cérebro. O sistema executivo é tipo nossa CPU, a unidade lógica, responsável por organização de tarefas, organização de tempo, tomada de decisões, tudo que neurotípicos consideram “normal”, só que ele está desregulado. Numa hora tá tudo bem, tá estudando, trabalhando, mas qualquer coisa pode distrair, ou causar parálise de análise, ou overanalysis, que muitos poderiam chamar de procrastinação ou falta de motivação.

Isso vocês já ouviram várias vezes. Todo mundo fala, “evite procrastinar”. Fácil falar né, se fosse fácil, todo mundo evitaria. Ou então “tente ser mais motivado”. Mas o que significa isso? Eu acabei de falar, medo, por exemplo, é uma reação instintiva, veio com milhares de anos de sobrevivência. Mas o que é motivação? É um neurotransmissor? É uma região do cérebro? Na realidade não, motivação é uma propriedade emergente de outros fatores.

Por exemplo, pra neurotípicos, pode ser uma simples recompensa. Se eu te der 1000 reais, você trabalha essa semana. Se eu te der 2000 reais você trabalha duas semanas. Pra muitas pessoas, esse motivador externo é suficiente pra engajar numa atividade e completar até o objetivo que tem em mente, digamos, 4000 reais, então ela se motiva a trabalhar 4 semanas.

Mas eu disse que o nucleus accumbens e a dopamina de uma pessoa com TDAH estão desregulados. O mesmo tipo de recompensa externa que funcionou pra um neurotípico não ativa as mesmas propriedades no cérebro de uma pessoa com TDAH. De repente ela resolve, sei lá, pintar os cantos das páginas do caderno, cada seção com uma cor. Algo assim, que pra um neurotípico, não faz o menor sentido.

Qual programa de organização devo usar? Notion? Obsidian? Um neurotípico pega a primeira folha de papel, lista o que precisa e é isso. Uma pessoa com TDAH primeiro precisa ver se dá pra customizar, deixar mais colorido, mais chamativo, e ela pode gastar horas nisso, antes de conseguir começar a escrever o primeiro item da lista. E quando começar, talvez lembre que tinha outro programa que queria testar, e vai instalar e customizar o outro. 3 programas depois, ainda não escreveu a primeira linha da lista. Isso acontece, e não é por sacanagem, nem procrastinação, é porque o sistema de recompensas dessa pessoa funciona diferente.

Deixa eu voltar rapidamente à questão dos pais, incrédulos de que o filho tenha déficit de atenção, porque eles sabem que o menino consegue ficar em hiperfoco, 12 horas por dia, na frente do fortnite. Só pode ser procrastinação. Lógico, como disse antes, pode ser mesmo, mas considere a pessoa com TDAH. Games foram feitos pra esse tipo de pessoa, porque foram desenhados com o objetivo de demandar toda a atenção. Toda hora tem alguma coisa nova, não entedia, tudo chama atenção: pontuação, itens, armas novas, fases novas. São horas e horas de distração que seu cérebro fica viciado mesmo.

Mesmo jogos que se chamam de “open world”, com um sandbox pra você fazer “o que quiser”, na verdade não são “open” de verdade, como a vida real. Eles tem objetivos principais e sidequests, organizados em listas, com objetivos bem definidos e recompensas no final de cada item. Foi sem querer, mas esses tipos de jogos foram feitos sob medida pra cabeça de alguém com TDAH.

Eu não tenho dados pra suportar isso, mas tenho uma hipótese sobre cursos online. Pessoas com TDAH possivelmente consumam mais pela mesma razão que se viciam em videogames: são gamificados. Tem listas de items bem definidos, tarefas e objetivos bem definidos, passo a passo bem definido, recompensas constantes com sensação de avanço. É como limpar a lista de sidequests de um jogo open world. Você fica viciado. Programas de organização, como um Notion, que permite infinitas customizações, mesma coisa. Eles chamam atenção, e viciam, pelos motivos errados.

Motivação não tem uma resposta única. Ela vai ser diferente pra cada pessoa. Você pode tentar entender os componentes fisiológicos, os neurotransmissores, as técnicas, mas pra variar, não tem receita mágica. Pergunte pra qualquer pessoa que você considere motivada. “Por que trabalha com tanto afinco?” E vai notar que nenhuma delas consegue dar uma resposta exata, vai fazer aquela cara de “ahh, sei lá, eu só faço”, se for honesto. Ou vai ter uma historinha empacotada, o que ela acha que você quer ouvir: “ah, eu faço isso pra construir um mundo melhor”.

Pra muitas pessoas, neurotípicas, costuma ter um componente lógico ou um desejo. Claro que eu quero trabalhar muito pra ficar rico pra me aposentar bem. Claro que eu quero estudar muito pra conseguir o melhor emprego na melhor empresa. Claro que eu quero ficar marombado, pra fazer mais sucesso na balada. Ou qualquer coisa assim. Mas de novo, pra neurodivergentes, o sistema lógico tem menos influência, e o sistema de recompensa está desregulado, então esse “claro”, não é tão claro assim.

O problema é que a pessoa já tem os problemas de inatenção, irritabilidade e impulsividade. Ela afasta ou pelo menos sente, que afasta as pessoas. Não consegue ir bem no trabalho. Tem dificuldades de criar relacionamentos duradouros, e ao mesmo tempo sente que não tem motivação, leu que isso se chama procrastinação. Seus resultados são ruins e isso causa vergonha, porque ela olha pros pais e amigos e vê olhos de decepção. Seu sistema de medo e ansiedade são desregulados, em breve ela chega a uma conclusão: eu não sou suficiente. Eu nunca vou ser suficiente. Eu sou um fracasso, uma decepção. É assim que pode surgir sensitividade a rejeição e até uma disforia, que pode levar à depressão, como ilustrei no começo.

Em situações de ansiedade, como ansiedade social, tipo ir numa festa ou evento, todo mundo tem inseguranças, será que tenho roupa pra ir? Será que vou falar alguma bobagem e as pessoas vão rir de mim? Será que vou conseguir falar com alguém? Existem 3 formas que as pessoas lidam com isso. A primeira, e mais óbvia, é que se esse medo for grande demais ela pode só Evitar, avoidance, e desistir de ir. Ou então se forçar a ir, mas quando chega a mente desliga, dá zone out, ela tá lá, mas não tá lá. É um cognitive mental check out.

Ou pode Suprimir, que é diferente do check out, você vai, mas vai brigando com você mesmo, tipo “eu aguento, eu aguento”, o sofrimento em silêncio, com a esperança de “espero que ninguém perceba”, o “fake it until you make it”, vou falsificar que tô gostando até uma hora conseguir gostar.

E finalmente, o ideal, que é enfrentar o medo, ir, processar, e aos poucos se adaptar, vendo que não era tão ruim quanto o medo inicialmente dizia que ia ser. Processar o medo como sendo irracional e compreender que não era o fim do mundo. Ninguém riu de você. Ninguém judiou de você, você tá bem. Pessoas neurotípicas fazem um pouco dessas três formas e tendem pra essa terceira opção, que é onde se amadurece. Todo mundo tem medo e ansiedade, mas aos poucos aprendemos a processar.

Mas pessoas com TDAH, exageradamente tomam o primeiro caminho: avoidance. Evitam a situação de ansiedade completamente, mas ao fazer isso ela está desistindo de coisas que são boas pra ela. Não só uma festinha. Deixa de explicar pro professor que passou mau e se podia fazer outra prova. Deixa de explicar pro namorado ou namorada que não tá bem. Deixa de pedir aumento no trabalho. E tudo isso retro-alimenta a sensação de fracasso, de insuficiência, e de novo, vira mais combustível pra sensitividade de rejeição e pra eventual depressão.

Motivação parece ser uma coisa que é só você ter um desejo muito forte, tipo quero ser rico ou quero muito ser famoso. E se a pessoa não tem motivação é porque ela não deseja forte o suficiente. Mas desejo e motivação são duas palavras diferentes por um motivo: elas não são iguais. Uma pessoa com ansiedade e TDAH como descrevi até agora, sem tratamento, tem chances de crescer sozinha, em total solidão ou pelo menos se sentindo solitária. Não tem nada que essa pessoa deseje mais do que ter uma companhia que não a faça se sentir insuficiente. Não tem nada que ela queira mais. Se fosse simples assim, ela já teria conseguido. Solidão não costuma ser uma opção, é uma consequência. E vocês já devem ter pelo menos ouvido falar o que solidão extrema pode causar.

Pra piorar, pessoas com TDAH parece que costumam desvalorizar seus sucessos e aumentar seus fracassos. Aumentar fracassos, achar que porque fez uma prova ruim, vai repetir o semestre, e por isso vai fracassar na faculdade, e por isso nunca vai conseguir um bom emprego, e por isso nunca vai ter uma boa carreira e por isso sua vida acabou, agora, já. É sua insula e sua amygdala hiperativa aumentando seus medos e ansiedades muito além da imaginação. Pra quem é neurotípico, pode parecer uma linha de pensamento absurda, mas pra um neurodivergente é absolutamente real.

Mas desvalorizar seus sucessos é mais sutil. É um mecanismo de defesa. O que eu falei do Evitar, avoidance. A pessoa desvaloriza o sucesso de agora porque se fracassar depois, na cabeça dela, vai ser menos dolorido. Se eu acertei hoje, mas fracassei amanhã, então eu sou um fake, uma fraude? É assim que pode nascer Síndrome do Impostor. Ou seja, o sistema dessa pessoa hiper-aumenta as consequências de um fracasso e minimiza os sucessos. Como você acha que ela vive?

Não estou querendo ser fatalista, e nem tratar esse assunto com desrespeito, mas é só pra explicar uma das formas de porque algumas pessoas chegam no pensamento de acabar com a própria vida. Pra neurotípicos não faz nenhum sentido. Mas se seu sistema de defesa está hiperativo, seu sistema de recompensa está desregulado, você não consegue tirar prazer das coisas porque seu sistema de recompensa tá desregulado. Sua irritabilidade e inatenção te afasta das pessoas, e seus resultados são cada vez piores, ao ponto onde, na sua cabeça, se sente totalmente incapaz e sozinho, e com a certeza que não existe solução. Não é difícil entender porque esse pensamento aparece.

E ao contrário do que filmes e ficção costumam mostrar, onde uma pessoa que decide desistir da vida faz toda uma preparação, escreve e envia cartas, inventa até jogos e tudo mais, faz parecer que nós conseguiríamos ver os tais “sinais” com antecedência e conseguir interceder. Mas não é bem verdade isso. Segundo pesquisas com sobreviventes, na maior parte dos casos, o que se sabe é que do momento que a pessoa tomou a decisão, o ato em si, costuma ser questão de poucos minutos, não dias. Lembrem-se de outra característica de TDAH: impulsividade. Impulsividade é justamente tomar uma ação por impulso, sem consideração pelas consequências.

Impulsividade é que leva uma pessoa com TDAH a tomar decisões impensadas, pedir demissão, desistir da escola, dirigir como doido num momento de frustração. E falando tudo isso, se você se relacionou com as características de TDAH talvez esteja se sentindo aflito, ansioso, desesperançoso. Mas calma. Até aqui foi pra explicar, pra quem não sabia, como a cabeça de alguém com TDAH poderia funcionar, pra entender que não é uma escolha, é uma consequência. Agora temos que entender, por que é assim?

Não existe uma teoria exata que todos concordam, e até 1995 o consenso era que TDAH era como uma doença mesmo, um defeito. Mas na antropologia surgiu uma teoria interessante que pode ajudar a dar perspectiva. De novo, é uma teoria. Vamos lá. Muitos de nós, temos dificuldade de entender o conceito de tempo. A Revolução Industrial, que moldou o mundo moderno como conhecemos hoje, começou na Inglaterra no final do século 18. De lá pra cá se passou só uns 250, talvez 260 anos. Dois séculos e meio. Parece um puta tempo né?

Mas pensa, estamos no século XXI, implica que se passou mais de 2000 anos desde que começamos a contar esse calendário. Isso é 8 vezes mais tempo do que os dois séculos desde a revolução industrial, é tempo pra caramba. Mas no frigir dos ovos, ainda não é nada. Nós somos parte da espécie Homo Sapiens, a sequência dos Neandertais, e essa espécie surgiu mais ou menos 300 mil anos atrás. Parece muito tempo, mas não é tanto assim.

Os primeiros hominídios, o galho que não tem a ver com os macacos primatas, começou com os australopitecus, em alguma coisa como 4.2 milhões de anos atrás. Se tivéssemos um relógio de 12 horas pra representar os 4.2 milhões de anos, começassemos a evolução dos seres humanos a partir do meio dia, os 250 anos da história industrial moderna seria só os últimos dois segundos e meio antes da meia noite.

Entendem essa proporção? As duas grandes guerras mundiais, o nascimento e evolução do motor a combustão do primeiro automóvel até chegar nos Teslas e foguetes da SpaceX, o nascimento do transistor e sua evolução até a internet e inteligência artificial, tudo isso aconteceu nos dois últimos segundos desse relógio. Já nossa evolução biológica enquanto seres vivos, levou as quase 12 horas anteriores.

A revolução da agricultura, onde deixamos de ser só catadores de subsistência, começou uns 10 mil anos atrás. Por toda nossa história, nossos antepassados começaram a formar tribos, e papéis foram sendo definidos. E é aí que entra a teoria de “caçadores catadores”. A história dos caçadores ou catadores de subsistência entrando no mundo dos fazendeiros.

Pra resumir, imagine que na pré-história alguns dos papéis mais importantes eram do caçador ou catador. O fazendeiro é alguém até certo ponto satisfeito em viver uma vida regrada, acordar todo dia 5 da manhã, fazer o trabalho repetitivo do arado, colheita até a tarde, ir dormir e começar de novo a mesma coisa no dia seguinte. O caçador, é o oposto, não tem uma rotina bem definida, às vezes precisa ir longe no meio de uma floresta desconhecida, prestar atenção em tudo, caçar e evitar ser caçado. Tudo pode ser uma ameaça, um urso ou uma escorpião.

Podemos imaginar que um caçador precisa conseguir escanear o ambiente rapidamente, sem ficar focado numa coisa só, daí agir rapidamente, ser hiper-vigilante. Ser mais agressivo que o normal, por impulsividade, talvez seja a diferença entre a vida e a morte nas savanas da África da pré-história. Lembrem-se, era uma época de recursos escassos. Todo mundo tá acostumado com agricultura moderna, mas na pré-história não existia essa tecnologia. O normal da história humana por milhões de anos sempre foi pouca comida, muita doença, muitos perigos e baixa expectativa de vida.

É por isso que levou até as 11 horas, 57 minutos e 30 segundos do nosso relógio evolucionário pra conseguirmos chegar perto do primeiro 1 bilhão de habitantes na Terra. E foi só por causa das tecnologias modernas, que começaram depois da revolução industrial, que fomos de uma só vez de 1 bilhão pra 8 bilhões de pessoas. Em dois segundos. É claro que isso ia ter consequências.

Mais uma vez de forma simplista, a revolução industrial foi uma enorme revolução de eficiência. Levou o homem do campo pras cidades, da agricultura pra indústria. E precisamos treinar essas pessoas. Daí nasce o sistema educacional como conhecemos hoje: salas de aula com vários alunos presos em cadeiras o dia inteiro. 30 ou 40 crianças ouvindo um professor chato o dia inteiro. E depois uma carreira de trabalho de 9 às 5 fazendo trabalho repetitivo, sentados em cadeiras o dia inteiro. Seja numa fábrica ou seja num escritório do mundo moderno. É um mundo ótimo pra quem gosta de rotina.

Entenderam: a sociedade moderna foi feita à imagem dos fazendeiros. Trouxemos os caçadores juntos e fizemos eles ficarem sentados o dia inteiro, por anos e anos. Tentamos encaixar uma peça redonda num buraco quadrado. O mundo moderno foi feito pra pessoas que conseguem aguentar a rotina de ficar fazendo poucas atividades, sentados o dia inteiro, em horário fixo. O exato oposto do que é um caçador.

Pesquisas sugerem que TDAH é de fato passado geneticamente. Tem papers com pesquisas que acompanharam a vida de mais de 50 mil gêmeos ao longo de décadas pra entender. Existe um fator genético e existia uma utilidade evolucionária. Não é um problema aleatório que aparece do nada na cabeça das pessoas, é uma pré-disposição. Mas como falei antes, não é uma chave de liga e desliga. O entendimento é que esse fator é uma vulnerabilidade em neurodivergentes que pode ou não ser ativada, em diferentes graus, dependendo do ambiente onde cada um cresceu.

Em pesquisas com alunos em sala de aula, também já foi identificado que 30 alunos com 1 professor tem o dobro de diagnósticos de TDAH do que numa sala com os mesmos 30 alunos mas 2 professores disponíveis. Ter um professor a mais que consiga dar mais atenção e redirecionar a atenção do aluno da forma correta, ajuda a criança a manifestar menos ou até não sofrer os problemas de TDAH. O ambiente é um enorme fator pra severidade da condição. Só ter a pré-disposição genética não garante que você vai necessariamente sofrer com isso.

Também se acredita que adultos diagnosticados tardiamente com TDAH na verdade já tinham isso desde a infância, mas infelizmente, nunca foram tratados quando deveriam. Seja por ignorância de pais e escolas, seja por preconceito contra medicamentos ou tratamentos. E na vida adulta a condição pode levar a outros problemas como desordem de ansiedade e, nos piores casos, depressão.

E mesmo quando há diagnóstico, ainda existe essa idéia de chave de liga e desliga. Ah, é símples, dá Aderol ou Ritalina e tá resolvido. Mas vou repetir porque é importante: a condição não é um único componente de liga e desliga igual pra todo mundo. É uma desregulação de diversos componentes e diversos neurotransmissores. Estimulantes não agem só numa região isolada, ela tem efeitos colaterais, que variam de pessoa pra pessoa. Cada pessoa tem uma combinação única de fatores que dão espectros de severidade diferentes pra cada sintoma de TDAH.

Algumas pessoas tem déficit de atenção mas não necessariamente hiperatividade. Outras podem ter dislexia somado. Em graus diferentes. É uma matriz multidimensional de combinações, e não uma única variável binária. Por isso toda hora estou falando que nada substitui o tratamento: porque só um profissional licenciado vai conseguir identificar as variáveis e como tratar no seu caso específico.

A medicação em si é super estigmatizada, tem aquela imagem que a pessoa vai virar um junkie viciado ou um zumbi. E sim, se um neurotípico se automedicar com uma ritalina porque assistiu video de tiktok falando que isso dá boost de produtividade, vai ter problemas. Uma pessoa neurodivergente que precisa de ritalina é parecido com uma pessoa com diabetes que precisa de insulina. Você pode chamar uma pessoa diabética de junkie em insulina?

Tecnicamente até sim, mas a diferença pra você, neurotípico, é que seu corpo fabrica insulina, mas algumas pessoas precisam de insulina externa, porque a desordem é justamente não conseguir fabricar sozinho. É pra casos assim que medicamentos são necessários. Não só isso, nosso corpo pode se tornar resistente a certos medicamentos. Precisa modificar dosagem, trocar de medicamento e tratamento. E o único que vai saber disso é um psiquiatra licenciado.

Psiquiatras não são médicos de loucos. São médicos, que aprenderam da mesma medicina que todos os outros clínicos gerais e tem especialização na neurologia e efeitos dos químicos que eu simplifiquei hoje. Um video de YouTube nunca vai substituir anos de experiência nessa área. De novo, se você se relacionou com algumas das condições que tentei explicar, procure um psiquiatra.

E não só um psiquiatra. Muito do que uma pessoa de TDAH sofre pode ser contornado com técnicas holísticas. Primeiro tem a medicação, especialmente em casos graves e urgentes. Mas se for dignosticado cedo, o ideal é CBT que é terapia cognitiva comportamental, que é como uma re-educação pra aprender como seu sistema funciona e técnicas de como compensar. Todo mundo recebeu uma educação de neurotípicos, mas claro que não funciona pra todo mundo. Existe uma educação pra neurodivergentes, que é a terapia.

Por exemplo, pra casos mais leves do espectro, coisas como sistemas de alarmes, notificações de calendário, listas de coisas a fazer bem escritas, com itens que tem ações específicas e não abstratas tipo “estudar mais” e sim “estudar o capitulo 5 do livro X”, sabe? Sidequests de jogos com objetivos bem definidos? São exemplos de mecanismos externos, que bem aplicados, compensam nossa inatenção, por exemplo.

Se sair procurando, vai achar uma tonelada de videos de lifehacks que pessoas com TDAH podem tentar, mas cada video vai mostrar o que funcionou praquele criador de conteúdo, no espectro dele. Nunca vai ser uma regra geral. E sair na tentativa e erro, com toneladas de video, sem o entendimento correto disso, em vez de ajudar, pode piorar sua ansiedade, amplificar o sentimento de fracasso. Por isso insisto, procure terapia de um profissional qualificado.

Agora, não são só más notícias pro pessoal de TDAH. Pra mim a teoria antropológica faz muito sentido: estamos forçando caçadores a sentar na cadeira de uma escola ou escritório, num horário fixo, e ficando putos porque eles não conseguem ser produtivos. Mas é lógico, é uma estrutura feita por fazendeiros. Por acaso, esse perfil é o que foi considerado “neurotípico”. Na pré-história, talvez o “típico” tenha sido ter TDAH. Eu mesmo tenho dificuldades nessa estrutura, sempre tive.

Porém, as qualidades de caçadores começaram a voltar a fazer sentido no mundo moderno. Empreendedorismo é uma atividade não estruturada onde pessoas com TDAH parecem ter algumas vantagens. Não é de hoje que tem videos e mais videos associando um Elon Musk a TDAH. A maioria das pessoas neurotípicas tem como objetivo na cabeça uma rotina de 9 às 5, sentado num escritório, com trabalho estável, sem dor de cabeça. Já um Elon, o que ele faz? Carro elétrico? Hm, não, entendiou. Lançar foguete então? Hm, não, entendiou também, zoar no Twitter. É isso. Pra muitos, Elon é o ápice do TDAH.

Várias áreas criativas costumam abrigar a impulsividade, a necessidade de coisas novas, a atenção em detalhes de TDAH. Seja literatura, música, artes, cinema, moda e muito mais. Veja vendas ou marketing, ou criação de conteúdo, ou streaming, que são áreas que precisam da hiperatividade, alta energia e habilidades sociais de pessoas com TDAH.

Muitos não pensariam nisso de primeira, mas uma pessoa de TDAH não procrastina, ela sofre tudo que expliquei até agora. Mas justamente uma das muitas técnicas que usam em sua organização é tentar quebrar as coisas em tarefas menores e mais urgentes. Em vez de ter um grande trabalho pra entregar no final do semestre, se os professores forem atentos, é melhor dar pequenos trabalhos com mais frequência.

O senso de urgência é um grande motivador pra pessoas com TDAH e pelo mesmo motivo, parece que elas conseguem se dar bem em trabalhos de emergência, emergência de hospital, por exemplo. Pessoas com TDAH parecem se dar bem em ambientes que parecem caóticos, com ritmo acelerado, de alta pressão e urgência. Se o ambiente exige tomadas de decisão muito rápidas, como por impulso, com hiperatividade, parece combinar.

E finalmente, tecnologia. Programação, design gráfico, edição de video, tarefas que exigem atenção a detalhes, a tal habilidade pra hiperfoco. Já falei que não tem como controlar nem garantir o hiperfoco, mas ela costuma vir em atividades que excitam mais o centro de recompensa do cérebro dessas pessoas. Se justamente forem atividades de tecnologia, isso pode ajudar muito. Não é de hoje que vejo muita gente que me acompanha e tem algum espectro de TDAH. A gente brinca que precisa ser meio doido pra ser programador, e acho que essa observação não tá muito errada.

Existem milhões de pequenas dicas e lifehacks que eu poderia explorar aqui, mas não é esse o ponto. Primeiro porque já existem centenas de videos desse tipo. Mais importante, porque o foco não é tentar consertar seu problema neste video. Isso eu não consigo fazer. Nem eu, nem nenhum youtuber. Só um especialista, durante várias sessões, ao longo de vários meses, num tratamento feito sob medida pro seu espectro em particular.

O objetivo deste video é awareness. Muitos neurotípicos não entendem que estão cercados de neurodivergentes, e só categorizam a pessoa como “esquisita” e ficam longe ou zoam gratuitamente, o que não ajuda. Eu sou neurodivergente e não sabia disso e certamente tenho dificuldades de identificar outros neurodivergentes porque tenho espectro autista, minha dificuldade é justamente em comunicação.

Aí vocês devem estar coçando a cabeça. “Como assim comunicação? Você não é a porra de um YouTuber??” Entenda, e isso é o que todo mundo que me critica não entende: eu leio um script e meus videos são editados. Já viram os bloopers no final do video? Eu não falo sem errar e sem parar. Eu deixo os bloopers justamente pra todos verem que eu erro como qualquer outro.

Já me falaram que tenho tom arrogante de sabe tudo. Eu tenho mesmo muita dificuldade de entender isso. Não sei se posso atribuir isso totalmente ao autismo, mas tenho muita dificuldade quando estou dando uma resposta que na minha cabeça é clara e objetiva e as pessoas me falam que eu fui mau educado ou algo assim.

Juro, não é brincadeira, na minha cabeça eu estou me esforçando pra dar a melhor resposta que consigo, da forma mais curta, justamente porque parece ruim fazer as pessoas perderem tempo me ouvindo falar coisas desnecessárias. Então edito os scripts pra ser o mais eficiente possível. É como eu prefiro. Mas depois me dizem que soou arrogante. Eu até acho que entendo, mas não compreendo, literalmente não computa na minha cabeça.

Eu entendia que tinha problemas de comunicação, mesmo antes de ser diagnosticado. Entenda, eu não sabia nada disso até pouco tempo atrás. Se procurar online por características do nível 1 de espectro autista vai encontrar coisas como: dificuldade com interações sociais. Em particular a dificuldade de entender sinais, expressões. A gente não nota muito a pessoa com quem tá falando. Eu sempre sou o último a entender piadas ou sarcasmo, normalmente eu vejo as outras pessoas rindo, e eu rio junto depois, sem entender bem porque.

Muitos de nós literalmente somos incapazes de falar olhando nos olhos da outra pessoa. Eu realmente não gosto, mas aprendi a olhar um pouco pro lado dos olhos, pra parecer que estou prestando atenção. Eu fui aprendendo a me comportar como as pessoas parece que esperam que eu me comporte. Mas isso é muito exaustivo. Por isso, no geral, prefiro atividades que posso fazer sozinho. Quanto menos precisar falar com outras pessoas, pra mim é melhor. Gosto mais de ambientes onde no máximo preciso falar online, é sempre mais confortável.

Segundo ponto é comportamento repetitivo. Preferência por rotina e rituais. É exatamente como eu gosto das coisas. Não tira nada do lugar que eu coloquei. Não me chama pra fazer nada em cima da hora. Tudo que altera minha rotina ou meu planejamento, me incomoda profundamente, eu tenho que me segurar muito pra não explodir mesmo em coisas triviais que eu não planejei antes.

Além disso eu tenho interesses muito estreitos. Eu me distraio, como pessoas com TDAH. Se você me acompanha no instagram, deve ter notado que meus interesses são bem limitados a poucos tópicos que vou super a fundo. É como eu funciono. Dizem que pessoas com autismo tem força cognitiva, tipo memória acima da média ou atenção a detalhes, ou até memória fotográfica como um Sheldon da vida. Eu nunca medi, mas por experiência, acho que pode ser o caso. Mas, eu esqueço muito fácil coisas do dia a dia, eu tinha dificuldade até de lembrar data de aniversário dos meus pais. Mas me pergunte fatos sobre a história da computação e eu te digo nomes e datas. Não sei bem como isso funciona ainda.

É como escrever um script como esse, eu fiz a pesquisa, tenho minhas experiências, tenho o assunto inteiro tudo de uma só vez na minha cabeça enquanto estou escrevendo. Quando eu chamo de “dump”, não é um exagero, é um dump mesmo, eu derrubo da memória pro teclado de uma só vez. E tenho atenção a detalhes. De bater o olho, vejo um errinho ortográfico e isso me irrita e eu preciso consertar. É assim que escrevo 50 páginas em um dia, em hiperfoco.

Daí tem alguns pontos que eu não me identifico tanto como sensitividade sensorial, tipo hiper sensitividade a cheiros, luzes, toques ou coisas assim. Sons eu tenho, se estou tentando me concentrar, barulhos me irritam profundamente. Quem assiste meus bloopers já viu isso. Também falam de ansiedade, mas comparado a uma pessoa com TDAH, minha ansiedade não chega nem aos pés. Até hoje, situações sociais me deixam ansioso, mas eu aprendi a suprimir. Eu subo num palco e dou uma palestra. Não gosto, por isso evito quando posso. Tem outras nuances como personas e máscaras que são mecanismos que eu aprendi a usar sozinho.

Isso pode soar estranho, porque todo mundo conhece a persona Akita do canal Akitando, youtuber, palestrante, ex-organizador de eventos grandes. E como assim eu tenho problemas de comportamento social e comunicação? Exatamente porque essa persona impede que vocês vejam esses problemas. Por anos, via tentativa e erro, aprendi meio a compensar, mas mesmo assim fica meio Sheldon, às vezes. Pra muitos assistindo, meu transtorno pode me fazer parecer uma pessoa arrogante. Como sou um youtuber, parece normal.

Claro, acho que a maioria consegue entender que não estou tentando agredir ninguém de propósito nem nada disso. E nem eu consigo dizer quanto que a forma como vocês de fora me enxergam tem a ver ou não com os efeitos do meu autismo, ou só por eu ser youtuber mesmo. Como eu nunca tratei e só descobri agora, ao longo dos anos fui criando mecanismos pra me defender e navegar o mundo. Eu sempre achei que era estranho, mas nunca parei muito pra refletir sobre isso, até muito pouco tempo atrás.

Pra piorar, desde quando eu era criança, sempre entendi que era tratado de forma diferente. Bullying por exemplo. Mas na época assumia que era por ser asiático. “Ah sim, japoneses naturalmente são zoados”. Normalmente eram só uns 2 ou 3 na sala de aula como eu, no máximo. Desde criança eu me achava diferente, mas achava que tinha a ver mais com isso, e nunca passou pela minha cabeça, mesmo depois de adulto, que poderia ser algo como espectro autista.

Mas é aquela sensação de “ahhhhh, agora tudo faz sentido”. Inclusive já teve pessoas que trabalhavam comigo que me zoavam me chamando de autista, porque quando eu tava no meu hiperfoco, literalmente desligava do mundo, e quando conversava era meio mão única, tinha o lance que eu não entendia sarcasmo ou piadas, então devia ser meio esquisito falar comigo. Eu tendo a falar e interromper mais do que ouvir quando é um assunto que me interessa.

Também me entedio muito fácil da conversa, já quero ir direto pra solução, sem tanta cerimônia. Eu até tenho empatia, mas a história dos outros não costuma conseguir segurar meu interesse muito tempo, eu me distraio e começo a pensar outras coisas, tenho aquele olhar que parece que tô olhando pra você, mas na verdade estou olhando 1km atrás de você. E uma hora depois, se não foi assunto do meu interesse, já esqueci do que falamos.

De qualquer forma, eu não tive muito interesse em estudar o autismo ainda, me foquei no TDAH por motivos pessoais e achei que valia a pena compartilhar. Eu vi em primeira mão os efeitos que depressão pode causar numa pessoa sem suporte e sem tratamento. Mais importante: numa pessoa que acredita que essa condição é fixa, imutável e a única certeza é sofrimento eterno. Eu entendi que um grande passo pra melhorar é justamente “entender” que o transtorno existe e os mecanismos por trás disso. Torna o problema muito mais palpável, menos abstrato, que começa a dar a noção de que é gerenciável.

Num mar de falsos gurus vendendo soluções mágica no Tiktok, isso só aumenta a ansiedade e frustração e piora a depressão. Cada oferta de solução mágica que não funciona, amplifica a sensação de que a culpa é da pessoa e que nada nunca funciona só pra ela. A culpa não é sua.

Falando em tiktokers, uma dúvida que paira no ar, e que é controversa, é que muitos assistindo devem ter notado que nos anos recentes aumentou bastante o aparecimento de casos de TDAH. Pode ser, ou porque o acesso a diagnósticos melhorou, ou porque de fato aumentou o número de pessoas sofrendo de algum espectro de TDAH. E acho que é um pouco das duas coisas.

Boomers e pessoas mais velhas que eu tem dificuldade de aceitar que transtornos psicológicos existem. Pra muitos parece só drama, mimimi, e gente tentando chamar atenção. Não ajuda que online, tem mesmo muito disso. Por isso os que sofrem de verdade não querem parecer que são esse tipo de pessoa, e sentem vergonha. A maioria das pessoas aprendeu a navegar como deu, evitando situações e, por consequência, limitando sua vida, ou suprimindo, e tendo todo tipo de efeitos colaterais, estresse, depressão, aumento de auto-medicação, álcool e drogas e por aí vai.

Desordens neurológicas são reais, se manifestam fisiologicamente, não é só fruto da imaginação. Também não se pode achar que todo mundo é uma vítima. Pessoas que de verdade enfrentam essas condições são as primeiras que não gostam de se vitimizar e que tenham dó delas. Elas não se expõe. Só querem conseguir fazer as coisas. O problema são os aproveitadores, que se usam dos transtornos dos outros pra aparecer. Não estão ajudando nada.

E tratamento não é camisa de força, hospício, lobotomia nem nada disso. O problema é o estigma. A vergonha de alguém descobrir que você decidiu se tratar, a ansiedade de ficar pensando que alguém vai achar que você é louco e coisas assim. Felizmente, estamos em 2023 e não em 1990. Mas mesmo na minha área, de tecnologia, a maioria de nós ainda não sabe como lidar com isso. Muitos de nós já nos adaptamos de alguma forma, provavelmente não da melhor, mas sabemos das dificuldades, então pelo menos podemos tentar aumentar o interesse em aprender mais sobre o assunto.

Deixando os problemas de lado, a neurologia, psicologia evolucionária e tudo mais são assuntos fascinantes por si só. Você é criador de conteúdo, ou de marketing, ou de UX, ou design, ou economia, qualquer profissão que tenta influenciar o comportamento das pessoas. Mas as pessoas não são nem totalmente lógicas e nem totalmente idiotas pra ficar caindo em truques baratos. Entender essas diferenças ajuda a produzir conteúdos melhor direcionados e melhora os negócios. É sempre ganha-ganha.

Um exemplo pequeno, home office, pra muitas pessoas com TDAH pode ter sido bom, porque como falei, os momentos de hiperfoco não são controláveis. Não dá pra forçar acontecer no horário comercial. E se vier às 9 da noite? Você vai se vestir, pegar o metrô, ir até o escritório? Aí chega lá e a urgência passou. Home office pelo menos dá a oportunidade da pessoa conseguir ser mais produtiva. Tem prós e contras, como sempre, mas novas opções começaram a aparecer em alguns lugares.

Outro exemplo, ouvi falar que algumas poucas escolas começaram a entender o diagnóstico de TDAH e oferecem opção desse aluno ter mais tempo pra fazer uma prova, ou fazer numa sala separada. À primeira vista pode parecer injusto. Mas você não tá entendendo. Ela não controla a ansiedade, ainda. Some a isso outras desordens, como dislexia. A prova em si já deixa ela mais ansiosa que todo mundo e com dislexia significa que vai ver todo o enunciado embaralhado. Ela é totalmente capaz de fazer a conta, mas pra isso precisa conseguir enxergar os números e letras nas posições corretas primeiro. A escola é justamente o lugar onde ela deveria ter a oportunidade de aprender a calibrar essas coisas.

Ainda não tem pesquisas o suficiente, tem muito ajuste em muitos processos que precisam acontecer, e nada disso vai acontecer da noite pro dia. Enquanto isso, nós neurodivergentes, precisamos aprender a navegar no mundo dos neurotípicos, aprendendo os mecanismos pra aliviar a maior quantidade de obstáculos quanto possível. É muito difícil fazer isso sozinho, e é por isso que a mensagem desse video é: se for o caso, aceite que a desordem existe, aceite que tem trazido prejuízos demais, e aceite que não é sua culpa. Mais importante: aceite que existem formas de melhorar drasticamente sua qualidade de vida.

Não vai ser com óleo de cobra, não vai ser ervas nem óleos essenciais, nem lifehacks engraçadinhos, vai ser com os medicamente corretos, com a terapia correta, com um bom especialista. É como quem quebrou feio uma perna e precisa ir num fisioterapeuta reaprender a andar. Não é uma perda de tempo, é uma economia de tempo, no futuro.

Eu não sou o melhor exemplo, mas pelo menos vejam, um neurodivergente pode ter uma carreira produtiva e sucesso. Isso não é um acidente. É aprender o seu espectro e criar estratégias que funcionam pra você. Durante o video todo eu disse que o certo, se você se relacionou com os sintomas que descrevi no video, é ir procurar um especialista. Mas digamos que você queira mais informações. Aqui mesmo no YouTube andei vendo alguns canais que podem ajudar a dar mais informações, caso tenha preguiça de ir ler os papers.

O primeiro é o canal da Dra. Tracey Marks, que é psiquiatra, e faz videos muito bem explicativos e informativos, que podem ajudar a dar nome pra coisas. Vale a pena dar uma olhada. Alguns exemplos que mencionei hoje, vi em videos dela. Outro canal que eu gostei, com ressalvas, é do Dr. K, do canal HealthyGamer. Ele sempre dá vários disclaimers, e suas explicações são muito boas, bem embasadas em pesquisa e exemplos clínicos. Achei interessante um quadro que ele faz conversas com streamers do Twitch, alguns famosos como Pokimane, que se abrem pra discutir seus problemas.

A ressalva é porque ele vende coaching online e fala muito de medicina indiana, que não é exatamente consenso. Mesmo assim, as explicações são sólidas e também peguei emprestado alguns exemplo. Mas tem canais que eu não gostei, como o AspieWorld. Esse é o caso de um não-profissional que fala da condição específica dele. Até tem boas informações, mas acho que o estilo dele de quantidade em vez de qualidade, encheu o canal de muita bullshit, achei mais perda de tempo do que vale a pena. E é uma pena porque vejo toneladas de canais falando de TDAH mas esse é um dos poucos de autismo.

Normalmente eu digo que se ficaram com dúvidas mandem nos comentários abaixo, mas cuidado, se ficaram com dúvidas sobre sua própria condição, consulte um especialista, mas se for como eu e ficou fascinado com o assunto, não deixe de pesquisar. Tem diversos psiquiatras e pesquisadores de neurologia que publicam não só papers, mas videos também pra resumir. Se curtiram o video deixem um joinha, assinem o canal e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais.

O Twitter liberou parte do código que chamou de “The Algorithm”, que forma o sistema que popula a aba de recomendações “Para Você”.

Vamos entender qual é o contexto de ciência da computação e história necessários pra começar a entender esse código todo. E uma pequena introdução à ciência por trás de recomendações e grafos em geral.

Finalmente, vou poder mostrar na prática a diferença de “código de curso” e “código de verdade” e exatamente porque software nunca acaba.

Capítulos

• 00:00:00 - Intro
• 00:00:57 - CAP 1 - Avisos e Descrevendo o Repositório
• 00:02:51 - CAP 2 - Interpretando Errado: Não Acredite em Blog Posts
• 00:07:14 - CAP 3 - Derrubando o Meme: Pessoas Idiotas
• 00:11:30 - CAP 4 - Objetivos do Video: derrubar os Clones. Código de Verdade
• 00:16:37 - CAP 5 - Entendendo Grafos. Introdução a Relevância
• 00:21:47 - CAP 6 - Primeira Geração de Relevância: WTF
• 00:27:49 - CAP 7 - Relevância nos Primórdios da Web: PageRank e HITS
• 00:35:43 - CAP 8 - Segunda Geração de Relevância: RealGraph e SALSA
• 00:39:22 - CAP 9 - Escalando com Hadoop e MapReduce: HDFS e Pig
• 00:43:15 - CAP 10 - Algoritmos Escaláveis de Grafos: Relembrando Mergesort
• 00:46:58 - CAP 11 - Terceira Geração de Relevância: GraphJet
• 00:50:36 - CAP 12 - Earlybird: Light Ranker. Apache Lucene
• 00:51:37 - CAP 13 - Ids para Sistemas Distribuídos: Snowflake
• 00:55:23 - CAP 14 - Serialização Eficiente sem JSON: Thrift e Protobufs
• 01:01:07 - CAP 15 - A Controvérsia do “Rails Não Escala”. Por que Scala?
• 01:07:37 - CAP 16 - Introdução a Similarity Clusters: Similaridade de Cosseno
• 01:16:08 - CAP 17 - Resumindo os demais Projetos: Aplicando o que Aprendemos
• 01:20:22 - CAP 18 - Qualidade do Código: Mini-Assessment
• 01:22:43 - CAP 19 - Sendo Educado na Web: Memes Idiotas
• 01:24:32 - CAP 20 - Refletindo sobre o Código: Lições a Aprender
• 01:27:31 - Bloopers

Links

• Fio no Twitter (https://twitter.com/AkitaOnRails/status/1641887891327537158?s=20)
• Twitter: The Algorithm (https://github.com/twitter/the-algorithm)
• Twitter: The Algorithm ML (https://github.com/twitter/the-algorithm-ml)
• Twitter’s Recommendation Algorithm (https://blog.twitter.com/engineering/en_us/topics/open-source/2023/twitter-recommendation-algorithm)
• Steven Tey: # How the Twitter Algorithm works in 2023 (https://steventey.com/blog/twitter-algorithm)
• Aakash Gupta: The Real Twitter Files: The Algorithm (https://aakashgupta.substack.com/p/the-real-twitter-files-the-algorithm)
• Earlybird: Real-Time Search at Twitter (https://stephenholiday.com/notes/earlybird/)
• Twitter Search is Now 3x Faster (https://blog.twitter.com/engineering/en_us/a/2011/twitter-search-is-now-3x-faster)
• Paper: GraphJet: Real-Time Content Recommendations at Twitter (https://www.vldb.org/pvldb/vol9/p1281-sharma.pdf)
• Paper: RealGraph: User Interaction Prediction at Twitter (https://www.ueo-workshop.com/wp-content/uploads/2014/04/sig-alternate.pdf)
• Paper: Real-Time Twitter Recommendation: Online Motif Detection in Large Dynamic Graphs (http://www.vldb.org/pvldb/vol7/p1379-lin.pdf)
• Paper: Discovering Similar Users on Twitter (http://snap.stanford.edu/mlg2013/submissions/mlg2013_submission_20.pdf)
• GitHub: FlockDB (https://github.com/twitter-archive/flockdb)
• GitHub: Cassovary (https://github.com/twitter/cassovary)
• GitHub: GraphJet (https://github.com/twitter/GraphJet)
• Twitter: Finagle (https://twitter.github.io/finagle/)
• Apache Avro (https://avro.apache.org/)
• AkitaOnRails: Chatting with Blaine Cook (Twitter) (https://www.akitaonrails.com/2008/6/17/chatting-with-blaine-cook-twitter)
• Fireship: Vector databases are so hot right now. WTF are they? (https://www.youtube.com/watch?v=klTvEwg3oJ4)
• Slideshare: Restrição == Inovação (https://www.slideshare.net/akitaonrails/devconf-2019-so-carlos)
• Elastic: Vector Search (https://www.elastic.co/what-is/vector-search)

SCRIPT

Olá pessoal, Fabio Akita

Já não é notícia nova, a esta altura acho que todo mundo já viu ou ouviu alguém comentando sobre o código dos algoritmos de recomendação do Twitter, que tio Elon Musk liberou, parcialmente, no último dia de março de 2023. No momento em que estava escrevendo o script deste episódio não se passou uma semana ainda. E até a gravação deste video ainda não foi liberada a segunda parte do código. Mas vamos ver o que temos até agora.

(…)

No mesmo dia que a primeira parte do código foi liberado, eu e diversos outros programadores e pesquisadores começamos a avaliar o código e surgiu muita coisa interessante. Eu mesmo fui twittando em tempo real o que achei de primeiras impressões. Meu foco foi mais na parte técnica e arquitetura. Os links pros meus tweets originais estão na descrição abaixo e neste video vou elaborar em mais detalhes o que não coube em pequenos tweets.

Antes de começar, preciso deixar alguns avisos muito claros aqui. Este código é incompleto. Ainda falta pelo menos uma segunda parte. E mesmo com essa parte, ainda não vamos ter certeza que tudo vai ser liberado. O que o Twitter soltou não é mais que uma pequena fração de todo o código necessário pra se fazer um verdadeiro clone de Twitter.

Esse código só cobre uma parte dos sistemas que devolvem os tweets recomendados que você vê na aba de “Para você”. Em termos coloquiais chamamos isso tudo de “Algoritmo do Twitter”, mas não é um único algoritmo: é uma coleção de dezenas de algoritmos e heurísticas que, funcionando juntos, geram recomendações que tem relevância pros seus interesses.

Mesmo sendo incompleto, estamos falando de mais de 4 mil e seissentos arquivos. Mais de 330 mil linhas de códigos, sendo mais da metade código feito na linguagem Scala, e quase 30% em Java. A próxima linguagem mais relevante depois dessas duas é Rust, na nova parte de machine learning chamada Navi, mas mesmo assim é só 2% do total desse código.

Mais importante, o sistema de build que eles utilizam é o Bazel. Pense NPM se você for de Javascript, ou algo parecido com Gradle se for de Java mesmo. Eu mesmo nunca vi Bazel sendo utilizado num projeto de verdade e cada sub-projeto tem um arquivo de BUILD em Bazel, mas eles omitiram os arquivos WORKSPACE, que são necessários pra conseguirmos realmente compilar e buildar cada projeto.

É possível reconstruir do zero, via tentativa e erro, mas é um trabalhinho bem chato que eu não tenho interesse em fazer e, até o momento, não vi ninguém se prontificando a fazer. Portanto tudo que eu, ou qualquer outro analisar, é baseado unicamente em análise estática do código, que é um jeito mais bonito de dizer que só temos como ler o código ou fazer compilações parciais. Por isso não acredite em tudo que ler em somente um pedaço do código. Deixa eu dar um exemplo.

Alguns pesquisadores foram mais interessados na parte das regras de negócio: os critérios que afetam o alcance de tweets. Em resumo, não teve nenhuma grande novidade bombástica além do que todo mundo mais ou menos já sabia só por observação. Vamos ver dois exemplos, o blog post do desenvolvedor Steven, da Vercel, e o blog post do Aakash Gupta. Ambos os links, novamente, estão na descrição abaixo.

No post do Steven, você vai ler que o algoritmo de ranqueamento vai determinar pesos em algumas ações em cima do seu tweet. Por exemplo, um like tem peso 0.5, um retweet é mais importante, tem peso 1, se alguém clicar no tweet, der reply ou like ou ficar mais que 2 minutos lendo, vai ter peso 11 e assim por diante. Mas, de onde ele tirou essa informação?

Ele coloca o link pro README no diretório projects/home/recap dentro do repositório the-algorithm-ml, que é o repositório menor de machine learning. A contagem de Scala e Java que falei acima foi no repositório principal the-algorithm, que é o maior; mas tem esse outro menor que é basicamente um projetinho Python, com 91 arquivos e umas 6 mil linhas de código pra PyTorch, que eles chamam de “heavy ranker”.

O problema é que o único lugar nesse código onde esses números de peso aparecem, é na documentação desse README. Olha só, se eu abrir o VS Code no projeto the-algorithm-ml e procurar por esse parâmetro “is_negative_feedback_v2”, que tem um peso negativo 74, só aparece no README, em nenhum lugar no código tem de fato esse valor.

Existe um arquivo “local_prod.yaml” que parece que configura esses parâmetros pra produção, e no servidor deles pode ser que esteja mesmo este número, mas no arquivo neste repositório, não tem nada. Portanto, não posso dizer que está nem certo, nem errado, só que é inconclusivo. Só que se você ler o post, vai achar que isso é um fato. E tenho certeza que um monte de gente vai referenciar esse blog post e repetir a informação sem checar o que significa. O Steven não errou nem mentiu, mas ele está descrevendo informação incompleta.

Mas não é só isso. Se for agora no post do tal Gupta, ele vai falar de outros parâmetros de peso. Por exemplo, ele fala que retweets dão um boost de 20 vezes. E de onde ele tira isso? É do repositório principal the-algorithm, no arquivo EarlybirdTensorflowBasedSimilarityEngine.scala no projeto cr_mixer. Lá tem esse trecho da função getLinearRankingParams. Ah, agora não é um README, é trecho de código. Então deve ser confiável, certo? Também não.

Vamos procurar quem chama essa função. Caímos nesse trecho da função getRelevanceOptions que, caso essa variável useTensorflowRanking seja falsa, daí vai chamar a função com os parâmetros que vimos antes, caso contrário, vai chamar essa outra função getTensorflowBasedRankingParams. Vamos ver o que ela define. Voltamos pro arquivo anterior e vemos que ela chama a função getLinearRankingParams abaixo, mas muda o tipo e, mais importante tem esse applyBoosts pra false.

O que isso significa? Será que então todos esses parâmetros com nome “boost” aqui embaixo vão ser ignorados? Como offensiveBoost ou tweetHasTrendBoost? Aí que tá, não temos como saber. Como disse antes, esse código é incompleto. Até o presente momento não sabemos nem se 100% desse código compila, não sabemos quais dependências estão faltando, não sabemos como buildar e, portanto, não sabemos como executar esse código e nem quais caminhos dentro são realmente executados pra cada tipo de dados e configurações.

E mesmo se conseguirmos fazer rodar, vamos voltar praquele README que mostrei agora pouco, da parte de machine learning com PyTorch. Olha o que diz: “não podemos liberar os dados reais de treino por causa de privacidade”. Faz sentido, claro, mas sem ter o mesmo material de treino, ou pelo menos o mesmo modelo gerado no final, não temos como reproduzir exatamente o que roda no Twitter e, portanto, não podemos garantir que é exatamente a mesma coisa rodando em produção nos servidores deles.

Portanto, do ponto de vista de auditoria, podemos confiar que, sim, esse código é certamente retirado do código real dentro do Twitter. É código demais pra falsificar, não seria prático. Mas os detalhes do que exatamente roda lá dentro, talvez a gente nunca saiba. Sempre é possível omitir camadas de filtros na fase de mixagem que adicionam ou removem tweets, ou omitir os arquivos de configuração reais que modificam todos esses pesos e boosts. Não temos como realmente saber, por isso cuidado com afirmações sendo feitas só lendo esse código.

Antes de continuar, eu preciso falar da vergonha alheia que foi o comportamento geral das pessoas frente a esse código. Vamos estabelecer: eu não sou fã de Elon Musk, Dogecoin é shitcoin, e acho uma puta perda de tempo gente que idolatra o cara ou que perde tempo engajando. Ele é só mais um cara que existe. A existência dele não me afeta, assim como a existência de qualquer outro, pra mim, é insignificante. E é só isso.

O Twitter é uma empresa privada. Como qualquer empresa, ela não tem nenhuma obrigação de liberar código. Portanto, o que ela fez ao liberar, pra mim, é um excelente marketing. Uma cortina de fumaça pra desviar atenção, controlar a narrativa e deixar todo mundo coçando a cabeça tentando desvendar esse quebra cabeça; e ao mesmo tempo cutucar os críticos no governo e cutucar os concorrentes como um Zuckerberg da vida. No mínimo vai deixar muita gente chata ocupada tentando abrir uma caixa semi-transparente que não tem chave pra tranca.

A real motivação por trás disso não me interessa. Só me interessa que temos esse código. O que foi liberado, continua sendo um código excelente de explorar. Porém, pessoas idiotas parece que tem talento de encontrar a parte mais insignificante, e viralizar os memes mais idiotas. Se você pesquisar a palavra “Elon” no VS Code, a primeira coisa que vai aparecer é essa chave “author_is_elon”, logo em cima de outras chaves “suspeitas” como “author_is_democrat” ou “author_is_republican”. Uau, que vazamento inesperado! O que é isso, a prova que o Elon dá boost nos tweets dele? O que é isso de democratas e republicanos, tem manipulação neles também?

Até gente que se auto-denomina “programador” ficou fazendo meme disso. É uma vergonha alheia. Se você viu alguém fazendo meme disso, pode des-seguir, o cara é inútil. Deixa eu mostrar como faz. Vamos lá pro código. Esse “author_is_elon” é chave pra um Map que no final vai se chamar PredicateMap, que é gerado através desta Sequence, onde cada elemento é um tuple com uma string que serve de chave e um FeatureMap, que é uma função booleana. No caso desse trecho do Elon, ele recebe um candidato, provavelmente candidato de tweet pra recomendar, e checa se a tal feature de Author contém esse tal DDGStatsElonFeature. Ênfase em “stats”.

Bacana, e quem usa esse PredicateMap? Vamos procurar no código. Achamos aqui na linha 82 do objeto ServedEventsBuilder que extende essa trait ClientEventsBuilder. Nesse trecho ele tá iterando por cada predicado naquela PredicateMap e no final o que tá gerando são counts pra cada predicado. É um contador. E quem vai usar essas contagens? Vamos de novo pesquisar, agora por esse objeto ServedEventsBuilder.

Pronto, chegamos neste HomeScribeClientEventSideEffect. É o que o Twitter chama de “side-effect”. Pelo que eu já tinha deduzido lendo o código, side-effect é um job de Kafka, um job assíncrono. E Scribe é justamente o servidor de logs open source que foi desenvolvido pelo Facebook. É só um servidor de log, não diferente de um Apache Flume ou Logstash, ou Rsyslog da vida. Esses códigos servem pra gerar métricas. É só isso.

“Ah, mas tinha que ser o cuzão egocêntrico do Elon pra ter um código especial pra uma métrica só pra ele.” Ué, mesmo se for. Se ele desenbolsou 40 bilhões pra comprar a porra toda, achei foi muito pouco código com o nome dele. Achei que fosse achar classes inteiras renomeadas pra DogeCoin ou algo assim espalhado por aí. Aliás, vocês estão assumindo que esse código foi feito por ordem do Elon.

Outra teoria muito mais plausível é que esse código foi feito justamente pelo povo que ele demitiu, pra monitorar os efeitos dos tweets do Elon antes da compra ter sido realizada. Muito mais plausível. Independente do que for, só vamos saber se, alguém de dentro do twitter, vazar os logs do repositório Git de verdade, com o timestamp do commit. E mesmo assim, commits de Git podem ser facilmente adulterados. Por isso é uma discussão meio inútil.

Todo mundo ficou fazendo meme com um código de log. E vocês se acham programadores? A discussão do porque esse trecho existe é irrelevante e só serve pra demonstrar como é um programador que gosta de fazer bikeshed: discutir coisas inúteis, sem nenhum valor, sem nenhum mérito. Você está perdendo seu tempo. Agora vamos entender como um programador de verdade olha pra esse código.

O objetivo a partir daqui é o seguinte: desmistificar a diferença de código de curso, código de tutorial e código de produção de empresa de verdade. Pra um iniciante que nunca trabalhou ou só trabalhou em projetos pequenos, a diferença vai ser gritante. A outra coisa é como um programador sênior pensa. Infelizmente, não tem como, num único video, com só 2 dias de análise, sem compilar, conseguir ter a visão completa. Então tudo que vou dizer são só minhas primeiras impressões.

Eu já disse isso em outros videos, mas aqui vale repetir: código de curso, código de tutorial, código em video no Youtube, são absurdamente diferentes de código de verdade de produção. Não tem nem comparação. A complexidade e tamanhos são impossíveis de caber em qualquer curso ou tutorial. É inviável. Literalmente, sem exagero, um curso vai te ensinar a fazer uma casinha de rato com caixa de sapato, mas todo projeto relevante de verdade é um Burj Khalifa, o arranha-céus mais alto do mundo que nunca foi construído, e toda a engenharia pra construir isso num terreno de areia, sem receita pré-pronta.

Outra coisa que já disse antes: software nunca acaba. Se seu produto realmente vale alguma coisa, você vai reescrever partes ou até ele inteiro, mais cedo ou mais tarde. E com esse código liberado pelo Twitter, vou finalmente poder ilustrar esses dois pontos. E esse vai ser o objetivo do video.

Eu peguei aleatoriamente o primeiro projeto no Github com nome de “twitter clone”. Tem dezenas por aí. Esse é feito em Next.js, com Typescript, Firebase, Tailwind, só “tecnologia de ponta”, como um amador poderia pensar. E ele faz tudo, olha só o Readme: usuários conseguem postar tweets, dar like, retweet, reply, adicionar bookmarks, adicionar imagens, seguir ou des-seguir outros usuários, updates de likes e tudo mais em tempo real. Porra, faz tudo.

Só que não. Isso não passa de uma caixa de sapatos frente ao Burj Khalifa. Vamos ver, com a ferramenta Tokei, vemos que esse projeto tem 158 arquivos e mais de 32 mil linhas de código. Pra um iniciante, sem dúvida, pode parecer gigantesco. Mas não é. Mesmo sendo só uma fração incompleta, o repositório do Twitter que estamos avaliando, tem mais de 4600 arquivos e mais de 330 mil linhas de código. 10 vezes mais código.

Mas esses projetos sequer são equivalentes. Esse tal “clone” é só o front-end e só as operações mais básicas. Ele jamais aguentaria a escala do Twitter em produção. O “the-algorithm” que foi liberado é só pra buscar os tweets que aparecem na aba “Pra você”. Notaram como esses clones omitem a aba “pra você”? Claro, porque justamente a inteligência pra buscar tweets recomendados, em tempo real, em escala, não é um problema trivial de resolver. Todo clone que você achar, ou vai omitir, ou vai ter uma versão super besta de recomendação. E nunca vão escalar pra ordem de centenas de milhões de pessoas. São todos, caixas de sapato.

E não tem nenhum problema nisso. O foco da maioria desses clones é ser um exercício pra iniciantes de front-end treinarem fazer interfaces parecidas com coisas que já existem. Nada mais, nada menos. Nenhum desses clones, seja clone de Twitter, clone de Instagram, clone de Pinterest, chega perto da unha dos pés das versões de verdade e são incapazes de fazer uma fração do que os originais fazem, ou de aguentar uma fração do tráfego. Essa é a realidade dos clones: são todos meros exercícios. Contanto que vocês entendam isso, não tem nenhum problema se exercitar neles. Todo mundo precisa começar do zero. E esse é o nível zero.

A razão dessa diferença é que é trivial fazer qualquer aplicativo funcionar só na sua máquina, com uma pessoa usando. Mesmo se você virar freelancer, normalmente trabalha em projetos que muito pouca gente usa. 10 pessoas. 100 pessoas. Mesmo mil pessoas, é extremamente pequeno. Empresas grandes como MercadoLivre, iFood, Nubank, lidam com milhões, dezenas de milhões de pessoas. No caso de Facebook, Google ou Apple, são bilhões de pessoas.

E nessa escala, as soluções são completamente diferentes de todo curso e tutorial que você procurar. Eu afirmo que não existe nenhum curso que cobre casos de larga escala, simplesmente porque todos fazendo cursos nunca tiveram que lidar com esse problema. Eles também simplesmente não sabem que isso existe. Eu mesmo nunca tive que lidar com o caso excepcional de bilhões de pessoas.

É muito caso a caso, em cada empresa gigante, vai ser diferente. Nenhum curso conseguiria cobrir, mesmo se quisessem. Simplesmente não existe esse material disponível, e é uma das razões de porquê esse código do Twitter é relevante: porque não existe código de produção de empresa de verdade disponível pra podermos mostrar, todos são fechados.

Eu trabalhei em vários projetos, incluindo alguns dessa categoria grande. Mas não posso mostrar, porque nenhum de nós deve quebrar confidencialidade e propriedade intelectual de clientes. Por isso eu falo pra não confiar em nenhum programador que não tenha tido esse nível de experiência: eles nunca viram nada além da dimensão de caixa de sapato e acha que o resto do mundo é pequeno assim. E definitivamente não é. Só quem já subiu no topo do Burj Khalifa, sabe a diferença.

A tal aba “Pra você”, à primeira vista, parece super simples. Na aba “seguindo” mostra só tweets de pessoas que eu sigo, provavelmente em ordem cronológica. Fácil de fazer, um iniciante consegue imaginar um “select top 100 * from tweets order by created_at desc” da vida. Agora, no pra você, tem tweets de gente que eu sigo e de gente que eu não sigo, mas que as pessoas que eu sigo interagiram. Então se eu sigo o João e o João retwitou o tweet do Paulo, no meu “pra você” pode aparecer o tweet do Paulo. Só que não é tão simples assim.

E se quem eu sigo interagiu com 100 tweets? Quais deles deveriam aparecer pra mim? Das pessoas que eu sigo, quais delas são mais relevantes pra aparecer no topo primeiro? Por que eu vejo o like de algumas pessoas mas não de outras? Ah, será que como os posts de blogs tavam tentando explicar, é só botar um peso pra like, outro peso pra retweet e dar um “group by” ou “order by” da vida e pegar o topo? Também não.

Como é impossível cobrir o código todo que foi liberado, escolhi começar falando só de um pequeno trecho. Um banco de dados NoSQL de grafos, que inclusive já tinha sido liberado antes como open source, com licença Apache, chamado GraphJet, e a história por trás dele. Tudo isso foi descrito num paper de autoria de Aneesh Sharma e vários outros colaboradores, publicado em 2016.

Pra todo mundo que não fez ciências da computação entender, na faculdade a gente aprende sobre um troço chamado “grafos”. Na prática, você já deve ter visto e até desenhado. É quando se desenha caixinhas ou círculos que chamamos de nós e ligamos um nó com outro nó com um troço que chamamos de vértices. Podemos representar grafos como matrizes adjacentes ou listas adjacentes. Outra forma de representar grafos é com vetores.

Daí podemos classificar grafos baseados em características como número de nós ou número de vértices, edges ou bordas, direção das bordas. Tem diversos tipos de grafos como unidirecionais. Em Git, por exemplo, você já deve ter ouvido falar que é um DAG, um direct acyclic graph, ou grafo acíclico, que não é cíclico, e direto.

Dado um grafo, temos como navegar de um nó pra outro nó. Pense em nós como uma casa numa rua e os vértices como o caminho, talvez a rua, entre essas casas. Daí temos algoritmos pra navegar como o algoritmo do menor caminho entre dois nós, que é o hello world de grafos. Não só isso, ainda no assunto de classificação, temos nós que ficam nas bordas do grafo que tem poucos vértices e temos nós no meio dos grafos com muitos vértices.

Costumamos chamar esses nós de “hubs”. Na prática, numa rede social, chamamos de hubs, mas pessoas comuns chamam de “influencers”. Pessoas comuns são os nós das bordas, com poucos relacionamentos, que são os vértices.

Tudo na natureza pode ser representado como grafos. Como falei antes, evolução de desenvolvimento de software, pode ser representado como um DAG, um grafo de commits, com branches. Um sistema de logística e entregas é orientado num mapa com grafos, pra determinar o melhor caminho de entrega entre dois pontos. O DNA humano pode ser um grafo, onde os nós são as bases como adenina, citosina, guanina e timina, formando nucleobases. As sinapses do nosso cérebro são grafos.

Num ecossistema animal temos a hierarquia da cadeia alimentar, que pode ser representado como um grafo. No mercado temos grafos de empresas e relacionamentos de comprador e vendedor. E assim por diante. No caso do Twitter, que é uma rede social, os nós costumam ser as pessoas, e os vértices são os relacionamentos, quem nós seguimos, quem damos likes ou retweets, quem bloqueamos e assim por diante.

Se você nunca estudou ciências da computação, vai ter um pouco de dificuldade de entender o que vou explicar e certamente não vai entender nada do código do Twitter. Vou tentar simplificar o máximo que der, mas só consigo chegar até certo ponto, então, se interesse em depois ir procurar cursos como nas aulas do MIT sobre grafos. Pra operar em grafos, você vai precisar aprender coisas como Álgebra Linear e Cálculo, pelo menos o Cálculo básico.

E portanto sim, pra entender como uma rede social funciona e o código por trás, precisa entender esses aspectos da matemática. E pra chegar no ponto de recomendação, também precisa entender o básico de estatística e probabilidade, porque recomendação é justamente a probabilidade dos tweets que o sistema recomendar realmente te interessar a ponto de engajar, dar like ou reply, que é a base de machine learning.

Mesmo se você não for implementar do zero inteligência artificial, machine learning, ainda assim precisa entender essa matemática. Machine Learning é, nada mais, nada menos, do que uma coleção de algoritmos de classificação e probabilidade. Se não souber quando pode usar regressão linear, regressão logística, similaridade de cosseno, bayes ingênuo, não vai saber o que fazer.

Cada caso, cada tipo de conjunto de dados e o resultado que quer, depende de saber escolher quais desses algoritmos usar. E pra saber quais usar, precisa saber a matemática por trás. Senão vai usar regressão linear quando não podia e ter resultados errados, que é a coisa mais comum de ver amador fazer. Nem tudo que parece uma reta, é uma reta.

E no caso desse código do Twitter sim, eu encontrei que ele usa coisas como grafos, regressão logística e similaridade de cosseno. Mas estou me adiantando. Vamos voltar ao tal paper do Graphjet de 2016. Um problema, que não é trivial de resolver e não tem uma solução única, porque depende do comportamento dos usuários e dos dados disponíveis, é recomendação. Seja recomendação de produtos num ecommerce, recomendação de leitura num site de notícias, ou recomendação de tweets num Twitter.

Como usuários seguem usuários, naturalmente temos grafos, em particular grafos bipartidos, com usuários de um lado e tweets de outro. Os esforços de recomendação começaram no Twitter por volta de 2010, lembrando que o Twitter começou a operar em março de 2006.

Eu mesmo criei minha conta só um ano depois, em abril de 2007, durante a Railsconf 2008 em Portland, onde eu via todo mundo se cadastrando pra gente compartilhar onde ia ser o próximo happy hour. Lembrando que ainda não existia Messenger do Facebook, não existia Whatsapp, não existia Telegram. O único aplicativo de mensagem que todo mundo usava, era SMS.

De qualquer forma, quando eles começaram a experimentar a recomendar usuários novos pra gente seguir, por volta de 2010, foi com um sistema que chamaram carinhosamente de “WTF”, What the Fuck. Mentira, era “Who To Follow”. A arquitetura era como nessa figura. Segundo o paper, no seu núcleo tinha esse Cassovary, que é um motor de processamento de grafos in-memory, ou seja, que mantém os grafos em memória. Isso é importante, porque a maioria dos algoritmos conhecidos pra lidar com grafos assume ter o grafo todo em memória. Guarde essa informação.

Esse projeto Cassovary é open source e podemos encontrar no GitHub deles. Última atualização foi de 2021, e não é mais utilizado hoje. Continuando, esse Cassovary operava em snapshots de grafos de seguidores carregados do HDFS, que é o sistema de arquivos distribuídos do Hadoop. Quem já trabalhou com Big Data, Data Lakes, certamente já esbarrou em instalações de HDFS e no Twitter não era diferente. Só entenda que é um sistema de arquivos distribuído, como se você tivesse uma partição única espalhada em múltiplos servidores. É um nível acima de um simples RAID.

Os grafos de seguidores vinham de outro banco de dados chamado FlockDB que fazia a ingestão desses dados no HDFS. FlockDB acho que foi o primeiro banco de dados de grafos que o Twitter criou e soltou como open source. O que aconteceu foi: eles começaram como qualquer tech startup normal, sem saber o que o produto ia se tornar. No começo usavam um banco de dados normal, MySQL mesmo. Mas quando começaram a fazer sucesso e ver que o problema era maior que um banco relacional, começaram a pesquisar alternativas. E o primeiro resultado foi um banco de dados de grafos, o FlockDB.

O FlockDB dava mais performance pra operações de inserção, updates, já que não precisava das garantias ACID de um banco relacional. Tinha operações extras pra lidar com grafos, como navegar por nós e pelos vértices. E vocês tem que entender que carregar um grafo em memória pode ser pesado. Imagine sua própria conta: você tem dezenas de tweets, você segue dezenas de pessoas, essas pessoas tem dezenas de tweets.

Cada um desses tweets tem contagens de likes, retweets; alguns tweets são replies pra outros tweets. E pra calcular qual deles é mais relevante ou menos relevante, o ideal é ter toda essa estrutura em memória pra conseguir navegar por toda essa informação. Agora pensa num banco de dados relacional como MySQL. Como você resolveria esse problema? Qualquer solução que você imaginar em SQL, pode ter certeza, já foi testado e sabemos que não vai escalar. Essa é um dos poucos cenários que podemos afirmar que um banco de dados relacional não é adequado.

Segundo a página de GitHub do FlockDB, até 2010 o cluster deles armazenava mais de 13 bilhões de bordas e sustentava picos de tráfego de mais de 20 mil escritas por segundo, e mais de 100 mil operações de leitura por segundo. Mas rapidamente chegou um ponto onde isso já não era mais suficiente. Foi quando começaram a puxar esses dados pra HDFS e processando nesse novo projeto que chamaram de Cassovary, um segundo projeto em Java pra lidar com “Big Graphs”, grafos com bilhões de nós e vértices. Foi a época que as celebridades gigantes começaram a viver no Twitter. Pense nível Kardashians.

Voltando ao paper, a camada de armazenamento do Cassovary dava acesso aos grafos via queries, pesquisas baseadas em vértices. Pense um “SQL” especializado em grafos. E em cima disso um motor de recomendação computava as sugestões de “Who To Follow”, o WTF, ou “quem seguir”. Foi assim que nos primórdios do Twitter a ganhamos sugestões de novas contas pra poder seguir.

Um dos objetivos desse projeto era ver se era possível manter os grafos em memória, in-memory. A pergunta que eles não tinham resposta é: será que o crescimento do volume de dados desses grafos seria mais lento que a Lei de Moore? Se for, o preço de memória iria baratear mais rápido do que os dados cresciam, e daria pra computar tudo em memória. Que é mais simples do que ter que lidar com discos, particionamento, paging, cache e tudo mais.

Como o paper diz, considere um grafo com 10 bilhões de bordas: mesmo uma representação ingênua, simples, ocuparia algo na faixa de 80 gigabytes, que um único servidor consegue aguentar. Você já trabalhou com um servidor, este ano, que tem 80 gigabytes? Se sim, diga nos comentários que empresa é, pra todo mundo entender meu ponto.

Uma das limitações, mesmo naquela época, é que essa sugestões de recomendação de quem seguir, eram calculados em batch, uma vez por dia, não era em tempo real como é hoje. Ou seja, você só tinha recomendações novas uma vez por dia. De qualquer forma, via muita experimentação, muitos testes A/B, eles chegaram em dois conceitos que usam até hoje e que vale explicar. O primeiro se chama círculo de confiança e o segundo foi a adoção de “SALSA” que é Stochastic Approach for Link-Structure Analysis ou Análise de estrutura de links usando processos estocásticos.

Um exemplo de grafo que eu não mencionei, mas deveria ser óbvio, é a própria World Wide Web. Toda página na internet é um nó, as bordas, vértices, são links de uma página pra outra. No começo da web, já se tinha um número grande de páginas, o suficiente pra ser difícil de achar as coisas. Pense numa era antes de existir Google. A forma rudimentar que existia pra gente se achar era derivado do conceito antiquado de Páginas Amarelas.

Se você for muito novo talvez nunca tenha visto, mas antigamente, quando precisávamos achar um mecânico, um médico ou qualquer serviço, tínhamos um livrão físico de páginas amarelas que era um diretório com todos os serviços da cidade. Cada cidade tinha um livro diferente. Imaginem que novos negócios tinham dificuldade de serem encontrados, porque precisava esperar uma nova edição ser impressa e distribuída pra todo mundo. Páginas de classificados nos jornais meio que cobriam um pouco dessa diferença.

Serviços como Yahoo, Excite, Lycos e outros serviam esse papel na Web. Se eu criasse um site novo, pedia pra ser incluído num desses diretórios pra que as pessoas conseguissem me achar. Esse era o processo. Mas mesmo assim, imagine restaurantes. Qual das centenas de restaurantes numa cidade grande como São Paulo, seria relevante pra mim? Mesmo se tivesse a opção de filtrar por localização e tipo de cozinha. Ainda assim eu tinha que manualmente tentar várias. Era bem trabalhoso.

Portanto, resolver esse problema de relevância entre milhares de páginas web, era muito importante. E lá no meio pro fim dos anos 90 surgiram pelo menos dois estilos diferentes de lidar com isso. A maioria de vocês que estudou o mínimo de grafos talvez estejam familiarizado com o famoso paper de PageRank, literalmente ranking de páginas, inventado pelos fundadores do Google, Larry Page e Sergey Brin em 1996 quando ainda eram estudantes de Stanford.

Procurem no YouTube, tem dezenas de videos que explicam PageRank, mas a idéia básica é a seguinte. Começa pelo básico, o “H” de HTML é pra Hyperlink. Todo mundo esquece isso, mas o mais importante numa página web é que a página de alguém contenha um link pra sua página. Quanto mais sites diferentes tem links apontando pro seu site, mais relevante ele pode ser.

No PageRank, imaginamos um navegador aleatório, uma pessoa imaginária que vai clicando em páginas e nos links nessas páginas, aleatoriamente. Qual a probabilidade de, só navegando sem rumo, alguém cair na sua página? Esssa probabilidade é o seu score, sua pontuação. Se sua página é famosa, centenas de outras páginas contém link pra sua, a probabilidade desse navegador aleatório chegar na sua página é alta, portanto sua pontuação no ranking, no PageRank, é alta.

Esse foi o algoritmo usado na primeira versão do Google, o site que matou todos os diretórios estilo páginas amarelas. Porque agora era possível fazer um programa que sai vasculhando todas as páginas na web, avaliando os hyperlinks entre eles, e atribuindo pontuações nesse ranking. Daí, quando fazemos uma pesquisa, ele nos mostra primeiro as páginas mais bem pontuadas. É por isso que logo na primeira página, os primeiros links costumam ser os corretos.

Com isso eliminamos a necessidade de seres humanos ficarem manualmente classificando páginas em diretórios e atualizando a relevância na mão, que sempre foi demorado, trabalhoso, tedioso e com muita margem de erro. Essa talvez tenha sido a primeira categoria de trabalhadores da web que perderam seu trabalho pra um algoritmo, e não será a última. Tudo que é feito manualmente e pode ser automatizado, certamente será. Todo trabalho repetitivo é automatizável, sabemos isso desde o começo da Web.

Mas todo algoritmo tem seu ponto fraco e rapidamente as pessoas começaram a notar que se o lance é esse número de links pra sua página, que tal criar um monte de sites fantasma que fazem links pra uma página que você quer tornar relevante? E assim surgiram os primeiros web farms, fazendas de servidores fake, e uma galera que vendia relevância pro seu site, fazendo um monte de site falso linkar pra sua. Seja criando sites bestas em série ou invadindo sites dos outros pra colocar links.

Isso aconteceu só lá no começo dos anos 2000. Por isso o Google evoluiu e deixou de usar PageRank e passou a usar, por exemplo, TrustRank, que combate web spam identificando quem é site legítimo e quem não é, e descontando pontuação. Ao longo dos anos o Google sempre foi aprimorando esses algoritmos, não é um produto fixo. Parte do trabalho de agências web era ficar monitorando quando o Google lançava uma nova versão pra modificar as estratégias pra levar relevância pros seus clientes. Esses truques baratos não funcionam mais hoje.

Mas não era só isso. Mesmo sem spammer e gente maliciosa, as primeiras versões do PageRank ainda sofriam de um problema grave. Pra ilustrar, veja meu conteúdo, meu canal e meu blog, que é de um domínio muito específico de assuntos de tecnologia pra programadores. Talvez eu faça um video explicando em detalhes sobre o algoritmo do Twiter, exatamente o que estou fazendo agora. Pra programadores é relevante.

Porém, imagine que um bosta como um Felipe Neto também faça um video falando sobre o algoritmo do Twitter. Segundo o PageRank, que é um ranking global, quer você goste dele ou não, se pesquisar no Google de 1997 “algoritmo do Twitter”, esse video do Felipe Neto iria aparecer na frente do meu. Essa é a desvantagem de um algoritmo de ranking global como o PageRank original.

Mas como eu falei, as pesquisas em torno de grafos evoluíram rápido. Por exemplo, em 1999 surgiu o algoritmo HITS que significa Hyperlink-Induced Topic Search, de Jon Kleinberg. HITS opera num grafo direcionado, onde páginas web representam nós e hyperlinks são bordas direcionadas. Até aqui, igual PageRank, mas o HITS assinala duas pontuações pra cada página web: uma pontuação se é um “hub” e outra pontuação se é uma “autoridade”.

Hubs são páginas que linkam pra diversas outras páginas. Pense um site do Estadão ou da Folha. São hubs de notícias que linkam pra trocentas outras páginas fora. Ou influencers como o Nelipe Feto, é um hub. Já autoridades são páginas que recebem muitos links de muitos hubs. Pense a página da Receita Federal em época de imposto de renda. Todo mundo faz link pra ela, pra avisar que tá vencendo a data ou ensinando como preencher seu imposto. Mas todo mundo pode ser ao mesmo tempo um hub e uma autoridade, alguns são mais hubs, alguns são mais autoridades num domínio em específico. Por isso duas pontuações distintas.

Portanto, o canal de um Nelipe Feto da vida teria uma pontuação de Hub muito maior do que de autoridade, que é exatamente o perfil do influencer médio: serve pra direcionar tráfego pra todo mundo, mas ele mesmo não é autoridade de quase nada. Já caras como eu geram muito pouco tráfego pros outros, mas todo mundo me menciona e linka pra mim em assuntos de um domínio específico de programação e tecnologia.

Com isso, minha pontuação de autoridade, num video sobre “algoritmo do Twitter”, seria maior que do Nelipe e eu apareceria no topo da pesquisa, mesmo ele tendo muito mais tráfego e sendo muito mais famoso. Essa é a vantagem de algoritmos da família do HITS, se comparado ao PageRank original: ele torna esse jogo bem mais justo do que uma pontuação única global, e tenta melhorar a confusão entre influencer e autoridade. Só porque alguém tem muito seguidor, de jeito nenhum o torna autoridade de coisa nenhuma.

Porém, se antes, a forma ingênua era ter uma única pontuação global do PageRank, em HITS teríamos sub-grafos pro domínio ou tópico, por exemplo, programação, gastronomia, viagens, cinema e cada vértice teria duas pontuações, de hub ou autoridade, por tópico. Portanto dá pra imaginar que é mais caro computar HITS do que PageRank. Claro, o que temos hoje num Google é uma amálgama dessas técnicas e muitas outras que surgiram ao longo do tempo. O que nos leva de volta a SALSA.

SALSA poderia ser considerado uma evolução da idéia de HITS pra análise de links, mas uma das idéias é não precisar navegar por todos os vértices e pontuar o grafo inteiro. Em vez disso ele implementa a idéia de andarilho aleatório ou random walker. É que nem pesquisas de opinião pública. Todo mundo tá acostumado a ver agências de fake news, cof, quero dizer, imprensa tradicional, fazendo pesquisas de opinião na rua pra dizer “ah, metade dos brasileiros considera o governo atual uma bosta”. Mas como eles sabem disso? Eu não lembro de ninguém me perguntando isso.

Essa é a mágica da estatística. Podemos fazer sampling, ou seja, pesquisar só uma fração da população. Quanto mais aleatório for esse sampling, melhor. Um coisa é perguntar pra 100 pessoas só de São Paulo, outra coisa é perguntar pra 4 pessoas de cada estado. Assumindo que escolhemos bem esse grupo, dentro de uma margem de erro, podemos afirmar que a população em geral tem essa ou aquela opinião, economizando ter que perguntar pros mais de 200 milhões de cidadãos do país. É uma puta economia de 200 milhões pra 100. Entendem?

Mesma coisa num grafo. Eu não preciso necessariamente andar o grafo inteiro, posso escolher um grupo aleatoriamente, em vez de usar o modo iterativo original do HITS, economizando muito processamento e tendo resultados que caem em margens de erro estatisticamente aceitáveis. Pra otimizar mais isso, ele também reorganiza os nós e vértices num grafo bipartido, que ajuda a separar os papéis de hubs e autoridades.

Posso separar nossos nós em dois conjuntos distintos: um com páginas que linkam pra outras páginas, os hubs, e outro grupo com páginas que recebem links, as autoridades. Não vale a pena eu detalhar hoje, mas gravem esses dois conceitos de random walk e grafo bipartido pra estudar depois se tiverem interesse.

Expliquei tudo isso porque o paper do Twitter menciona que eles desenvolveram um algoritmo de recomendação baseado em SALSA, que é um algoritmo de random walk na mesma família de HITS, originalmente desenvolvido pra ranking de pesquisa web. O algoritmo constrói um grafo bipartido de uma coleção de websites de interesse (hubs de um lado e autoridades de outro), e cada passo no SALSA navega por duas bordas - um pra frente e outro pra trás. - agora você sabe o que esse parágrafo do paper está dizendo.

E ele continua dizendo: nós adaptamos SALSA pra recomendação de usuários da maneira mostrada nesta figura. O lado de hubs na esquerda é populado com o tal círculo de confiança do usuário, os usuários que ele escolheu manualmente seguir. As “autoridades” no lado direito são populados com usuários que esses hubs interagem. Depois que esse grafo bipartido é construído, rodamos múltiplas iterações de SALSA, que assinala pontuações.

Daí os vértices do lado direito são ranqueados por essa pontuação e tratados como recomendações de usuários. Os vértices do lado esquerdo também são ranqueados e interpretados como similaridade entre usuários. Baseado no princípio da homofilia, que é só um nome bonito pra dizer que pessoas com interesses parecidos tendem a se agrupar mais, podemos apresentar esse resultado como recomendações, que antigamente era uma seção chamada “similares a você”.

Resolvi dar uma detalhadinha a mais até aqui pra tentar explicar como foi o raciocínio por trás da primeira versão do motor de recomendação, mas agora vou tentar andar um pouco mais rápido, porque esse foi o sistema WTF que não existe mais. Sim, toda essa pesquisa, experimentação, durou pouco tempo. Apesar de ser um sistema bom, que funcionou bem, ele ainda não é o que conhecemos hoje. E em 2012 eles começaram a perseguir o tal projeto Cassovary que mencionei antes.

Pra ter recomendações ainda melhores, eles queriam usar mais sinais dos logs de comportamento dos usuários. Comportamento de likes, retweets, replies, follow e tudo mais. Mas isso torna os metadados do grafo ainda maiores e a premissa da primeira versão, que era tentar manter tudo em memória, já não cabia mais. Daí veio a decisão de tentar usar Hadoop, em particular Apache Pig que, pra quem não sabe, é tipo um compilador que produz sequências de programas MapReduce.

Hadoop é uma plataforma de tecnologias criadas pra lidar com o problema de Big Data no auge da Bolha da Internet no começo dos anos 2000. Pra muita gente ainda hoje, o conceito de Big Data não é muito palpável, porque ninguém lida com isso no dia a dia. Varia de produto pra produto, mas quando estamos gerando coisa como gigabytes por dia de dados, terabytes por mês, estamos em território de Big Data. O que você faz, com um banco de dados que tem centenas de terabytes? Deita e chora, porque não importa quão bom seja seus índices e queries, sua aplicação vai ficar absurdamente lenta, só pelo tamanho.

Nessa ordem de grandeza estamos falando que não é possível manter todos os dados numa única máquina, mesmo sendo um servidor grande, seja por limitação física ou de custo. Daí a única solução é a estratégia de Napoleão: particionar, dividir esse tanto de dados em múltiplos servidores, e daí conquistar. Por isso a base do Hadoop começa com o HDFS, que é o Hadoop File System, um sistema de arquivos distribuído.

Agora o problema é o seguinte: na faculdade você aprendeu a lidar com dados todos no mesmo lugar. Por exemplo, digamos que você tem uma lista de produtos e preços e queremos achar o produto mais barato, como faz? Simples, escolhe um algoritmo qualquer de ordenação como um Quicksort ou Mergesort da vida, e pega o primeiro elemento que vai ser o mais barato. Pra fazer isso, precisamos iterar elemento a elemento da lista pelo menos uma vez. Mas e agora, e se estamos com 5 servidores e essa lista foi dividida por 5?

Intuitivamente, poderíamos pensar, beleza, vou ter que repetir a ordenação uma vez em cada máquina. Daí no final vou ter uma lista parcial com os 5 produtos mais baratos achados em cada um dos 5 servidores, daí faço uma última ordenação nessa lista e finalmente acho o mais barato. Cada um dos servidores vai rodar em um quinto do tempo do que se fosse a lista completa, mas no final, ainda tem pelo menos mais uma operação de ordenação extra e aí tenho o resultado. Então seria tecnicamente um pouco mais “lento” rodar em vários servidores separados, mas vai ser menos caro.

Isso de rodar um algoritmo em pedaços dos dados, mapear os resultados parciais e depois reduzir na resposta final, é o que, a grosso modo, chamamos de MapReduce, que é parte fundamental de como fazer processamento de dados em Hadoop. Novamente, não vou detalhar MapReduce então anote pra pesquisar mais depois. MapReduce ficou famoso porque, depois do PageRank, é como o Google conseguiu operar em larga escala e deixou todo mundo no chinelo no começo dos anos 2000.

Hoje em dia é como toda grande empresa de tecnologia funciona, mas 20 anos atrás, essa forma de pensar em processamento de dados foi fundamental pra possibilitar termos produtos que aceitam quantidades massivas de pessoas e transações, literalmente ultrapassando a população total de diversos países. Tem mais gente no Twitter do que a população dos Estados Unidos, metade da população do mundo tá em produtos da Meta.

Por isso, pra segunda versão do motor de recomendação, o Twitter deixou o FlockDB e WTF pra trás e perseguiu o tal projeto Cassovary pra rodar em cima do HDFS do Hadoop, usando MapReduce. Mas eles tiveram vários problemas. Mesmo em 2012 já era sabido que grafos não performavam bem em Hadoop. Isso porque a maioria dos algoritmos conhecidos pra processar grafos são iterativos, lembra que falei pra guardar essa informação?

Pra ilustrar. Pense nos diferentes algoritmos de ordenação que aprendeu na faculdade. Alguns professores cometem o pecado de não explicar porque existem tantos e porque foram criados. Por exemplo, meu professor na faculdade mandou a gente decorar lá Quicksort, Mergesort, mas não explicou que mergesort foi criado pelo lendário Von Neumann pro problema de listas de dados que não cabiam na memória RAM da época, então começavam gravados numa fita. Daí o algoritmo vai percorrendo os elementos da fita, sem estourar a RAM, e vai gravando ordenado numa segunda fita. Se tiver essa imagem de fitas na cabeça, mergesort finalmente faz sentido. Sem isso, é um algoritmo que não faz sentido existir.

Em 2012 ainda não existia o equivalente mergesort pra grafos que não cabem em memória e precisam ficar divididos em partições de HDFS distribuídos em múltiplos servidores. Hoje em dia já existe um suporte maior. Pense um Apache Spark com GraphX. Mas 10 anos atrás, era um uso inédito ainda. O próprio paper descreve que eles estavam cientes dessas desvantagens. O paper menciona que o gargalo era na materialização dos vizinhos dos vértices, que requeria um enorme shuffling de dados, que é pegar dados de diversos servidores pra formar o grafo necessário pro processamento.

Nessa parte do paper ele referencia outro paper, o “Discovering Similar Users on Twitter”, onde é explicado como exatamente eles conseguiram passar as barreiras de usar Hadoop, adaptando o algoritmo de PageRank personalizado pra ambiente distribuído. Como já expliquei, esse algoritmo é largamente utilizado pra computar similaridade entre nós em um grafo, mas é iterativo e requer data shuffling frequente. Quando falo data shuffling é tipo reembaralhar dados. Pensa como isso é difícil quando seus dados estão distribuídos em diferentes servidores.

Pra resolver, os autores do paper propõe uma modificação ao algoritmo de PageRank personalizado chamado “One Pass PPR”, que reduz o número de iterações e minimiza esse reembaralhamento pra cada iteração. Nesse caso, os dados são particionados baseados nos IDs dos usuários e processados numa única passada sobre os dados, usando uma combinação de pontuações local e global. O algoritmo também usa técnicas de caching pra evitar recomputar resultados intermediários, reduzindo o número de iterações totais.

Além disso os autores também propõe técnicas de compressão pra reduzir o tamanho do grafo e possibilitar processamento mais rápido em sistemas distribuídos como Hadoop. É muito detalhe pra tentar explicar hoje, mas esse é o resumão desse outro paper que também recomendo darem uma olhada depois.

É nele que se resolve o problema de conseguir dizer que quem segue um Lebron James tem alta probabilidade de seguir um Kobe Bryant ou quem segue uma Lady Gaga costuma seguir uma Taylor Swift. E é onde nasce o framework que é utilizado até hoje e que vou retornar pra explicar, sobre a arquitetura de geração de candidatos e modelo de aprendizado baseado em regressão logística e similaridade de cosseno pra achar usuários similares no Twitter.

Voltando ao Cassovary, é só uma parte da solução, é quem dá acesso aos dados dos grafos em Hadoop. A solução geral é chamada de RealGraph, que é uma representação composta do grafo de seguidores e grafos de interação induzidos através de logs de comportamento. Essa representação é construída de múltiplos pipelines de funcionalidades que são extraídas, limpas, transformadas e juntadas a partir dos logs crús. O RealGraph é armazenado em HDFS. E esse nome “RealGraph” vamos encontrar no código em Scala do repositório que foi liberado, como podemos ver no VS Code. Toda vez que ver “RealGraph”, provavelmente é isso.

Mas esse segundo motor de recomendação ainda tinha um grande defeito, só servia pra recomendar usuários similares pra você seguir e só atualizava poucas vezes ao dia, não era nem perto de ser tempo real. Funcionava, mas ainda não é a aba “pra você” que tem no Twitter hoje. Pulamos do WTF de 2010, pro Cassovary, Hadoop e RealGraph de 2012, e agora saltamos pra 2014 e um novo paper que descreve algumas novas estratégias pra particionar e organizar esses grafos. Como podem ver, não era um problema trivial de resolver.

No caso de Twitter, e até em sistemas de mensageria em geral, existe uma particularidade nos dados: você nunca precisa do grafo inteiro dos usuários. Por exemplo, pouca gente tá interessado em ver tweets de mais de 1 ou 2 dias atrás das pessoas que segue. Então mesmo que seu influencer favorito tweet todos os dias, o que seria um volume grande de tweets pro grafo, podemos limitar uma janela de 1 ou 2 dias pra todo mundo e lidar com um sub-grafo muito menor.

Pensando assim não precisamos lidar com operações como “deletar” um tweet do grafo, por exemplo. Basta pensar em expiração. É mais ou menos o mesmo pensamento por trás de caches como Memcached ou Redis da vida, que usamos hoje. Não pense em como apagar dados velhos, estabeleça uma janela de tempo e deixa expirar sozinho, que é boa prática de qualquer tipo de caching.

Não só isso, mas não precisamos guardar o timestamp exato de cada tweet no grafo. Isso vem da observação que a maioria das interações, como likes, retweets, replies, costumam acontecer muito próximo do momento que o tweet foi criado. Pra maioria de nós é interessante saber que o tweet foi postado 1 hora atrás, 5 horas atrás, 1 dia atrás, mas não interessa exatamente quando. É menos um dado pra ter em memória e mais uma economia.

Pensando em tudo que eles aprenderam até agora, iniciariam um terceiro motor de recomendação em cima de outro projeto que eles também tornariam open source, chamado de GraphJet. Ele mantém um grafo bipartido que registra integrações de usuários a tweets durante as mais recentes “n” horas, com uma API super simples só com as operações que eles sabiam que realmente iam precisar, sem fazer overengineering de criar um banco de dados de grafos genérico demais. Finalmente tinham experiência suficiente pra conseguir especializar a solução.

O resto do paper entra em detalhes sobre como foi a estratégia de mapeamento de IDs, estratégias de gerenciamento de memória pra balancear reembaralhamento e distribuição dos dados. Em resumo, eles conseguiram chegar num modelo onde só o processamento pra encontrar usuários e tweets recomendados ficou na casa abaixo dos 10 milissegundos, que é perto do ideal pra conseguir ter resultados em real-time, onde a maior parte dos gargalos era a comunicação com os diversos sistemas de filas, como o Apache Kafka que usam até hoje.

Esse paper é bem bacana e recomendo lerem com muita calma e anotando cada termo que não conhecem pra pesquisar depois. Ele descreve as três gerações de motores de recomendação dentro do Twitter até 2016. Não parei pra ver se tem papers mais novos que continuam essa história, mas graças a isso o código liberado que tem vários trechos que mencionam RealGraph ou GraphJet, agora devem fazer mais sentido. Entenderam? Sem esse tipo de pesquisa, só lendo o código liberado, ninguém nunca ia entender do que se trata. Precisa do contexto histórico.

E isso é só a parte do motor de recomendação, existem diversas outras funcionalidades no Twitter, por exemplo, o motor de pesquisa, que é quando você faz pesquisas por palavras-chave e ele retorna tweets com esse conteúdo, que nem uma pesquisa no Google. Na figura da solução do Cassovary, que puxa dados do HDFS, que vieram do FlockDB, pra cima tem fetchers que mandam pra um serviço chamado Blender.

Blender foi um front-end escrito em Java em cima do Netty, que é a grosso modo o equivalente a um Node.js pra Java. Por baixo usa o lendário Apache Lucene como motor de procura. Lucene é feito em Java e a gente usa faz anos. Toda vez que um site tiver um campo de pesquisa, e os resultados forem bons, pode ter certeza que tem Lucene por trás. O produto mais famoso que é construído em cima do Lucene é o Elastic, também conhecido como Elasticsearch, ou o Solr da própria Apache. Full text search, correção ortográfica, auto complete, tudo isso já é problema resolvido por Lucene, Solr ou Elastic.

Só encontrei um post no blog de engenharia do Twitter e outro post de um ex-programador que trabalhou no Twitter por volta de 2012, mas além do Blender existia um outro sistema relacionado à parte de pesquisa em tempo real, que é diferente do sistema de recomendação, chamado Earlybird. E eu menciono isso porque “Earlybird” é outro termo que aparece bastante no código que foi liberado recentemente. Então agora você sabe.

Aproveitando que comecei a falar de projetos open source do Twitter, na parte do paper onde ele explica o desenvolvimento da solução GraphJet, falei que tem uma seção que fala da estratégia de IDs. Isso gerou outro projeto open source chamado Snowflake, que eu não conhecia também. Mas em dados distribuídos, IDs únicos é um problema. Por exemplo, numa tabela de banco de dados MySQL, rodando na sua máquina local, você coloca um inteiro auto incremental e esquece. Cada nova linha vai ganhando um ID como 1, 2, 3 … 10, 11, 12 … 1001, 1002 e assim por diante.

Ids incrementais tem diversos problemas, um deles é segurança, mas o outro é conseguir particionar esses IDs. E quando eu tenho um banco de dados distribuídos em 2 servidores? Vou só dizer que no primeiro servidor vai de 1 a 1 milhão, no segundo servidor vai de 1 milhão a 2 milhões? Isso não escala. Se você for mais esperto vai lembrar, ah, podemos usar coisas como UUID ou GUID da Microsoft, IDs de 64 bits ou 128 bits aleatórios. Ou até espaços menores de 48 bits, como MAC address de placas de rede.

Quanto maior o ID, mais espaço vai ocupar em disco e quando carregar em memória. E se vamos desperdiçar esse espaço, o ideal é que não seja aleatório e sirva algum propósito. Daí temos IDs semi-aleatórios. No caso da estratégia do Snowflake o ID é um número aleatório prefixado com um timestamp, um identificador do servidor onde está, e uma sequência numérica aleatória. Dessa forma consigo agrupar tweets que foram criados num determinado período de tempo, tenho a localização no cluster de servidores, mas também sei que não vai ter colisão desse ID com outro ID em outro servidor. Quer dizer, até pode ter colisão mas a probabilidade é hiper baixa, perto de zero, na prática.

Menciono isso porque se procurar no VS Code, olha só, Snowflake aparece em diversos lugares do código. E achamos trechos que usam a função timeFromIdOpt onde passamos um ID de Snowflake e ele retorna um timestamp, daí podemos fazer operações, como ver se foi criado antes ou depois de determinada data. Se estudar bancos de dados distribuídos, vai ver como existem diferentes estratégias de IDs únicos pra diferentes necessidades.

Um banco de dados como Cassandra usa outra estratégia, chamada TimeUUID, que é muito similar, já que também tem um componente de timestamp embutido no ID, o que facilita fazer queries de períodos de tempo e análise de time series, séries de tempo e processamento de eventos. Um DynamoDB da Amazon tem um identificador único chamado de “chave de partição” que é usado pra particionar dados em múltiplos servidores no cluster. A chave de partição é combinado com uma “chave de ordenação”, que é usado pra ordenar os dados dentro de uma partição.

Sem fugir demais do assunto, mas já que falei disso, preciso pelo menos explicar outro conceito. Em bancos de dados distribuídos, um problema seria se um servidor ficar mais cheio que outros servidores. Idealmente queremos balancear o volume de dados entre cada servidor. Uma das formas de fazer isso é o que chamamos de “Consistent Hashing”. Esse algoritmo mapeia chaves de partição, como o Snowflake do Twitter ou TimeUUID do Cassandra em nós virtuais num anel, um ring. Cada nó virtual representa um servidor físico no cluster.

À medida que novos nós são adicionados ou removidos do cluster, os ranges de partição são redistribuídos por todos os nós virtuais, garantindo distribuição uniforme das chaves de partição. Novamente, é um problema bem conhecido e bem resolvido nos mais diversos bancos de dados distribuídos. Eu lembro quando líamos papers da Amazon sobre isso lá por 2008 e 2009. Mas pra um estudante de ciência da computação hoje, continua sendo um problema fascinante de entender, já que o conceito é bem simples. Um ID é muito mais do que só uma etiqueta qualquer. Ela serve pra facilitar pesquisas e pra facilitar balanceamento de sistemas distribuídos.

E pra terminar essa parte de open source, tem outros dois projetos que são mencionados que acho importante explicar. O primeiro se chama Thrift e o segundo é Protocol Buffers ou Protobufs. Acho que muitos de vocês já devem ter ouvido falar pelo menos de Protobufs. Bem a grosso modo, pense micro-serviços ou endpoints de APIs hoje. A maioria de vocês deve estar acostumado a ter endpoints que se comunicam ou simplesmente cospem dados em formato JSON. É o hello world de APIs em todo tutorial e curso. Só que JSON não é a única forma e pra muitos casos, é a pior opção.

JSON é um formato excelente pra endpoints de APIs que seres humanos como eu ou você vamos manipular. É indicado pra coisas como APIs de ecommerce, onde queremos puxar coisas como principais ofertas, pra mostrar no nosso blog. Mas pra comunicação entre sistemas, por exemplo, o backend do ecommerce conversar com meios de pagamento ou logística. Ou mesmo pra comunicação entre micro-serviços dentro da mesma empresa, é um dos protocolos mais porcaria que existem.

Como um exemplo bem, mas bem tosco, imagine este pequeno JSON de um produto de ecommerce. Quem já trabalhou com ecommerce sabe que é bem maior que isso, mas pra ilustrar aqui no video é suficiente:

{
  "product_id": "PS5-001",
  "name": "PlayStation 5",
  "description": "The PlayStation 5 is the next generation of gaming consoles, with advanced graphics, haptic feedback, and lightning-fast load times.",
  "price": 499.99,
  "availability": true,
  "images": [
    {
      "url": "https://example.com/images/ps5-001-front.jpg",
      "type": "front"
    },
    {
      "url": "https://example.com/images/ps5-001-back.jpg",
      "type": "back"
    }
  ]
}

JSON é um protocolo texto, onde o schema vai embutido junto com cada registro. Como falei, isso facilita pra pessoas comuns conseguirem ler sem muita dificuldade. Agora imagine um schema de Protobuf assim:

message Product {
  string product_id = 1;
  string name = 2;
  string description = 3;
  float price = 4;
  bool availability = 5;
  repeated Image images = 6;
}

message Image {
  string url = 1;
  string type = 2;
}

Note, ele define exatamente que tipo de dados, portanto qual o tamanho exato, de cada campo de dados. Dessa forma não preciso de coisas como aspas, vírgulas, nada disso, posso concatenar um valor atrás do outro, porque o tamanho vai ser fixo. No final, o mesmo JSON, convertido em Protobuf vai gerar um linguição binário que, em hexadecimal, seria assim:

0a 07 50 53 35 2d 30 30 31 12 10 50 6c 61 79 53 74 61 74 69 6f 6e 20 35 1a 42 54 68 65 20 50 6c 61 79 53 74 61 74 69 6f 6e 20 35 20 69 73 20 74 68 65 20 6e 65 78 74 20 67 65 6e 65 72 61 74 69 6f 6e 20 6f 66 20 67 61 6d 69 6e 67 20 63 6f 6e 73 6f 6c 65 73 2c 20 77 69 74 68 20 61 64 76 61 6e 63 65 64 20 67 72 61 70 68 69 63 73 2c 20 68 61 70 74 69 63 20 66 65 65 64 62 61 63 6b 2c 20 61 6e 64 20 6c 69 67 68 74 6e 69 6e 67 2d 66 61 73 74 20 6c 6f 61 64 20 74 69 6d 65 73 2e 20 32 25 15 01 20 f3 26 9d 3a 40 28 01 32 2b 0a 1f 68 74 74 70 73 3a 2f 2f 65 78 61 6d 70 6c 65 2e 63 6f 6d 2f 69 6d 61 67 65 73 2f 70 73 35 2d 30 30 31 2d 66 72 6f 6e 74 2e 6a 70 67 22 04 66 72 6f 6e 74

É isso que a nova API com Protobuf vai cuspir. Como disse antes, ao contrário do JSON, esse formato é 100% hostil pra um ser humano conseguir ler, porém, é 100% perfeito pra um computador ler. A fase de converter o JSON numa estrutura de dados é muito mais simples. Um protobuf é muito próximo de uma struct de C, só que mais genérico pra funcionar em qualquer linguagem. O JSON do exemplo é um string que pesa quase 200 bytes. Já esse linguição, que contém exatamente os mesmos dados, pesa menos de 80 bytes. Mesmo nesse exemplo super tosco, estamos falando de uma economia de 2.5 vezes na transferência de rede, sem contar a economia de processamento.

Lembra que falei que o Twitter lida com milhões de tweets todo dia? Imagine se internamente, em todo sistema, de pesquisa, banco de dados distribuído, sistema de recomendação, filas de processamento, ficasse trafegando tudo em JSON. Terabytes e terabytes de banda sendo desperdiçados. Por isso o Twitter adotou o equivalente a Protobufs do Google, o Thrift do Facebook. Thrift e Protobuf é quase a mesma coisa.

A única pergunta que você poderia ter é: por que o Twitter não usou o Protobuf do Google então? Em vez de reinventar a roda? De fato, Protobufs foram criados antes, sendo usados dentro do Google desde pelo menos 2001, mas só foi lançado publicamente em 2008. Nesse meio tempo surgiu o Facebook, que teve problemas similares pra resolver e inventaram o Thrift, que lançaram em Abril de 2007. Por isso o Twitter só tinha a opção do Thrift em 2007. Mas pra novos projetos, especialmente que interagem com componentes como PyTorch ou Tensorflow, que também veio do Google, eles passaram a usar Protobufs e você vai achar os dois no código.

Thrift e Protobufs são protocolos de serialização de dados. Esse tipo de protocolo é ideal pra comunicação entre micro-serviços. Só que diferente de JSON ou XML, a forma de fazer essa comunicação não é via HTTP, como num web service, e sim via RPC ou Remote Procedure Call, que formaliza como um serviço chama uma função, ou procedure, de outro serviço. No caso do Google eles tem o gRPC que é um framework de RPC que tem como objetivo prover comunicação eficiente e escalável entre serviços na rede.

Twitter não usou gRPC. Finagle é o equivalente de gRPC feito pelo Twitter, que usa Thrift pra serialização de dados em vez de Protobufs. Tem os mesmos objetivos de lidar com comunicação de alto throughput, baixa latência, na rede. Finagle é implementado em cima de Netty também, usando muita funcionalidade de programação assíncrona com Futures de Scala, que é o equivalente Promises de Javascript de hoje. E novamente, o Twitter Finagle foi lançado em 2011, o gRPC do Google só sairia por volta de 2015. O Twitter estava tendo que inventar tecnologias que não existiam ainda, por isso é um case fascinante.

Mas claro, Google sendo um nome muito maior e mais reconhecido que Twitter, matou os projetos Thrift e Finagle. Num projeto moderno, você deveria escolher Protobufs e gRPC ou alternativas mais modernas. Hoje, o Thrift ainda existe como Apache Thrift mas da Apache temos outras alternativas como Apache Avro, que foi criado mais pro cenário de streaming de dados serializados. Ou seja, quando você abre um streaming de um serviço pra outro serviço e trafega registros serializados com Avro entre eles.

Apache é um nome muito reconhecido pra quem é de Java e também no espaço de data sciences e machine learning. Quem lida com Kafka e é de Java, deve ter usado Avro como opção de serialização pra jobs em vez de Protobufs ou JSON. JSON é mais pra linguagens menores, como Javascript ou mesmo Ruby e PHP. Protobufs são mais usados em soluções que envolvam tecnologias do Google, como em Android. De qualquer forma, vale a pena estudar todas. Não ache que o mundo acaba em JSON ou XML. Tem coisa muito melhor e muito mais eficiente que é usado por sistemas realmente de grande volume. Pro ecommerce da esquina, de fato, tanto faz.

Falando em Java, acho que vale a pena eu relembrar a parte inicial dessa história. O que aconteceu justamente entre 2007 a 2010. Essa era a época que eu era mais participativo na comunidade Ruby on Rails e, claro, Twitter era um dos exemplos de maior sucesso de Rails. Mas aí veio a notícia bombástica: o Twitter declarou que estava migrando de Ruby pra Scala. E daí veio o meme que não morre de “Rails não escala”.

A forma como o Alex Payne, um dos principais desenvolvedores do Twitter descreveu, ou melhor, não descreveu os problemas que estavam enfrentando, tudo que eu expliquei até aqui, causou má interpretação e muita gente falando muita merda. Eu conversei com outro dos principais desenvolvedores daquela época, Blaine Cook, em junho de 2008. E mesma naquela época, eu também não tinha uma visão completa dos acontecimentos. Depois leiam a entrevista original que está no meu blog.

Por exemplo, da forma como Alex Payne falou, deu impressão que ele estava dizendo que Ruby on Rails não suportava conectar com múltiplos bancos de dados, o que não era verdade. Sim, não havia uma chavinha fácil, mas era basicamente uma linha extra que precisava ser colocada na classe pai de todos os ActiveRecords e dava pra selecionar onde fazer a conexão. Eu e vários outros escrevemos tutoriais de como fazer isso.

Mas a verdade é que o problema não era esse. Ninguém de fora do Twitter tinha muita noção do volume de dados que eles estavam tendo que lidar. E isso era 2007. Lembrem-se, a Amazon AWS tinha lançado não fazia um ano. Produtos que hoje são arroz com feijão, como SQS, DynamoDB, Route53 nem tinham sido lançados ainda. Firebase ainda não existia. Porra, coisas como Redis ainda não tinha sido inventado. GitHub ainda não tinha sido inventado.

A verdade é que particionar dados, organizar um MySQL em shards, e conseguir fazer uma arquitetura coesa em cima disso, não era trivial, e o Twitter estava numa fase de crescimento rápido. Não é que Ruby on Rails não escalava pra escala do Twitter. Nada em Python escalaria. Nada em PHP escalaria. Node.js ainda não tinha sido inventado também, mas também não escalaria. Entenda, havia poucas opções.

Possivelmente a opção mais completa teria sido começar a implementar um banco de dados de grafos em cima de Erlang, algo inspirado no banco de dados Mnesia que vem no OTP de Erlang. Porém, já viram Erlang? Hoje ele ainda é pouco usado, e em 2007 menos ainda. É verdade que grandes sistemas de telecomunicações já usavam fazia anos, mas era um salto bem grande pra uma tech startup tomar.

Quais as alternativas? Eles precisavam de uma linguagem pra escrever componentes como sistemas de filas, coisas no nível de Kafka, lembrando que Kafka só seria lançado em 2011. Coisas no nível de Cassandra, que também só seria liberado publicamente pelo Facebook em 2008. Neo4J talvez fosse o componente mais próximo de se encaixar nos problemas do Twitter, mas era super novo, tinha sido lançado em 2007.

Entendem? Imagine você sendo um desenvolvedor do Twitter, vendo milhares, centenas de milhares de tweets sendo postados todos os dias, e tendo que lidar com grafos de usuários e tweets, sendo que algoritmos de grafos nunca tinham sido testados com volumes desse tipo. Numa época onde toda tecnologia de Cloud e NoSQL e Devops ainda não tinha sido inventado, onde linguagens mais comuns como Ruby, Python, PHP, Javascript, não estavam ajudando e programar em C++ ou Java, parecia ser um passo pra trás.

Elixir não tinha sido inventado ainda. Go não tinha sido lançado ainda. Rust não tinha sido inventado ainda. LLVM ainda era uma grande novidade, já que a Apple tava só começando a mover suas ferramentas e linguagens de GCC pra Clang, como conto no episódio da Apple e GPL. Mas havia uma única linguagem que talvez pudesse fazer sentido, a linguagem Scala, que tinha sido lançado já em 2001, pelo visionário Martin Odersky.

Odersky é um desses gênios incompreendidos, tanto que tirando povo da área de Java, duvido que qualquer um aqui já tenha ouvido falar dele. Mas deveriam. O cara é Ph.D de ciência da computação pela ETH de Zurique e trabalhou sob a supervisão de ninguém menos que Niklaus Wirth, o inventor de várias linguagens como Modula-2 e Pascal, e o autor do livro de estruturas de dados e algoritmos que eu usei na faculdade.

Odersky participou e fez contribuições no mundo Java desde a versão 1.1, tendo trabalhado no compilador, na implementação de Generics, e algumas linguagens experimentais como a Pizza e Funnel, que influenciaram o design do Java.

Muito antes de programação funcional ficar hypezinho de hipster sem graça, como é hoje, no começo do século, ele já vislumbrava uma linguagens que destilasse o melhor da orientação a objetos, como usar traits, que são como protocolos de Objective-C, em vez de herança excessiva, mesclado com conceitos de programação funcional. Scala já tinha higher order functions, já usava tipo Opcional, evitando os famosos NullPointerException, pattern matching e tudo que se vê em linguagens mais modernas de hoje.

Então era de fato a linguagem mais moderna que se podia escolher em 2007, mas rodando em cima da JVM, que era a virtual machine mais madura que existia. Dava pra criar aplicações que só seriam possíveis em C++ com uma fração da dor de cabeça. Pra isso custaria um pouco mais caro em uso de recursos do que se fosse puramente nativo, mas a JVM naquele ponto oferecia um ecossistema que ninguém mais tinha.

E o objetivo do uso de Scala não era pra fazer front-end-zinho, era pra fazer os diversos componentes que eu expliquei que ainda não existiam. Começou com o projeto open source Starling, que é mais ou menos um mini Kafka, alguns anos antes do Kafka. Inventaram o RealGraph e GraphJet antes de um banco de dados de grafos maduro existir. Utilizaram coisas como Hadoop, que também faz parte do ecossistema Java. Nada disso seria possível sem ser, ou em Java ou em C++.

Hoje em dia eles teriam muito mais opções, como o próprio Elixir, Go ou Rust, e se quisessem arriscar em linguagens mais exóticas teriam D, Nim, Zig, talvez Swift, Kotlin. Mas de novo, era 2006 pra 2007 e o relógio tava correndo. Em retrospecto, foi uma decisão muito acertada. E é por isso que o código que foi liberado é 2 terços Scala e Java. Muito das pesquisas que o Twitter fez, junto com trabalhos do Facebook, Google, Apple, Amazon, gerou o atual ecossistema de linguagens, ferramentas e plataformas pra lidar com Big Data, Data Science, Machine Learning, culminando com Deep Learning e a atual geração de inteligência artificial que todo mundo tá babando. Mas foi assim que as coisas começaram, no início do século.

Agora que temos uma noção melhor do contexto histórico, dos projetos e papers de pesquisa gerados, podemos começar a entender melhor o código liberado. Esse código é um conjunto de diversos sub-projetos. Se abrirmos o primeiro README na raíz do repositório, eles descreveram o que são cada um desses projetos. Por exemplo, SimClusters-ann é o serviço que retorna candidatos de recomendações de tweets dado embeddings de um cluster de similaridade.

Esse serviço usa o algoritmo de similaridade aproximado de cossenos. Já vou explicar isso. Segundo o README, um job constrói o mapeamento entre SimClusters e Tweets. O job grava os top 400 tweets de um SimCluster e os top 100 SimClusters pra um tweet. Pontuação de favoritos e pontuação de seguidores são dois tipos de pontuação que um tweet pode ter. Os top 100 SimClusters baseados nessas pontuações é que chamam de Tweet SimCluster Embedding.

A similaridade de cosseno entre dois Embeddings apresenta o nível de relevância de dois tweets num espaço de SimClusters. A pontuação varia de 0 a 1. A alta pontuação de similaridade de cosseno, maior que 0.7 significa que os usuários que gostam de dois desses tweets compartilham os mesmos SimClusters.

Similaridade de cosseno é um conceito de Álgebra Linear pra medir quão similar são dois vetores em termos de direção e magnitude. Eu gosto desse conceito porque expliquei isso desde pelo menos 2015 até minha última palestra pública em 2019. Quem assistiu minha palestra “Restrição == Inovação” vai se lembrar disso, e vou aproveitar pra usar os slides que eu usava nessa palestra.

Comece visualizando a página inicial do Google, o campo onde se digita palavras-chaves. Podemos digitar “apple” e recebemos páginas indexadas da web que tem essa palavra. Um amador que acabou de aprender SQL poderia pensar que é alguma coisa parecido com “select urls from pages where text like ‘%apple%’”.

Essa é a solução que faríamos no começo dos anos 90, antes de Larry Page e Sergey Brin inventarem PageRank, antes de Jon Kleinberg inventar HITS. Essa linha de SQL de fato vai achar todas as páginas onde aparece a palavra “apple”, mas não vai saber como ordenar: qual delas é mais relevante e deveria estar no topo da lista? Pra saber relevância, precisamos de Álgebra Linear.

Tudo depende de como você enxerga o que é uma página web. Todo mundo enxerga um documento, uma coleção de palavras, que é o texto desse documento. Digamos que nosso banco de dados só tem 3 documentos indexados, como neste slide. Pra simplificar bastante, vamos assumir que nosso vocabulário é bem limitado e os documentos só tem as palavras apple e banana. O documento 1 tem 4 apples e 1 banana, documento 2 tem 3 bananas e 1 apple, e documento 3 tem 5 bananas e nenhum apple.

Podemos representar esses documentos como vetores, como neste slide. Próximo passo, criamos um índice, que é uma lista que diz em quais documentos aparece a palavra apple e quais aparece banana. Pense em algo como o índice do seu banco de dados MySQL ou Postgres ou SQL Server da vida. Agora vamos digitar a palavra “apple” no campo de pesquisa desse nosso Google de mentira.

O truque começa em representar essa pesquisa, essa query, também com um vetor. No caso apple sendo 1 e banana sendo 0. É como se fosse um documento também. Pelo índice, podemos descartar o documento 3, já que apple não aparece nenhuma vez. Mas ainda temos o documento 1 e o documento 2. Qual deles é o mais relevante pra aparecer no topo da lista? De bater o olho sabemos que é o documento 1, porque aparecem a palavra apple 4 vezes, e no documento 2 só aparece 1 vez. Mas como um algoritmo conseguiria computar isso?

Pra isso desenhamos esses vetores num espaço vetorial, um Vector Space. No caso só temos duas dimensões, porque só temos duas palavras no nosso vocabulário. Apple é o eixo X e banana é o eixo Y. Então o vetor que representa o documento 1 seria assim: 4 unidades pra direita no eixo X, e 1 unidade pra cima no eixo Y. Já o documento dois seria só 1 unidade pra direita no eixo X mas 3 unidades pra cima no eixo Y. Finalmente o vetor da query é só uma unidade pra direita no eixo X, só 1 palavra apple, entenderam?

O lance com vetores é que agora temos ângulos entre o vetor de pesquisa e os vetores de documentos. E pra calcular a similaridade de cosseno usamos dot product, que é produto escalar. Funciona assim: vamos multiplicar apple com apple, banana com banana e somar os dois. Então vetor de pesquisa é 1 e 0, 1 apple e 0 bananas e vetor do documento 1 é 4 apples e 1 banana então a conta seria 1 vezes 4 mais 0 vezes 1, que dá 4, esse é o produto escalar.

Daí fazemos a mesma coisa entre vetor de pesquisa, de novo, e o vetor do documento 2, então o produto escalar vai ser, 1 apple vezes 1 apple mais 0 banana vezes 4 bananas, dando 1. Como o produto escalar 4 do documento 1 é maior que o 1 do documento 2, sabemos que o documento 1 tem mais similaridade com a pesquisa e, portanto, é o mais relevante pra aparecer no topo da lista.

Esse exemplo é super trivial porque só usamos duas palavras, então temos só duas dimensões. Mas vamos complicar. E se tivéssemos um novo documento indexado que tenha a palavra coco? O vetor dele poderia ser 1 apple, 0 banana e 2 cocos. Todos os outros vetores precisam ser atualizados pra conter coco, mas no caso tem 0 cocos então não muda nada. Pra representar o espaço vetorial, precisamos de uma nova dimensão Z. O vetor desse novo documento seria desenhado com 1 unidade pra direita no eixo X e 2 unidades pra baixo no eixo Z.

E podemos calcular o produto escalar entre a pesquisa e esse novo documento também. Em geometria, a gente consegue desenhar no papel até 3 dimensões, mas claro, o vocabulário de uma língua como português é muito mais que só 3 palavras. Num dicionário como o Aurélio, vai ter mais de 500 mil palavras. Portanto podemos ter potencialmente 500 mil dimensões nesse espaço vetorial. Na realidade vai ser a quantidade de palavras únicas que tem num documento, ou página web de verdade. O script deste episódio, por exemplo, tem mais de 3 mil palavras únicas. É um vetor de 3 mil dimensões.

Felizmente, produto escalar é uma operação muito rápida de se calcular em qualquer computador moderno, só somas e multiplicações simples. E é assim que funciona a base de todo tipo de algoritmo de relevância e recomendação. É isso que tem por baixo da biblioteca Apache Lucene que falei antes. E se olhar a documentação de um Elastic vai ver que menciona VSM, ou Vector Space Model, que é esse gráfico que vim mostrando, muito maior do que os 3 do exemplo. E é isso que esse projeto SimClusters vai fazer, só que com vetores de usuários e tweets.

No caso do Twitter, esse primeiro projeto se chama SimCluster-ANN. SimCluster é similarity cluster, e esse “ANN” provavelmente significa “Approximate Nearest Neighbor” ou vizinho mais próximo aproximado. Em machine learning e data mining, pesquisa de vizinho mais próximo é o problema de encontrar o ponto de dado mais próximo em um espaço de muitas dimensões, dado um certo ponto de pesquisa, onde soluções exatas são inviáveis pelo tamanho do conjunto de dados.

Algoritmos de vizinho próximo aproximado, como Locality-sensitive hashing ou LSH e métodos baseados em árvore como KD-trees, oferecem uma forma eficiente de resolver esse problema fazendo um trade off de algum grau de precisão por uma melhoria significativa em performance. Então é mais uma otimização do Twitter pra ganhar performance, mais ou menos como o random walk no algoritmo de SALSA que expliquei antes.

Nesse sub-projeto, o conceito importante são embedding spaces, que tem como objetivo responder a pergunta “quais tweets e usuários são similares aos meus interesses?”. Embedding funciona gerando representações numéricas dos interesses dos usuários e conteúdo de tweets. Daí podemos calcular a similaridade entre quaisquer dois usuários, tweets ou pares de usuários e tweets num espaço de embedding.

Justamente um dos espaços de embeddings mais úteis do Twitter são os SimClusters. SimClusters descobrem comunidades ancoradas por um grupo de usuários influentes usando um algoritmo customizado de factorização de matrizes. Existem umas 145 mil comunidades, que são atualizadas a cada três semanas. Usuários e tweets são representados em espaço de comunidades e podem pertencer a múltiplas comunidades. Elas podem ter algumas milhares até milhões de usuários. Segundo o blog de engenharia, essa imagem representa algumas das maiores comunidades.

Sem entrar em muito mais detalhes, vamos bater o olho em alguns outros projetos descritos naquele arquivo README. Veja um aqui chamado “real-graph”. Eu falei de RealGraph antes. Veja este “Tweepcred”, que é o algoritmo de PageRank pra calcular reputação dos usuários. Temos esse “recos-injector” que é descrito como um processador de eventos em streaming pra construir os streams de entrada pra serviços baseados em GraphJet. Já sabemos o que é GraphJet, mas “recos” eu acho que significa “recomendações”, então é um injetor de recomendações pra GraphJet.

Pulando lá pra baixo temos esse “light-ranker” que é um ranqueador mais leve usado pelo índice de pesquisa, o tal Earlybird que mencionei antes, que é um projeto legado e parece que ainda é usado; o componente construído em cima de Apache Lucene. O heavy-ranker está no outro repositório “the-algorithm-ml”, que o blog post do Steven, que falei lá no começo, menciona e segundo o README é o responsável pela aba “Pra você” e tem aquela lista de pesos.

Nesse ponto da cadeia, depois da fase de candidate sourcing, temos uns 1500 candidatos que podem ser relevantes. Pontuação serve pra prever a relevância de cada tweet candidato e é o sinal primário pra ranquear tweets na timeline. Nesse estágio, todos os candidatos são tratados igualmente. O ranqueamento sai de um rede neural de uns 48 milhões de parâmetros que é continuamente treinada com interações de tweets pra otimizar o engajamento positivo (como likes, replies e retweets), segundo o blog de engenharia do Twitter.

Sendo bem honesto, eu não tenho certeza de como exatamente isso funciona ainda. Olha o diagrama que tem no próprio arquivo README que lista os projetos. Os dados vem dessas caixinhas intituladas “Grafo Social”, “engajamento de tweets” e “dados dos usuários”. Daí temos features, como o GraphJet, SimClusters, TwHIN que é outro projeto no repositório the-algorithm-ml, e serve pra pré-treinar os tais embeddings.

Daí temos o RealGraph, TweepCred e Trust & Safety, que parece ser um projeto de tensorflow pra treinar modelos pra filtrar coisas como conteúdo pornográfico, adulto, ou o que ele considera como “tóxico”. Não sabemos exatamente porque não foi liberado o modelo e nem os dados de treino. É um projeto bem pequeno e quem entende de Tensorflow poderia dizer um pouco mais, mas não tem muito pra se ver.

Continuando, temos essa coluna que ele chama de Home Mixer. Daí temos 3 fases: uma que ele chama de candidate sourcing, que é literalmente “escolher os candidatos”, candidatos de recomendação. Esses candidatos passam pelo tal heavy ranker, que parece ser o modelo de machine learning via PyTorch. O resultado disso passa pra etapa final de heurísticas e filtros.

Então, pra se chegar nos tweets recomendados na aba “Pra você”, na etapa de sourcing já acontece diversos filtros pra selecionar os candidatos de tweets que você pode gostar de ver. Esses “filtros” passam pelos projetos de SimCluster, RealGraph, T&S, Tweepcred, os GraphJets e são mesclados pelo projeto cr_mixer. Isso vale comentar. Os tweets recomendados, mais ou menos, são metade de tweets gerados pelas pessoas que você segue, o que ele chama de “In-Network” e a outra metade é de tweets de pessoas que você não segue, que ele chama de “Out-of-Network” e quem puxa isso é esse projeto cr-mixer.

Dado esse conjunto inicial de tweets, In e Out of network, aí vem a parte de recomendação propriamente dito usando o light ranker, o projeto Earlybird, e daí o heavy ranker. Mas antes de mandar pra você, ainda passa por um pipeline de filtros. Pelo projeto home mixer propriamente dito, esse visibility-filters que é onde está implementado a política de censura do Twitter.

Por último, tem esse projeto Navi, que parece mais recente, escrito em Rust, mas é super pequeno e não faz muita coisa. Parece mais um adaptador pra falar com os componentes de Tensorflow e PyTorch e um tal de Onnx, que eu não conhecia, mas parece que significa Open Neural Network Exchange, que é um formato open source pra representar modelos de machine learning. Foi originalmente desenvolvido pela Microsoft e Facebook em 2017 pra facilitar interoperabilidade entre diferentes frameworks de deep learning, por exemplo, entre PyTorch e Tensorflow. Mas realmente não sei como ele é usado neste projeto ainda.

Se tiverem interesse em saber mais, cada um desses sub-projetos tem um README também, então recomendo que comecem por eles. Mas como disse no começo, se tentar rodar bazel build em qualquer diretório, ele vai reclamar da falta de um arquivo de Workspace. Então, até o Twitter liberar isso, ou alguém se dar o trabalho de gerar na mão, não temos como compilar e nem de tentar rodar nada.

Por isso que é meio chato, porque mesmo lendo essas coisas todas na documentação e no próprio código, não temos como testar. Basta um if que a passamos batido e talvez algum desses componentes nem rodem. É muito difícil saber o comportamento exato dum sistema grande desses sem ter uma massa de dados de entrada pra ver o que realmente é cuspido na saída.

De qualquer forma, do ponto de vista de organização, além da falta de arquivos pra fazer build, também senti muita falta de arquivos de testes automatizados. Não tem como saber se eles tiraram antes de abrir em público, se ainda vai ser liberado, ou se realmente não existem. Espero que existam, porque dar manutenção num sistema grande desses, sem testes, seria uma grande burrice.

Se eles tivessem liberado os arquivos de testes, nós teríamos uma idéia muito melhor de como esse sistema de comporta, mesmo sem poder compilar e rodar. Testes servem como se fosse uma documentação viva de um sistema. Teria sido muito mais fácil confirmar tudo que analisamos.

Mas no geral, minha opinião é que o código Scala parece muito bem feito, dado o contexto que se trata de um legado de mais de 10 anos. Eu esperaria algo muito mais bagunçado, muito mais macarrônico. Comparado com o código do Twitch, que eu analisei em outro video quando foi vazado, eu preferiria muito mais trabalhar neste código do que no outro.

O básico tá bem feito: métodos curtos, baixa complexidade ciclomática, nomenclatura bem feita, nada de variáveis “x” ou “y” que não dá pra saber do que se trata. Pouca coisa hard-coded, tudo organizado em arquivos de configuração, e até que bem comentados onde precisa. Não é comum ver projetos legados com esse nível de qualidade. Não é nem de longe perfeito, mas até que me surpreendeu.

Obviamente, esse repositório é só um espelho incompleto do repositório de verdade, que permanece fechado dentro do Twitter, sob confidencialidade. O código que foi liberado também não pode ser usado por nenhum projeto fechado sem liberar as modificações feitas em cima desse código. É isso que a licença AGPL que eles colocaram significa: eles não querem que ninguém adicione em outro projeto e mantenha fechado.

Depois que soltaram esse código, um bando de imbecis ficou spamando a seção de Issues, mas teve um ou outro pull request que eles aprovaram já, nada significativo. Só a remoção daquele código de métrica que tinha o “author_is_elon” que imbecis adoraram ficar fazendo meme. Não teve nenhuma contribuição significativa ainda e nem espero que vá ter, até que eles liberem os arquivos de Workspace do Bazel.

Eu não tenho muito senso de humor pra memes idiotas e gente que acha bacana ficar pichando uma seção que deveria ser séria como a área de Issues. Quer fazer meme idiota, fica no Reddit ou no 4chan. Não tem o mínimo de etiqueta, não participa. Participação desse tipo é só idiota, não tem nenhum valor e não contribui com absolutamente nada. É só certificado de idiota mesmo.

Ao longo de mais de 10 anos, o Twitter fez sua parte e contribuiu tecnicamente. Os papers que falei, os projetos open source, os diversos blog posts de engenharia, inspiraram muitos outros projetos a tentar arquiteturas e tecnologias que, na época, sequer existiam ou se existiam, ninguém sabia se funcionava. Independente da sua opinião política, que é irrelevante, o Twitter certamente contribuiu ordens de grandeza mais do que qualquer um dos engraçadinhos que não sabem respeitar um trabalho de engenharia.

Ter acesso a esse código não me torna mais fã do Elon Musk, mas só serve pra confirmar muitas coisas que eu já sabia sobre os primeiros engenheiros do Twitter: eles foram muito bons, especialmente pra época. E pra vocês que são iniciantes, aproveitem a oportunidade pra fuçar tanto o código quanto os papers que eu citei. É assim que um produto em produção evolui. Só nesse sistema de recomendações, vimos 3 gerações diferentes de soluções, cada uma gerando mais experiência pra fazer o próximo ser melhor. Código de produção de verdade, de um produto que tem uso, nunca acaba.

Você que é empreendedor querendo entender mais de programação, entenda: se seu código não está evoluindo, é porque seu produto é irrelevante. O Twitter existe desde 2006, e o código nunca chegou numa versão que todo mundo tirou a mão e falou “tá perfeito, não precisa mexer mais”. O mesmo acontece com qualquer produto, ecommerce, elearning, fintech, todos continuam evoluindo, pivotando, ajustando e consertando pra ficar cada vez melhor. O Twitter de hoje é bem diferente do Twitter de 2007, mesmo que só pelo front-end não pareça que tenha mudado muita coisa. A cara não muda tanto quanto o backend.

Dá pra ficar literalmente dias, indo de arquivo em arquivo, tentando desvendar quem chama quem, quem depende de quem, em que momentos, quais serviços rodam pra quais tipos de dados. Mas é super trabalhoso fazer isso sem conseguir rodar nada e sem testes. Eu não acho que vale a pena, mas na internet sempre tem alguém com mais boa vontade de fazer trabalho chato como esse. Com apenas 2 dias olhando pra esse código, eu só consigo descrever até aqui.

E com tudo isso, pelo menos espero que pra vocês que sejam iniciantes, tenham tido uma perspectiva diferente do que imaginavam que seria um código de verdade de produção. Mesmo sem entender nada, deve dar pra começar a entender melhor a dimensão. Repetindo: esse repositório liberado só tem parte do código do sistema de recomendação. Não tem o front-end web, não tem o app mobile, não tem as ferramentas de administração, não tem o ferramental de monitoramento, enfim, só estamos vendo uma fração do que é feito o Twitter.

Antes de terminar, enquanto estava escrevendo este episódio, o canal Fireship lançou também um video curto falando disso. Não tem nada demais, mas eles lançaram um segundo especialmente sobre “Vector databases”. Só assistindo esse video dele, duvido quem a maioria tenha entendido. Eu expliquei o que é isso durante este video, e se você já não tinha conhecimento prévio de Álgebra Linear, provavelmente entendeu mas não compreendeu.

Enfim, o Fireship menciona bancos de dados modernos de vetores como Pinecone e Weaviate e disse que vai fazer um curso sobre isso. Não sei se foi piada, como eles sempre fazem, ou se vão mesmo, mas vou ficar de olho pra saber. Problema de um curso desses é o famoso “olha como se faz um hello world, é super simples”, mas sem entender tudo que falei hoje, você vai usar sem entender. Mas assistam lá depois. Vou deixar o link na descrição abaixo.

E finalmente, isso responde outra pergunta que todo mundo tem: precisa saber matemática pra ser programador? E a resposta é não. Pra fazer coisa simples, sabendo matemática básica de regra de três e porcentagem, dá pra ir se virando. No dia a dia de software pequeno, se souber pelo menos usar uma calculadora, já funciona. Agora, sem saber Álgebra Linear, Cálculo, Estatística e Probabilidade, você nunca vai trabalhar em projetos como esse do Twitter, é uma impossibilidade. Matemática é opcional, inglês é opcional, tudo depende de quão pouco você quer ter de opções. Se ficaram com dúvidas, mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais.

Finalmente vou pagar promessa. Este é o video sobre containers e Docker que venho falando faz vários videos atrás, que ia fazer. Mas eu precisava explicar a instalação, como Linux boota, como funciona virtualização, pra finalmente chegar em containers. Então este episódio vai amarrar tudo que vocês aprenderam nos videos de Linux, de armazenamento, etc e finalmente vão entender containers do jeito certo.

Erratas

5:12 - tá errado, isso é em outros comandos, como top eu acho, que mostraria 400% se tivesse usando 4 CPU. Do jeito que eu falei ficou parecendo que naquele quadrado vermelho mostraria isso, mas ali é POR cpu/thread, por isso vai só até 100%. Só em linhas de comando que mostra num número só quanto que tá se usando que apareceria, por exemplo, 400%.

Conteúdo

• 00:00 - Intro: qual a diferença de VMs e Containers?
• 01:49 - CAP 1 - Limitando Processos - cgroups
• 07:43 - CAP 2 - Enganando Processos - namespaces
• 14:45 - CAP 3 - Recapitulando Containers - LXC, Docker, OCI
• 17:34 - CAP 4 - A Base de Containers - RunC
• 22:29 - CAP 5 - Hello World de Docker - O que tem dentro?
• 33:20 - CAP 6 - Restringindo Processos Ainda Mais - Capabilities
• 37:18 - CAP 7 - Orquestrando Containers - Docker Compose
• 41:26 - CAP 8 - Bônus do Episódio “Tornando sua App Web mais Rápida” - Load Balancer com Docker
• 43:25 - CAP 9 - Orquestra de Gente Grande - K8S e Terraform
• 47:17 - CAP 10 - Outros Usos de Containers - Apps em Containers?
• 51:28 - Bloopers

Links

• https://github.com/akitaonrails/episode0139
• https://www.zsiegel.com/2022/01/17/load-balancing-in-docker-with-nginx
• https://www.mo4tech.com/unshare-command-details-and-examples.html
• https://ericchiang.github.io/post/containers-from-scratch/
• https://wiki.archlinux.org/title/cgroups
• https://nodejs.org/en/docs/guides/nodejs-docker-webapp/
• https://docs.docker.com/compose/gettingstarted/
• https://flast101.github.io/docker-privesc/
• https://blog.alexellis.io/runc-in-30-seconds/
• https://man7.org/linux/man-pages/man7/capabilities.7.html
• https://blog.container-solutions.com/linux-capabilities-in-practice
• https://github.com/containers/bubblewrap

SCRIPT

Olá pessoal, Fabio Akita

O penúltimo video sobre o setup do meu PC foi pesado em configuração mas se conseguiu chegar até o fim, deve ter entendido um pouco mais sobre como virtualização funciona, em particular usando o emulador QEMU acelerado com KVM. Aquilo é virtualização: criar uma máquina virtual que roda outro sistema operacional, outra kernel, por cima.

Hora de pagar a promessa que vim fazendo em diversos videos. Finalmente falar um pouco sobre os tais “containers” que até hoje muita gente confunde com virtualização. As duas coisas “parece” que é rodar um programa dentro de uma máquina virtual. Mas containers são completamente diferentes de máquinas virtuais. Vamos lá.

(…)

Se fosse fazer um TLDR, uma única frase que resume a diferença, é até simples: uma máquina virtual roda um novo kernel, possivelmente numa outra arquitetura, como x86 em cima de ARM, já um container reaproveita o mesmo kernel, necessariamente na mesma arquitetura de hardware. É essa a diferença. Agora vamos ver na prática.

Vou começar falando só de containers de Linux. BSD, Windows, MacOS tem infraestrutura diferente pra containers. Windows tem como rodar container pra rodar apps de Windows. Isso é leve. Mas quando Windows ou MacOS precisam rodar apps de Linux, na prática o que acontece é que eles de fato sobem uma máquina virtual de Linux primeiro, como o WSL que já fiz dois videos a respeito. Portanto envolve sim virtualização. E é dentro dessa máquina que um Docker Desktop cria containers de Linux. Só em Linux nativo que containers são realmente “leves”.

Em Linux precisamos entender dois componentes fundamentais: cgroups e namespaces. Cgroups já mencionei no episódio anterior quando mostrei como isolar threads da CPU só pra máquina virtual e só pro host. Cgroups ou control groups é um mecanismo da kernel pra agrupar processos e limitar recursos como cpu e memória.

Existem várias formas de listar cgroups. A mais simples acho que é só dar ls /sys/fs/cgroup. Lembra o script chamado “suspend” que fiz pra limitar AllowedCPUs pro host? Usei o systemd pra limitar esse parâmetro pros cgroups init.scope, system.slice e user.slice. Vejam na listagem que todos são diretórios. Se listar um deles, vem vários arquivos como “cpu.weight” ou “memory.pressure”. É como se parametriza os recursos pra esses cgroups.

É tudo organizado como uma árvore, pra variar olha só árvores de novo, onde um cgroup herda configurações de outro cgroup. Honestamente, não sei os detalhes de como é configurado cada um que já vem de cada distro e imagino que cada um configura essa árvore de formas um pouco diferente. Essa listagem é no meu Manjaro. Num Ubuntu é semelhante, tem a maioria dos mesmos slices.

Se listarmos o que tem em system.slice, tem novos subdiretórios, um pra cada daemon que o systemd inicia, e também cgroups pra cada um dos aplicativos instalados via Snap, que vou falar um pouco mais pra frente. Pra enxergamos isso melhor podemos rodar o comando systemctl status. Agora temos a hierarquia toda de cgroups. Como falei antes, olha aqui o system.slice e os sub-grupos de cada daemon. E mais pra baixo temos o user.slice onde os programas que estamos rodando como navegador, terminal e tudo mais ficam em seus próprios sub-grupos também. Todos os processos rodando estão organizados em cgroups. Você nem sabia disso, mas toda vez que executa um programa, ele vai estar atrelado a pelo menos um cgroup.

Lembra que quando usamos comandos com ps ou programas como htop eles pesquisam os metadados no sistema de arquivos virtual /proc? Por exemplo, vamos pegar o PID do meu navegador Edge. Tem vários processos, todo navegador separa cada aba num processo diferente pra isolar, ter mais segurança, e se uma aba crashear, não derrubar todas as outras junto. Podemos fazer cat /proc/PID/group e aqui vamos em qual sub-grupo de cgroup esse process está. No escopo do edge, dentro de app.slice, dentro de user service, dentro de user.slice.

Existem várias formas de controlar cgroups. Uma delas é usando o sistema de arquivos virtual disponível no diretório /sys/fs/cgroups. Isso é um ponto de montagem. Se fizermos mount | grep cgroup olha como aparece que o tipo do sistema de arquivos é “cgroup2”. É como se fosse um dispositivo virtual montado. Lembra que já expliquei nos episódios de Linux, como nos de Slackware, Gentoo e no que explico como funciona o boot, que existem diversos pontos de montagem especiais como “/proc” ou “/dev”?

Pra mostrar na prática pra que diabos saporra serve, deixa criar um script idiota em Ruby. Podia ser em Python, podia ser em Java, faça no que quiser. É só um loop infinito printando ponto pra sempre. Vamos rodar e em outro terminal abro o “htop”. Veja aqui no topo que meu script tá usando 100% de 1 CPU. Se eu tivesse feito suportar múltiplas threads, cada 100% seria uma CPU. Um programa que usa 4 threads inteiras ia aparecer aqui como 400%.

No topo do programa lista todas as threads independentes e veja que tem uma de 100% que é meu script. Mas se esperar um pouquinho vai ver que ele muda de lugar. Um programa não fica sempre fixo no mesmo thread. Pra isso serve o scheduler da kernel. Expliquei sobre scheduler no episódio de concorrência e paralelismo e é a razão de porque no episódio anterior tive o trabalho de mostrar como mandei a máquina virtual usar as threads de 16 a 31 e limitei o host a usar só de 8 a 15. Lembra deste script aqui usando systemd e configurando o parâmetro AllowedCPUs em todos os diretórios raíz de slices?

command=$2

if [ "$command" = "started" ]; then
    systemctl set-property --runtime -- system.slice AllowedCPUs=0-15
    systemctl set-property --runtime -- user.slice AllowedCPUs=0-15
    systemctl set-property --runtime -- init.scope AllowedCPUs=0-15
elif [ "$command" = "release" ]; then
    systemctl set-property --runtime -- system.slice AllowedCPUs=0-31
    systemctl set-property --runtime -- user.slice AllowedCPUs=0-31
    systemctl set-property --runtime -- init.scope AllowedCPUs=0-31
fi

Ctrl-C pra parar o loop infinito e agora podemos criar sub-diretórios e arquivos usando comandos normais como “mkdir”, “echo” ou podemos continuar usar o SystemD pra facilitar, que é o que vou fazer agora. Vou criar um slice pra mim chamado “akita.slice” em “/etc/systemd/system/akita.slice”. Só abrir com qualquer editor de textos usando “sudo” e no caso quero limitar o uso de CPU em só 30% pra processos neste cgroup. Pra isso coloco este conteúdo:

[Slice]
CPUQuota=30%

Posso configurar outros limites, como memória, mas pra esse exemplo, só isso já funciona. Agora vou abrir um shell dentro desse cgroup com este comando systemd-run --slice=akita.slice --uid=akitaonrails --shell e nessa linha de comando que abriu, vou repetir o mesmo comando ruby loop.rb.

Olha o htop. Tá vendo aqui no topo da lista? Antes o script consumia 100% de uma thread, mas como agora reiniciei a partir do meu novo cgroup,que só permiti usar 30% da CPU, a kernel obriga a usar no máximo 30% da CPU. E com isso conseguimos controlar granuladamente o que cada processo no sistema pode ou não consumir.

E por que eu iria querer limitar um programa forçado assim? No Wiki do site do ArchLinux tem um exemplo no fim. Ele menciona o Matlab, que é um programa de cálculo numérico e, dependendo da complexidade do cálculo, pode consumir toda a RAM e toda CPU do sistema. Se um programa usar todos os recursos, vai faltar CPU e RAM até pra kernel e o sistema inteiro vai ficar lento ou crashear. É um tipo de ataque de DoS. DoS ou Denial of Service é um programa saturar todos os recursos da máquina até tudo parar de funcionar. Mas se colocar o Matlab num cgroup onde limito CPU e RAM pra, digamos, deixar sobrar uns 10%, a kernel vai ter a possibilidade de tentar se corrigir.

Depois leia mais sobre cgroups no Wiki do Arch. Mas o importante foi pra explicar que existe esse recurso em todo Linux moderno. Agora vou pular pro segundo grande recurso pra limitar o que processos podem fazer, que se chama “Namespaces”. Quando listo o que tem em “/proc” consigo enxergar todos os PIDs de todos os processos rodando no sistema. Se rodar o comando “mount” consigo ver todos os pontos de montagem ativos no sistema. E existem comandos ou locais onde posso listar a stack de rede, IPC que é comunicação inter-processos, IDs de usuários e grupos.

Mas é possível esconder todos esses detalhes de um processo. Pra isso existe o comando unshare, literalmente “descompartilhar”. Num terminal normal, se executarmos o comando ps aux isso vai nos devolver uma lista com todos os processos ativos neste momento, e costuma ser uma lista grande num desktop normal. Vamos abrir um novo shell, mas fazendo sudo unshare --fork --pid --mount-proc /bin/bash. Parece nada demais né? Mas se executarmos ps aux olha só, cadê todos os meus processos? Sumiu? O bash agora tem PID 1.

É isso que se chama namespace, é um espaço separado de nomes, no caso de PIDs. Se abrir outro terminal e executar ps aux tá tudo aqui bonitinho e lá no final olha o comando unshare e a instância de bash rodando com um PID alto. A diferença é que o bash que acabamos de abrir não enxerga mais o mesmo “/proc” global. Ele tem um “/proc” local só pra ele, isolado e separado que começa do 1 de novo. De dentro daquele bash, vamos listar o que tem em “/proc”, só os dois PIDs que listou. No outro terminal normal se listar “/proc” tem todos os PIDs.

Entenderam? Namespace faz o processo puxar a informação de outro lugar. Estamos mentindo, mas ele continua executando no mesmo sistema, igual qualquer outro programa, tanto que tem um PID de verdade. Pra quem é de Javascript, uma analogia é a diferença de criar uma variável com o antigo “var” pra cair no escopo global da função ou usar “let” e manter a variável no escopo local do bloco, manja? Não é exatamente a mesma coisa, mas é parecido.

Com o recurso de namespaces podemos mentir pros processos pra não enxergar mais o resto do sistema do lado de fora e assim limitar o que podem fazer. Por padrão, todos os recursos do sistema operacional são globais, todo processo tem acesso a praticamente tudo que outro processo tem, salvo permissões de leitura e execução por usuário, que você tá mais acostumado a pensar, tipo, root tem acesso a tudo. Mas com unshare inclusive note que ele engana meu processo fazendo achar que é root. Se executarmos o comando id olha, sou o usuário zero.

Como executamos unshare com sudo, esse root tem o mesmo nível de privilégio do root de verdade, o que não é muito seguro. Vamos dar exit e executar a mesma linha de comando mas com a opção “–user” e pronto. Se executarmos “id” agora sou nobody, literalmente um zé ninguém. Mais útil vai ser rodar como root, só que não tendo acesso ao sistema de arquivos todo. Vamos consertar isso.

Se assistiu meus episódios de Linux, viu minha explicação sobre chroot. Um container de verdade não usa chroot, mas pra demonstração dos conceitos vai servir. Teve um palestrante que já demonstrou isso anos atrás e deixou alguns arquivos que vamos precisar. Vou deixar o link na descrição abaixo, vamos baixar o tarball “rootfs.tar.gz”.

wget https://github.com/ericchiang/containers-from-scratch/releases/download/v0.1.0/rootfs.tar.gz

Pronto, baixei lá no “/tmp” mesmo porque é só pra demonstração. Agora é só descomprimir com tar xvfz, esperar um segundo … e tá lá. Se listarmos o que tem, parece com a raíz do seu HD, não? É uma mini-distribuição do que chamamos de “userland”. Se listar o “rootfs/boot” não tem a kernel nem a initram que deveria. E o que fazemos com isso? É como na instalação do Gentoo, fazemos sudo chroot rootfs /bin/bash. Ele vai fazer “change root”, mudar a raíz, pra esse diretório rootfs e executar o bash dentro do sub-diretório “rootfs/bin” e não o meu de verdade.

ls dá pau agora. Isso porque esse shell não carregou perfil nenhum, então não tem nenhuma variável de ambiente configurado. Vamos exportar o path de novo com export PATH=/sbin:/bin:/usr/bin e agora sim temos acesso às ferramentas nesses diretórios. É assim que sua distro Linux faz, só que isso já vem configurado automático pra você, mas na mão é assim que fazemos.

Essa variável provavelmente está no seu arquivo “/etc/profile” ou .bashrc ou .zshrc da vida. Executando ls / parece que não aconteceu nada, mas faz ls /boot, viu? Vazio. Estamos dentro do diretório “rootfs” que está sendo mascarado pra gente como se fosse a nova raíz. Esse shell não tem mais acesso ao meu sistema de arquivos de verdade.

Agora tentamos executar ps e dá pau. Isso porque não existe nenhum mount de diretórios especiais, como o “/proc” que é onde comandos como “ps” pesquisam processos. Veja o erro, ele manda justamente dar mount nisso. Mas agora é que vamos juntar esse comando de chroot com o unshare. Então damos exit e executamos o comando sudo unshare -p -f --mount-proc=/tmp/rootfs/proc chroot rootfs /bin/bash

A opção “-p” é o jeito mais curto pra “–pid” e “-f” é pra “–fork”. Daí montamos o proc e damos chroot via unshare. Não podemos esquecer de exportar o PATH de novo. Pronto. Se fizermos ls /boot tá vazio. Se fizermos ls /home, tá vazio. Ou seja, esse não é seu sistema, ele está enxergando a raíz a partir do diretório “/tmp/rootfs”. Mas agora se rodarmos ps aux, sucesso! Só enxergamos os processos dentro do novo namespace. Não só escondemos os PIDs de todo o sistema como escondemos o sistema de arquivos e você pensa que está num sistema completamente diferente.

Esse é o ponto que confunde todo mundo. O comportamento dentro desse shell faz parecer que estou dentro de uma máquina virtual. Mas isso não é uma máquina virtual, não tem um hypervisor como KVM com um emulador como QEMU simulando uma máquina nova do zero e fazendo boot de um novo kernel. Por isso estou reforçando que o diretório falso “/boot” tá vazio, não tem outra kernel. Isso não é uma máquina virtual. E se voltarmos pra outro terminal e executarmos ps aux esse bash que abrimos dentro do chroot tá aqui, aparecendo normalmente como se fosse qualquer outro processo.

Se não ficou claro. Alt-tab pro shell dentro do chroot. Executando ls /usr/bin vamos abrir um programa que tem aqui. Olha só, veio um python naquele tarball, vamos executar. Esse é o REPL de python que vocês já devem ter visto. Alt-tab pro terminal normal e ps aux de novo. Olha só aparecendo aqui python. Se fosse uma máquina virtual, teria um único processo, por exemplo de QEMU e só, eu não estaria vendo os processos dentro da máquina virtual misturado com os do meu sistema. E isso porque esses processos ESTÃO rodando no meu sistema normalmente, sem emulação, nem nada disso, é nativo.

Se não fosse assim, chamaríamos tudo de máquina virtual. Mas por isso inventamos esse termo novo chamado “container” justamente pra ser distinto. O processo está só sendo enganado, achando que está num outro sistema porque cortamos os olhos dele, as mãos dele, o nariz dele. E só apontamos tudo pra outros namespaces É isso que unshare e chroot fizeram com o shell do bash: isolaram num jarro, num container. Tudo que executa com unshare está na Matrix.

Nessa demonstração simples só escondemos os PIDs, o diretório “/proc” e o sistema de arquivos, mas dá pra mudar a rede, dá pra mudar todos os outros mounts como “/dev” ou “/sys”, dá pra fazer ele enxergar outros cgroups, outro clock do sistema, outros usuários e grupos, outro hostname e domainname, ou seja, o processo realmente vai achar que está em outra máquina, sem realmente estar. Ele pára de ter acesso ao resto do sistema e efetivamente roda “isolado”, que é todo o objetivo.

Namespaces são super flexíveis. Por exemplo, se isolar o container numa rede virtual, é assim que o processo num container consegue dar bind, digamos na porta 80, e um outro processo em outro container também consegue subir na porta 80, cada um numa rede isolada que daí configuro pra expor um pra fora como porta 4001 e outra como 4002. Mas também posso adicionar esses dois containers ambos no mesmo namespace de rede e assim crio uma rede virtual só entre os dois, sacaram? Pra isso serve o comando nsenter que é literalmente “entrar num namespace”, depois pesquisem.

Pesquisem no Google por “container from scratch” ou “container do zero” e vão esbarrar em artigos como do site da RedHat e diversos outros artigos explicando sobre unshare. Mas pra hoje esses exemplos que dei já servem pra continuar a explicação. As coisas começam a ficar confusas porque existem várias ferramentas que funcionam em cima dessa infraestrutura de cgroups e namespaces que expliquei. No começo, no mundo Linux surgiu Linux Containers ou LXC e depois Docker.

Em 2015 a empresa do Docker criou a Open Container Initiative ou OCI, um grupo com várias outras empresas pra padronizar e tornar mais portável todos os componentes que fazem containers funcionar, em particular o formato de imagens que é o formato OCI image, é o que você baixa do site dockerio.com. Os padrões estão todos na opencontainers.org e no mundo Linux a implementação desse padrão é a tecnologia “runC”. Vamos ver como funciona.

O runC precisa de um arquivo “config.json” que define as características do container. E vamos aproveitar aquele diretório “rootfs” ainda. O próprio comando runc gera esse arquivo executando runc spec dentro do diretório rootfs mesmo.

{
 "ociVersion": "1.0.2-dev",
 "process": {
  "terminal": true,
  "user": {
   "uid": 0,
   "gid": 0
  },
  "args": [
   "/bin/bash"
  ],
  "env": [
   "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
   "TERM=xterm"
  ],
  "cwd": "/",
  "capabilities": {
   "bounding": [
    "CAP_AUDIT_WRITE",
    "CAP_KILL",
    "CAP_NET_BIND_SERVICE"
   ],
   "effective": [
    "CAP_AUDIT_WRITE",
    "CAP_KILL",
    "CAP_NET_BIND_SERVICE"
   ],
   "permitted": [
    "CAP_AUDIT_WRITE",
    "CAP_KILL",
    "CAP_NET_BIND_SERVICE"
   ],
   "ambient": [
    "CAP_AUDIT_WRITE",
    "CAP_KILL",
    "CAP_NET_BIND_SERVICE"
   ]
  },
  "rlimits": [
   {
    "type": "RLIMIT_NOFILE",
    "hard": 1024,
    "soft": 1024
   }
  ],
  "noNewPrivileges": true
 },
 "root": {
  "path": "/tmp/rootfs",
  "readonly": true
 },
 "hostname": "runc",
 "mounts": [
  {
   "destination": "/proc",
   "type": "proc",
   "source": "proc"
  },
  {
   "destination": "/dev",
   "type": "tmpfs",
   "source": "tmpfs",
   "options": [
    "nosuid",
    "strictatime",
    "mode=755",
    "size=65536k"
   ]
  },
  {
   "destination": "/dev/pts",
   "type": "devpts",
   "source": "devpts",
   "options": [
    "nosuid",
    "noexec",
    "newinstance",
    "ptmxmode=0666",
    "mode=0620",
    "gid=5"
   ]
  },
  {
   "destination": "/dev/shm",
   "type": "tmpfs",
   "source": "shm",
   "options": [
    "nosuid",
    "noexec",
    "nodev",
    "mode=1777",
    "size=65536k"
   ]
  },
  {
   "destination": "/dev/mqueue",
   "type": "mqueue",
   "source": "mqueue",
   "options": [
    "nosuid",
    "noexec",
    "nodev"
   ]
  },
  {
   "destination": "/sys",
   "type": "sysfs",
   "source": "sysfs",
   "options": [
    "nosuid",
    "noexec",
    "nodev",
    "ro"
   ]
  },
  {
   "destination": "/sys/fs/cgroup",
   "type": "cgroup",
   "source": "cgroup",
   "options": [
    "nosuid",
    "noexec",
    "nodev",
    "relatime",
    "ro"
   ]
  }
 ],
 "linux": {
  "resources": {
   "devices": [
    {
     "allow": false,
     "access": "rwm"
    }
   ]
  },
  "namespaces": [
   {
    "type": "pid"
   },
   {
    "type": "network"
   },
   {
    "type": "ipc"
   },
   {
    "type": "uts"
   },
   {
    "type": "mount"
   },
   {
    "type": "cgroup"
   }
  ],
  "maskedPaths": [
   "/proc/acpi",
   "/proc/asound",
   "/proc/kcore",
   "/proc/keys",
   "/proc/latency_stats",
   "/proc/timer_list",
   "/proc/timer_stats",
   "/proc/sched_debug",
   "/sys/firmware",
   "/proc/scsi"
  ],
  "readonlyPaths": [
   "/proc/bus",
   "/proc/fs",
   "/proc/irq",
   "/proc/sys",
   "/proc/sysrq-trigger"
  ]
 }
}

Agora que vocês viram a demonstração com unshare, esse arquivo não deveria parecer muito alienígena. Inclusive foi por isso que fiz videos explicando Linux antes, porque precisa entender o sistema operacional pra entender como containers são configurados. Esse arquivo começa declarando a versão do padrão OCI, daí qual processo vamos rodar, que é o bash, e com qual usuário e grupo, no caso zero quer dizer root. Olha como já configura o PATH pra mim. “CWD” é Current Working Directory que é o diretório onde o programa vai abrir.

Capabilities pula que vou explicar depois. Daí “root” quer dizer a raíz do sistema de arquivos, que vai ser dentro daquele /tmp/rootfs onde fizemos chroot. Hostname é o nome da máquina, que é definido pelo namespace UTS, assim o container pode ter um nome de máquina diferente do nome da máquina de verdade.

No atributo de mounts aparece a mesma coisa que fizemos com a opção “–mount-proc” do comando unshare, onde mandamos dar mount no sistema de arquivos especial de processos. Assim, dentro do container não vai mais enxergar os pids de verdade do lado de fora. Mas aqui tá mais completo porque vai dar mount pra “/dev”, pros pseudo terminais em “/dev/pts”, pra memória compartilhada que é “/dev/shm”, as filas de mensagem pra comunicação entre processos em “/dev/mqueue”, o “/sys” que espelha funcionalidades e informações da kernel e finalmente o mount de cgroup que mostrei no começo do video. Tudo isolado dos de verdade do lado de fora do container. Estamos deixando esse jarro o mais realista possível pro processo dentro.

E por fim quais namespaces vou isolar também que são os mesmos do unshare. Pid sabemos que esconde os processos, mas temos network pra rede virtual, ipc que é a fila pra comunicação interprocessos, uts que permite mudar o hostname interno e mount que permite criar mounts diferentes do seu sistema.

Com tudo configurado, podemos executar, a partir de rootfs, sudo runc start hello. Hello você pode substituir por um nome qualquer pra esse container, contanto que seja um nome único, daí podemos criar quantos containers quisermos. Como aconteceu antes quando rodamos unshare com chroot, caímos no bash dentro do jarro, com todos os seus sentidos sequestrados. RunC está mentindo pro bash, vamos ver?

Se digitarmos id estamos como root. Se executarmos ls /boot, tá vazio, estamos dentro do diretório rootfs como nova raíz de arquivos. Melhor ainda, se digitarmos mount, temos só os pontos de montagem que definimos no config.json. Ele não enxerga nenhum dos pontos de montagem de verdade do meu sistema. E se digitarmos ps aux, como antes, só enxergamos o bash que está rodando. É como se fosse uma máquina de verdade vazia. Estamos dentro da Matrix, mas repetindo, isso não é uma máquina virtual. Container, na prática é outro nome dado a um processo em execução com menos acessos que um processo normal, mas no fundo é só isso: a execução de um processo.

O que eu falei no começo do episódio? Vou repetir: Se fosse fazer um TLDR, uma única frase que resume a diferença, é até simples: uma máquina virtual roda um novo kernel em qualquer arquitetura, um container reaproveita o mesmo kernel, nas mesma arquitetura. É essa a diferença. Mas agora vamos ver na prática. Estou repetindo o tempo todo que “/boot” está vazio. Não tem outra kernel, estamos compartilhando a mesma kernel. Hypervisors compartilham o hardware de verdade, como CPU, GPU e dispositivos pra máquinas virtuais que rodam qualquer outro sistema operacional, qualquer nova kernel isolados um dos outros. Posso rodar Windows do lado de BSD. Mas um container compartilha o mesmo kernel que existe já carregado. Ele não pode rodar sistemas operacionais diferentes, só outra distro Linux.

Vamos voltar pro que eu disse no começo: como Windows e MacOS fazem pra ter containers de Docker de Linux? Eles sim, primeiro precisam usar o hypervisor deles, o Hyper-V ou o Hypervisor.framework pra bootar um Linux de verdade e em cima desse Linux rodar o RunC pra conseguir ter containers de Linux. Por isso Docker é sempre mais pesado em cima de Windows do que direto num Linux. Numa distro Linux não tem a necessidade de rodar um hypervisor antes. Entenderam essa diferença? É muito importante, porque sua performance e uso de recursos como RAM sempre vai ser pior no Docker pra Windows ou pra Mac. Sempre, não tem exceção.

Mas eu falei Docker e fiquei mostrando RunC, qualé? É porque depois que a OCI foi formada, o Docker, Podman, Kubernetes, todos que usam containers, provavelmente usam RunC por baixo, que é a infraestrutura que usa cgroups, unshare e outras coisas que vem em todo Linux. Mas se tem RunC então pra que precisamos de Docker?

A parte importante do Docker não é mais a capacidade de executar containers. Hoje em dia isso vem nativo na kernel do Linux através do RunC que mostrei. O grande lance de Docker é o ecossistema de imagens, o DockerHub. Como é o tutorial de hello world de Docker logo depois que instala? docker run hello-world, vamos executar no terminal. Ele imprime esse texto e termina. O que aconteceu?

A ferramenta começa checando no registry local se tem uma imagem com nome “hello-world”. Como não tinha, deu “pull”, como se fosse o comando git clone ou mais especificamente, git pull. Já explico porquê, mas na prática baixou o binário do site hub.docker.com. Podemos ir no site deles e ver o registro dessa imagem lá, tão vendo? Na dúvida ele baixa da tag “latest”. É o equivalente à branch “main” ou a antiga “master”.

Essa imagem baixada é que nem aquele nosso diretório “/tmp/rootfs” que eu tinha baixado o tarball, onde demos chroot. Com essa imagem o runC sobe um container. Pra ver o container que executou basta rodar o comando docker container ls --all. Sem essa opção a lista seria vazia porque o container executa e termina. Com essa opção “all” ele mostra mesmo os terminados. Lembra no comando “runc” que dei o nome de “hello” pro container? No comando de docker run poderia passar a opção “–name” mas como não fiz isso ele deu um nome aleatório pro container.

Agora uma coisa que a maioria que já usou Docker nunca deve ter feito. Vamos executar o comando docker export NOME_CONTAINER > rootfs.tar. Sacaram? Podemos criar um diretório novo “mkdir -p /tmp/rootfs2” e fazer tar xvf rootfs.tar --directory /tmp/rootfs2. Agora damos “cd” pra dentro e não tem quase nada lá, alguns diretórios pra fazer mount de procs e outras coisas e esse executável “hello” que podemos executar diretamente com “./hello” e olha só, a mesma saída que vimos antes. É isso que o docker run executou e é assim que podemos pegar o conteúdo de uma imagem de Docker. Uma imagem de Docker não é muito diferente de um mero tarball.

Vamos entender melhor essa tal imagem. Pra começar, de volta no site do DockerHub vamos escolher a imagem do banco de dados Postgres. Agora vamos abrir do lado outro navegador com o arquivo Dockerfile no Github do repositório docker-library. Se clicarmos na tag “latest” podemos ver o que ele chama de layers. Sem ir linha a linha, só de bater o olho, conseguem ver onde um lado bate com o outro? Por exemplo, no Dockerfile tem esse comando “ENV GOSU_VERSION”. O comando ENV de Dockerfile serve pra configurar uma variável de ambiente, equivalente ao comando export num Bash. Todos esses “/bin/sh” são esses comandos RUN e assim por diante.

O que é um Dockerfile? É como se fosse um script de comandos que diz passo a passo como montar a tal imagem de Postgres. Voltando pra primeira linha, começa com o comando FROM. Não precisamos começar uma imagem do zero, podemos começar com uma que já existe e construir por cima. É como se fizéssemos git clone de um projeto e começássemos a adicionar coisas e ir fazendo git commit.

A grosso modo, cada comando do Dockerfile, esses em letra maiúscula no começo da linha, vão gerar um dos layers que vemos aqui no site do DockerHub. Com exceção de layers de configurar variável de ambiente, que é irrisório, a maioria dos comandos modifica ou baixa arquivos e por isso ocupa espaço. É que nem commit de Git. Por isso é comum num Dockerfile ter comandos RUN que executam vários comandos de shell concatenados, que nem logo no começo que fazemos apt update; apt-get install ...; rm -Rf. Por que?

Se o rm -Rf estivesse separado em outro comando RUN embaixo, o comando do apt-get install ia baixar e instalar pacotes, como em qualquer Debian ou Ubuntu que você usa. Digamos que instalou 50 megabytes, tô chutando. Mas vem um lixo opcional que não preciso, daí no comando seguinte rodo rm e apaga 10 megabytes. Mas a imagem vai ter um layer com 50 megabytes. Porque o rm ficou num layer separado.

Em vez disso eu baixo os 50 mega, na sequência já apago, e aí fecho a camada com 40 megabytes. Por isso fica tudo dentro do mesmo comando RUN, como se fosse num mesmo commit, entenderam? Quanto menos comando RUN no Dockerfile, melhor. Olha esse outro comando RUN embaixo, um monte de linhas um atrás do outro, e o resultado final de executar tudo é que vai no layer da imagem.

Essa é a importância da OCI que o Docker fundou. Ela define esse formato chamado imagem OCI. Dentro dessa imagem, que é um binariozão parecido com um zipão, tem alguns arquivos e diretórios obrigatórios. Como um index.json que tem o nome, ID, tamanho, lista de layers e histórico. Tem o oci-config.json que é o equivalente ao config.json do RunC que mostrei antes e, o mais importante, o diretório “blobs” que é parecido com diretório “.git/objects” de um repositório Git.

Ah, vocês não assistiram meu video de Git né? Lá eu expliquei que o importante é só o que tem no diretório “.git”, todo o resto pode jogar fora porque dá pra recriar tudo com o que tem aqui. Se listarmos ls .git/objects vem esse monte de subdiretórios. Vamos listar um deles e encontramos um arquivo com nome que é um SHA1. Esse é o SHA1 do commit de git. Os blobs da imagem de Docker é similar só que otimizados pra layers binários numa árvore, enquanto Git é otimizado pra árvore de commits de texto.

Lembram do formato QCOW2 que mostrei no episódio anterior? O QEMU Copy-on-Write versão 2 que é a imagem de HD virtual que o QEMU usa e onde instalamos o Windows virtualizado? É similar. O formato de imagem OCI também suporta copy-on-write. Que é o mesmo recurso que tem disponível em sistemas de arquivos modernos como o BTRFS. Um snapshot de BTRFS é similar com snapshot de QCOW2 que é parecido com layers de imagem OCI. COW permite criar layers só realmente com a diferença dos blocos que mudaram num arquivo.

Sabe diff que fazemos em Git e ele grava no commit só as linhas que foram adicionadas e as que foram removidas e não o arquivo todo? COW é como se fosse diff de arquivo binário. E lembra que eu venho repetindo em todos os videos da mini-série de armazenamento como arquivos são nada mais do que um conjunto de blocos binários organizados numa árvore? Se um arquivo tem 100 megabytes, divididos em 100 blocos de 1 megabyte, digamos que só 10 blocos desse arquivos foram alterados. Na próxima camada, ou commit, não precisa repetir os 100 megabytes inteiros do arquivo, só os 10 blocos modificados ocupando 10 megabytes. É por isso que imagens de Docker não são pesados.

Pra construir uma imagem nova só precisamos ter o arquivo Dockerfile como esse do Postgres e rodar o comando docker build. Se resolvermos mudar o Dockerfile a partir da metade, e repetirmos o comando docker build. Todas as camadas geradas pela primeira metade de comandos do arquivo permanecem as mesmas, jogamos fora as últimas camadas e ele executa os comandos a partir da metade. Por isso que quanto mais pro começo de um Dockerfile você mexer, mais o docker build vai ter que trabalhar. Se mexer só na última linha, só ela que vai ter que rodar.

Então uma imagem de OCI ou Docker é um conjunto de camadas binárias, como commits de um git. Pra montar dentro do container o Docker usa um sistema de arquivos chamado overlay2 que é um Union Filesystem. Union significa que unifica as diversas camadas num sistema de arquivos único. O container em si não sabe que tem essas camadas todas por baixo. Isso só importa pra construção da imagem, não pra rodar.

Eu menti agora pouco pra vocês. RunC é a infraestrutura de containers no Linux que sistemas como Kubernetes e Podman usam, mas o Docker propriamente dito na verdade usa outra coisa, que é o “containerd”. Pense assim, RunC tem menos funcionalidades, é mais simples, mais leve e pode rodar em userland, ou “rootless”, sem permissões de root ou daemons. Já containerd tem mais funcionalidades e foi feito pra funcionar com um daemon que sobe como root.

Por isso que quando se instala Docker, todo tutorial vai te falar pra executar “systemctl start docker” e habilitar o serviço pra subir no boot com “systemctl enable docker”. E isso pode se tornar um problema de segurança. Se sair pesquisando sobre buracos no Docker, vai achar várias formas de exploit dependendo de como o container foi configurado pra subir. O caso mais besta é subir um container com um comando como esse: docker run -tid -v /:/mnt/ alpine. Estão enxergando o erro?

O problema é essa opção “-v” que é pra mapear volumes. Lembra que quando estamos dentro da imagem o processo dentro não enxerga nada do sistema de arquivos fora? Pois bem, no mundo real o container é mais útil se ele tem “algum” acesso ao mundo externo. É melhor ser o Neo, saber que o mundo real existe, e ter superpoderes dentro da Matrix e um deles é conseguir enxergar arquivos do sistema de verdade.

Essa opção “-v” monta um diretório do lado de fora pra um diretório do lado de dentro, no caso do exemplo vai montar a raíz de verdade do meu HD pra um diretório “/mnt” no container. Mas isso é uma burrice, nunca faça um ponto de montagem tão amplo. Como o daemon que roda o container, o containerd que o Docker usa, sobe como root, ele tem permissão pra editar qualquer arquivo do sistema de verdade a partir desse ponto de montagem.

Daí é game-over, posso fazer o que quiser, inclusive editar o arquivo “/etc/passwd” pra injetar um novo usuário com permissão de root na máquina de verdade e invadir ela. Eu acho que ninguém em sã consciência jamais subiria um container de Docker num servidor de produção apontando pra raíz do HD do servidor. Só um sem noção faria isso. Seria certificado de estupidez.

É uma das razões de porque muitos de nós preferimos usar Podman em vez de Docker. Podman foi feito pra ter todos os mesmos comandos, mesmas opções e mesma sintaxe de Docker. Então comandos como docker build ou docker run -it bla bla posso rodar com podman build ou podman run bla bla. Se quiser posso fazer um alias no shell chamado docker que aponta pro podman e tudo vai funcionar praticamente igual. Podman usa o mesmo arquivo Dockerfile com a mesma sintaxe, a única diferença é aquele comando FROM no começo do arquivo.

Por exemplo, no caso do postgres começa com “FROM debian”. Pro Podman suportar precisa reescrever como “FROM docker.io/debian”. Só especificar o site da imagem porque ele suporta outros repositórios em vez de só o dockerhub. Outra diferença é que Docker é construído em cima do containerd, mas Podman usa o RunC como mostrei antes. Diferente do containerd não precisa ter um daemon rodando como root. Na verdade RunC, e por consequência o Podman, tem modo “rootless”. Ou seja, nem preciso iniciar com “sudo”. Portanto o container consegue rodar sem privilégio nenhum e por padrão é mais seguro. Veja documentação deles de como funciona esse modo porque não vou detalhar hoje.

E falando em segurança e permissões, pra concluir, faltou falar daquele bloco no arquivo do config.json que falei pra pular, lembram? Capacidade ou Linux Capabilities. Toda vez que se fala em permissões em Linux, automaticamente pensamos em coisas como os comandos “chown” pra mudar a propriedade de algum arquivo ou “chmod” pra mudar um arquivo pra ser só de leitura por exemplo. Ou, usar ou não usar “sudo” pra executar alguma coisa. E é isso, acabou.

Só que não. De cara vocês já aprenderam sobre cgroups e como eles limitam os recursos do processo, ou namespaces e como o sistema mente pros processos, independente se tem permissão de root ou não. E tem muito mais em cima. Linux capabilities é a habilidade da kernel de dar ou remover capacidades com o comando setcap.

Vou tentar não descer em detalhe desnecessário demais, mas num terminal o primeiro comando pra entender capabilities é o capsh. Execute num terminal e vemos dois campos no começo: Current e Bounding Set. Current vazio significa que um usuário normal começa sem nenhuma capacidade por default, mas tem várias capacidades que podem ser habilitadas, que é essa lista enorme chamada de Bounding Set.

Existem dois tipos de capacidades em Linux: capacidades efetivas e capacidades permitidas. Capacidades efetivas determinam quais operações um processo pode performar, e capacidades permitidas são quais podem ser habilitadas ou desabilitadas. Bounding Set é um sub-conjunto de capacidades permitidas. E quem controla esse set é o comando prctl, depois pesquise porque não quero entrar em detalhes sobre granularidade de segurança de Linux hoje.

Próximo comando vai ser grep Cap /proc/$BASHPID/status. Essa variável BASHPID é o pid do bash. Aí aparece essa lista bizarra, mas é fácil. O primeiro são inherited capabilities, ou capacidades herdadas no caso zero. Segundo são capacidades permitidas que eu falei, zero. Terceiro capacidades efetivas que também expliquei, zero. Finalmente capacidades bounding set.

Com o comando capsh --decode= esse hexadecimal e a lista é, obviamente, a mesma que vimos no comando capsh --print antes. Isso fica guardado no objeto proc do processo. E esse hexadecimal é um bit set. Um conjunto de bits. Se você não conhece a técnica de guardar propriedade num bit dentro de um inteiro e pegar os valores com uma máscara binária, um bit mask, pesquise. É essencial pra economizar bits em coisas como protocolos de rede.

De qualquer forma veja de novo aquele bloco de capabilities em config.json, agora você sabe o que é efetivo ou permitido. Esses cap_alguma coisa tem que ler no manual de capabilities. Só digitar man capabilities no terminal. Pronto, cap_audit_write é capacidade de escrever no log do sistema, cap_kill é capacidade de enviar sinais tipo SIGTERM ou SIGKILL e cap_net_bind_service é pra conseguir dar bind em portas privilegiadas abaixo de 1024, como a porta 80 sem precisar fazer sudo.

Com isso vocês tem pelo menos noção agora do que são containers do ponto de vista da kernel do Linux. Eles não são máquinas virtuais. É simplesmente um jarro que a kernel cria ao redor de um processo que roda nativamente pra restringir o que ele pode ver ou acessar, fazendo esse processo acreditar que está sozinho em outra máquina. A kernel usa cgroups e capabilities pra limitar os recursos e capacidades que esse processo tem acesso e usa namespaces pra limitar os sentidos desse processo, fazendo enxergar coisas como pids, mounts, rede, e tudo mais que são falsos, dentro da Matrix.

Docker é implementado em cima de containerd que é um serviço que precisa rodar como root. Podman e Kubernetes são implementados em cima de RunC que é mais leve e sem necessidade de um daemon auxiliar. Falando nisso, pode ser que Kubernetes ou Terraform confundam pra quem nunca mexeu. Qual a diferença disso pra Docker ou Docker Compose?

Vamos lá. Dockerfile vocês já entenderam, servem pra construir imagens OCI. Docker Compose é hiper útil, tem o Podman Compose que é exatamente a mesma coisa pra quem escolher usar Podman. Ambos começam com um arquivo docker-compose.yml. Deixa eu dar um exemplo besta aqui. Digamos que está trabalhando num projeto em Node. Comece criando um Dockerfile que constrói a imagem do seu projeto Node com seguinte conteúdo:

# Use the latest LTS (long-term support) version of Node.js as the base image
FROM docker.io/node:lts

# Set the working directory to the project root
WORKDIR /app

# Copy the package.json and package-lock.json files to the working directory
COPY package*.json ./

# Install the dependencies
RUN npm install

# Copy the rest of the project files to the working directory
COPY . .

# Expose the app's port
EXPOSE 3000

# Run the app when the container is started
CMD [ "npm", "start" ]

Começamos a partir da imagem do Node versão lts em vez do mais novo que é latest, lembram? Projetos em produção precisam de estabilidade e não da versão mais nova que pode ser a mais bugada. Sempre use a mesma versão de tudo na sua máquina de desenvolvimento e nos servidores de produção e isso começa pela image de docker.

Dentro do container, o código fonte do seu projeto vai ficar nesse WORKDIR, em /app. Daí copiamos o arquivo package.json pra dentro do container e rodamos npm install pra criar o node_modules e baixar todas as dependências. Terminamos de copiar todos o códigos fonte do projeto com esse comando COPY. Além disso esse container vai expôr pra fora a porta 3000 que é onde o servidor de node vai dar bind quando rodar o comando que está em CMD, no caso npm start.

Não esquecer de também criar um arquivo .dockerignore praquele comando COPY não copiar o node_modules que está no seu ambiente de desenvolvimento. Dentro do container já rodamos npm install então não precisa copiar tudo de novo. É importante entender onde ficam os arquivos em cada ambiente.

node_modules
*.log

Só com isso já dá pra fazer docker build . -t seuusuario/seuprojeto E já dá pra rodar com docker run -p 3000:3000 seuusuario/seuprojeto. Digamos que seu projeto precisa ter Redis e Postgres instalado. Isso costuma ser um problema, porque se você for um programador bem ocupado e experiente, na sua máquina deve ter diversos projetos. E alguns mais antigos podem depender de Postgres mais antigo, outros de Postgres mais novo. Mas se instalar na sua máquina via o gerenciador de pacotes da sua distro, sempre vai estar com a versão mais nova só.

Pra ter várias versões de node, muita gente usa o NVM ou o meu favorito que é o ASDF, mas e pra ter várias versões de postgres, de redis, de mysql, de kafka e todos esses outros componentes? E é pra isso que entra o Docker Compose. Este é um exemplo de arquivo docker-compose.yml que também ficaria na raíz do seu projeto:

version: "3"

services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_HOST=db
      - DATABASE_USER=app_user
      - DATABASE_PASSWORD=app_password
      - REDIS_HOST=redis
    depends_on:
      - db
      - redis

  db:
    image: docker.io/postgres:latest
    environment:
      - POSTGRES_USER=app_user
      - POSTGRES_PASSWORD=app_password

  redis:
    image: docker.io/redis:latest

Docker Compose orquestra e sobe vários containers Docker que ele chama de services. O primeiro é sua aplicação. Ele começa com o atributo build sendo ponto, que é o diretório atual. Vai subir a imagem que seria construída com o Dockerfile que tá no seu projeto nesse diretório. Daí configuramos o projeto com variáveis de ambiente, por exemplo dizemos que DATABASE_HOST se chama “db”. Normalmente você colocaria “localhost”, mas cada serviço é como se estivesse rodando numa máquina separada graças ao Namespace UTS que permite que cada um tenha seu hostname separado, por isso o service de Postgres vai se chamar “db”.

Logo embaixo começa o bloco “db” onde dizemos que é pra baixar a imagem docker.io/postgres:latest e configuramos o usuário e senha, que é o mesmo que o serviço de node da sua aplicação vai usar. Mesma coisa no terceiro service que chamamos de “redis” e baixa imagem docker.io/redis. Latest é a versão mais nova, mas num projeto de verdade é bom fixar uma versão em específico pra não confundir.

Veja também que o serviço app, que é sua aplicação, tem um bloco dizendo “depends_on”, ou seja, o docker compose só vai subir sua aplicação depois que os serviços de postgres e redis carregarem. E pronto. Mesmo que você seja um programador que acabou de entrar no projeto, depois de fazer git clone do repositório, é só rodar docker compose up e pronto! Vai subir todos os serviços e ao final pode ir no navegador a apontar pra localhost:3000 e que vai estar tudo de pé e funcionando. O ideal é manter essa configuração atualizada, porque o que mais acontece é ficar ajustando só na sua máquina e não subir a atualização pro repositório, daí pessoas novas entram na equipe e baixam uma configuração desatualizada e dá vários problemas. Mantenha tudo atualizado.

De bônus, lembra do video de otimização web onde explico sobre coisas como NGINX? Podemos simular o que eu falei naquele video com docker compose. Não é uma coisa que faríamos num projeto de verdade mas só pra ilustrar como aquele diagrama conceitual viraria código de Docker Compose:

version: "3"

services:
  app_1:
    build: .
    ports:
      - "3000"
    environment:
      - DATABASE_HOST=db
      - DATABASE_USER=app_user
      - DATABASE_PASSWORD=app_password
      - REDIS_HOST=redis
    depends_on:
      - db
      - redis

  app_2:
    build: .
    ports:
      - "3000"
    environment:
      - DATABASE_HOST=db
      - DATABASE_USER=app_user
      - DATABASE_PASSWORD=app_password
      - REDIS_HOST=redis
    depends_on:
      - db
      - redis

  db:
    image: docker.io/postgres:latest
    environment:
      - POSTGRES_USER=app_user
      - POSTGRES_PASSWORD=app_password

  redis:
    image: docker.io/redis:latest

  load_balancer:
    image: docker.io/nginx:latest
    ports:
      - "8080:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    depends_on:
      - app_1
      - app_2

Os serviços app, redis e postgres são iguaizinhos o do exemplo anterior mas agora adicionei um “load balancer” que puxa a imagem do nginx. Lembram que expliquei naquele video que ele é quem realmente responde na porta 80? E pro nginx funcionar precisa ter um arquivo nginx.conf no seu projeto que instruímos o docker compose copiar pra dentro do container de nginx. Esse arquivo diz o seguinte:

user                 nginx;
worker_processes     auto;

events {
    worker_connections  65535;
    multi_accept        on;
}

http {
    charset              utf-8;
    sendfile             on;
    tcp_nopush           on;
    tcp_nodelay          on;
    client_max_body_size 4m;

    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    map $remote_addr $proxy_forwarded_elem {

        # IPv4 addresses can be sent as-is
        ~^[0-9.]+$        "for=$remote_addr";

        # IPv6 addresses need to be bracketed and quoted
        ~^[0-9A-Fa-f:.]+$ "for=\"[$remote_addr]\"";

        # Unix domain socket names cannot be represented in RFC 7239 syntax
        default           "for=unknown";
    }

    map $http_forwarded $proxy_add_forwarded {

        # If the incoming Forwarded header is syntactically valid, append to it
        "~^(,[ \\t]*)*([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?(;([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?)*([ \\t]*,([ \\t]*([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?(;([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?)*)?)*$" "$http_forwarded, $proxy_forwarded_elem";

        # Otherwise, replace it
        default "$proxy_forwarded_elem";
    }

    upstream www {
        least_conn;
        server app_1:3000;
        server app_2:3000;
    }
    
    server {
    
        listen 80;
    
        location / {
            proxy_pass http://www;

            proxy_http_version                 1.1;
            proxy_cache_bypass                 $http_upgrade;
            
            # Proxy headers
            proxy_set_header Upgrade           $http_upgrade;
            #proxy_set_header Connection        $connection_upgrade;
            proxy_set_header Host              $host;
            proxy_set_header X-Real-IP         $remote_addr;
            proxy_set_header Forwarded         $proxy_add_forwarded;
            proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Host  $host;
            proxy_set_header X-Forwarded-Port  $server_port;
        }
    
    }
}

O bloco server, tem a configuração do servidor que vai escutar na porta 80 e fazer o tal proxy reverso pra http://app e app está configurado acima, são os hostnames app_1 e app_2 na porta 3000 de cada container. Lembrem que containers tem rede virtual separada, namespace de portas separado. Então cada um, quando carregar, se penduram na porta 3000 e o nginx vai fazer round robin entre esses dois servidores.

app_1 e app_2 herdam do serviço app que é sua aplicação em Node. Aqui estamos subindo duas instâncias pra ter balanceamento de carga entre os dois. Note que o serviço load_balancer depende desse app_1 e app_2 estarem de pé, e esses dois, por herdarem de app, dependem de redis e postgres estarem de pé e é assim que o docker compose sabe quem tem que subir primeiro pra tudo estar funcionando. E pronto! Isso é uma pequena demonstração de uma aplicação node com dois processos sendo balanceados por um nginx.

Docker Compose foi feito pra infraestrutura bem simples, em particular pra rodar na sua máquina de desenvolvimento e facilitar a vida de programadores. Ele até serve pra fazer deploy em servidores pequenos, tipo numa Digital Ocean da vida. Antigamente tinha um projeto chamado Docker Machine que servia pra conversar com provedores de servidores, mas acho que ninguém usa mais.

Veja como nesse arquivo, pra subir duas instâncias da aplicação, precisou manualmente digitar app_1, app_2, colocar eles no depends_on do load_balancer. Imagina se precisasse subir 10 instâncias. Ou se precisasse configurar replica de Postgres. Ou se precisasse configurar uma fila e vários servidores separados de jobs assíncronos como falei no video do ChatGPT. Esse arquivo não escala, ia ficar complicado ainda mais porque também não sabe só aumentar ou diminuir só os containers de web. Ele não tem noção do que está rodando nos servidores já e só dar manutenção.

É pra isso que entra Kubernetes e Terraform. Kubernetes é um conjunto de tecnologias de infraestrutura elástica. A parte que se aproxima de Docker é o que ele chama de pods, que são containers que rodam com RunC. Mas o Kubernetes faz bem mais, configura VPC que são redes privadas virtuais. Eu posso criar uma rede isolada só pros containers web, outra rede isolada separada só pra servidores de jobs, por exemplo. Sabe lidar com balanceador de carga, o Ingress, adicionar e remover pods dinamicamente, e sabe que está ou na AWS ou no Google Cloud ou na Azure e com isso consigo adicionar serviços exclusivos como o RDS da AWS como banco de dados ou o Cloud SQL do Google Cloud. É bem mais flexível e, por isso, mais complicado.

Entenda, um IaaS ou Infraestrutura como Serviço, como a AWS, me fornece os componentes básicos de infraestrutura. O Kubernetes é melhor pra lidar mais com os pods, os containers, depois que já tem a infra de máquinas e rede pronta. Pra subir essa infra inicial, podemos ou fazer na mão via interface web, o que não recomendamos, ou orquestrar com Terraform.

Por exemplo, máquinas virtuais que o AWS chama de EC2. Esses servidores tem tamanhos diferentes, por exemplo t2.nano que só tem 1 vcpu ou t2.xlarge de 4 vcpus ou a1.metal com 16 cpus, ou m4.16xlarge de 64 vcpus, cada um com um preço diferente por hora. Tem planos diferentes pra S3, pra RDS, pra SQS, e assim vai. E isso só na AWS. Pra organizar tudo, usamos Terraform. Deixa mostrar só alguns trechos de um exemplo de arquivo de configuração, que pode ficar super comprido.

# Set up the provider for the desired cloud provider
provider "aws" {
  region = "us-east-1"
}

# Create a VPC to host the resources
resource "aws_vpc" "app_vpc" {
  cidr_block = "10.0.0.0/16"
}

# Create a public subnet in the VPC
resource "aws_subnet" "public_subnet" {
  vpc_id            = aws_vpc.app_vpc.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "us-east-1a"
}

# Create an Internet Gateway and attach it to the VPC
resource "aws_internet_gateway" "app_igw" {
  vpc_id = aws_vpc.app_vpc.id
}

# Create a route table and a route for the public subnet
resource "aws_route_table" "public_route_table" {
  vpc_id = aws_vpc.app_vpc.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.app_igw.id
  }
}

# Associate the public subnet with the route table
resource "aws_route_table_association" "public_subnet_association" {
  subnet_id      = aws_subnet.public_subnet.id
  route_table_id = aws_route_table.public_route_table.id
}

# Create an EC2 instance to host the Node.js application
resource "aws_instance" "app_server" {
  ami           = "ami-12345678"
  instance_type = "t2.micro"
  vpc_id        = aws_vpc.app_vpc.id
  subnet_id     = aws_subnet.public_subnet.id
  key_name      = "app-key"
  user_data     = "${file("user_data.sh")}"
}

# Create a security group for the EC2 instance
resource "aws_security_group" "app_server_sg" {
  name        = "app_server_sg"
  description = "Security group for the application server"
  vpc_id      = aws_vpc.app_vpc.id
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# Create an RDS instance for Postgres
resource "aws_db_instance" "app_db" {
  engine               = "postgres"
  engine_version       = "11.5"
  instance_class       = "db.t2.micro"
  name                 = "app_db"
  username             = "app_user"
  password             = "app_password"
  vpc_security_group_ids = [aws_security_group.app_db_sg.id]
  vpc_id               = aws_vpc.app_vpc.id
  subnet_group_name    = "app_db_subnet_group"
}

# Create a security group for the RDS instance
resource "aws_security_group" "app_db_sg" {
  name        = "app_db_sg"
  description = "Security group for the application database"
  vpc_id      = aws_vpc.app_vpc.id
  ingress {
    from_port   = 5432
    to_port     = 5432
    protocol    = "tcp"
    cidr_blocks = ["10.0.1.0/24"]
  }
}

# Create a security group for Redis
resource "aws_security_group" "app_redis_sg" {
  name        = "app_redis_sg"
  description = "Security group for Redis"
  vpc_id      = aws_vpc.app_vpc.id
  ingress {
    from_port   = 6379
    to_port     = 6379
    protocol    = "tcp"
    cidr_blocks = ["10.0.1.0/24"]
  }
}

# Create an Elasticache cluster for Redis
resource "aws_elasticache_cluster" "app_redis" {
  engine            = "redis"
  cluster_id        = "app_redis"
  node_type         = "cache.t2.micro"
  num_cache_nodes   = 1
  security_group_ids = [aws_security_group.app_redis_sg.id]
  vpc_id            = aws_vpc.app_vpc.id
}

# Create an Nginx load balancer
resource "aws_lb" "app_lb" {
  name            = "app_lb"
  internal        = false
  security_groups = [aws_security_group.app_lb_sg.id]
  subnets         = [aws_subnet.public_subnet.id]
  load_balancer_type         = "application"
  idle_timeout               = 60
  enable_deletion_protection = false
}

# Create a security group for the Nginx load balancer
resource "aws_security_group" "app_lb_sg" {
  name        = "app_lb_sg"
  description = "Security group for the application load balancer"
  vpc_id      = aws_vpc.app_vpc.id
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# Create a target group for the Nginx load balancer
resource "aws_lb_target_group" "app_tg" {
  name     = "app_tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.app_vpc.id
  target_type = "instance"
}

# Register the EC2 instance with the target group
resource "aws_lb_target_group_attachment" "app_tg_attachment" {
  target_group_arn = aws_lb_target_group.app_tg.arn
  target_id        = aws_instance.app_server.id
  port             = 80
}

# Create a listener for the Nginx load balancer
resource "aws_lb_listener" "app_listener" {
  load_balancer_arn = aws_lb.app_lb.arn
  port              = "80"
  protocol          = "HTTP"
  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app_tg.arn
  }
}

Veja, o Terraform sabe que o provedor é AWS, e em qual região geográfica, no caso leste dos Estados Unidos, tipo Nova Iorque. Veja configuração de rede privada, subnets, gateway, tabela de rotas, e mais.

Daí contrato um servidor EC2, tamanho t2.micro, e configuro pra rede que tinha declarado antes. Embaixo configuramos grupo de segurança. Depois tenho configuração de banco de dados, depois de Redis que é o serviço que a AWS chama de Elasticache, depois tem o load balancer. E esse arquivo de exemplo é bem simplório e incompleto. Entre Kubernetes e Terraform, tem bastante detalhe pra realmente deployar uma aplicação em produção que esteja configurado de forma eficiente e com segurança.

Numa configuração de verdade, se tudo estiver direitinho declarado, seria só digitar terraform init pra fazer download e instalar os plugins necessários. Daí terraform plan pra criar o plano do deployment pra esse provedor e a gente checar se tá tudo realmente certo. Coisa que já tá instalada ele não vai instalar de novo, vai só reconfigurar e instalar o que falta. E no final fazer terraform apply pra realmente contratar os serviços, configurar e colocar nos lugares certos na infra.

Video de hoje não é sobre devops mas já que estou falando de containers e serviços, achei legal só mostrar um exemplo pra quem nunca viu. Mas o ponto é: compare uma configuração longa de Terraform com um simples Docker Compose. Nem chega perto, porque o objetivo das duas ferramentas é diferente. Um é pra orquestrar uma infra de verdade, a outra é pra rodar só na sua máquina pra facilitar desenvolvimento. Pra configurar uma AWS use Kubernetes e Terraform. Pra configurar serviços na sua máquina de desenvolvimento, use Docker Compose. Todo bom projeto deveria ter isso.

Pra finalizar, não vou mostrar mas queria só explicar outras tecnologias de containers que existem. Expliquei sobre imagens OCI de Docker, mas tem outro projeto que recomendo que pesquisem chamado OSTree. Lembra que falei que uma imagem meio que parece montado com commits binários de um Git? Existe de fato um projeto que é um Git de sistema de arquivos, o OSTree. A idéia é a seguinte: imagina que você tem 100 servidores numa AWS da vida, coisa grande. Imagina se sai atualização do Ubuntu Server que roda lá, o que você vai fazer? Mandar rodar apt update; apt upgrade -y e rezar pra não dar pau?

Na verdade não, vai montar imagens com ostree. O sistema de arquivos de todo servidor vai ser como um Git gigante. Daí sai atualização, você atualiza só em uma imagem. O OSTree nos servidores vai baixar a nova imagem e trocar a imagem antiga pela imagem nova. É tipo dar um git pull e trocar pro branch mais novo com um git checkout manja? É uma explicação grosseira, mas é bom saber que isso existe.

Outra coisa é sobre capacidades. Além de Linux capabilities que expliquei antes existem outra formas de limitar acesso a recursos da máquina, especialmente no contexto de segurança. Sabe em aplicativo Android ou iOS hoje em dia que pergunta se você quer dar acesso da camera pra um app ou acesso à sua localização e coisas assim? No mundo Linux isso é responsabilidade de componentes como Seccomp de Secure Computing Mode, que é outra funcionalidade da kernel do Linux pra restringir chamadas de sistema. Ele normalmente é usado em combinação com outros mecanismos de segurança, mas o seccomp em si oferece a infra na kernel pra aplicar filtros nos programas. Se alguém tentar fazer alguma coisa que não deveria, a kernel recusa.

Em cima disso temos projetos como AppArmor e SE-Linux. Olhando só por cima, eles se complementam. Ambos servem pra forçar políticas de segurança nos programas. O AppArmor permite especificar que recursos, como arquivos, dispositivos e sockets de rede um programa tem permissão pra usar. SE-Linux significa Security Enhanced Linux que também força políticas, por exemplo, pra acesso a hardware externo. É ele quem pode proibir um aplicativo de usar sua webcam.

Além disso, do jeito que falei, parece que todo container vai usar Namespaces de Linux com o comando unshare, mas existem outras formas de fazer containers, como o projeto Bubblewrap que é um container mais simples e usa outro recurso da kernel do Linux que são namespaces unprivileged e seccomp-bpf.

Mencionei ostree, seccomp, apparmor, se-linux e bubblewrap porque se você juntar todos eles num único projeto, começa a surgir com coisas como Flatpak. Sabe, aquele instalador de aplicativos? Tecnicamente é como se fosse um Docker ou Podman, mas feito pra funcionar melhor com aplicativos, especialmente aplicativos gráficos, com janela e que precisam acessar seus arquivos, USB e se comunicar com outros programas, precisando ter acesso a serviços como dbus. Tem gente que fica pensando em usar Docker pra instalar um Gimp ou LibreOffice. Não né, pra isso serve Flatpak.

Flatpak roda aplicativos como Spotify, Discord, Zoom, dentro de containers semi-isolados. Menos isolados que um container de Docker, mas um pouco mais seguros do que se fosse instalado direto via apt ou pacman. E o Snap de Ubuntu é similar, um gerenciador de containers. Em vez dos pacotes serem tipo zips como expliquei no video de Slackware, Flatpak e Snap baixam imagens, como imagens de Docker, só que em vez de imagem OCI é OSTree.

Entenda que Flatpak e Snap são primos de Docker e Kubernetes. As tecnologias por baixo também dependem da kernel do Linux e sempre caímos em cgroups, namespaces, capabilities e algum formato de HD virtual dentro de um linguição de bytes binários que chamamos de imagens. Espero que tenha dado uma luz no entendimento de containers e espero que ninguém mais tenha a pachorra de confundir containers com máquinas virtuais. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e compartilhem o video com seus amigos. A gente se vê, até mais!

Já tinha feito videos sobre antes de 1997 e sobre depois de 2002, ficou faltando contar justamente sobre como foi meu começo de carreira, a transição da faculdade pros primeiros empregos, de agência a pontocom, de CD-ROMs pra Web, tudo que eu passei no final dos anos 90 até a virada do século, incluindo o Bug do Milênio.

Muitos agora começando carreira ou vendo o atual Crash da Bolha Tech estão inseguros, talvez sirva como perspectiva pra dar uma noção de que crises são cíclicas e qual é a melhor posição pra se estar pra passar ileso todas as vezes.

Capítulos

• 00:00 - Intro
• 01:41 - CAP 1 - Relembrando 1997 - Retrospectiva
• 05:37 - CAP 2 - Meu Primeiro Emprego numa Agência - CD-ROMs
• 14:03 - CAP 3 - Minha Primeira Comida de Rabo - Sendo Estagiário
• 18:42 - CAP 4 - Minha Primeira Vez Aprendendo “Backend” - Microsoft
• 22:09 - CAP 5 - Combatendo o Bug do Milênio - Y2K
• 30:24 - CAP 6 - Meu Primeiro Merge e Layoff - A Primeira Pontocom
• 34:42 - CAP 7 - Entrando numa Agência “Big 5” - F/Nazca
• 37:55 - CAP 8 - A Primeira Vez Procurando Emprego - PSN
• 41:50 - CAP 9 - A Segunda Vez Procurando Emprego - SAP
• 44:54 - CAP 10 - O que me Motivava? - Perspectivas
• 46:45 - CAP 11 - O seu Colega Contrataria Você? - Verdadeiro Networking
• 52:10 - CAP 12 - Varar Noites?? - DISCLAIMER
• 54:00 - CAP 13 - Mas Akita: O que você recomenda pra mim? - O que o Akita NÃO Fez?
• 58:42 - Bloopers

Links

• Playlist: Minha História (https://www.youtube.com/watch?v=ii5Q2fCl8C0&list=PLdsnXVqbHDUe50Aqsa-i_NW42AkuByQZa)

• Playlist: Eu Avisei (https://www.youtube.com/watch?v=wpPv1dJWjDs&list=PLdsnXVqbHDUehzKjiRruy--gncHz9Injy)

• Playlist: Carreira (https://www.youtube.com/watch?v=A2-yU3YjB1U&list=PLdsnXVqbHDUcAWAN3cXHWnM9JEw2gjIN9)

• Macworld 1997: The return of Steve Jobs (https://www.youtube.com/watch?v=IOs6hnTI4lw)

• LinuxMall - A história de uma das primeiras lojas virtuais do Brasil (https://www.youtube.com/watch?v=BGVmQEpKTSI)

• The iPod Revolution (https://www.youtube.com/watch?v=FQwzI4kBG1o)

SCRIPT

Olá pessoal, Fabio Akita

Pra quem acompanha o canal desde o começo, deve ter notado que eu contei um pouco da minha carreira na área com videos como Meus Primeiros 5 Anos que fala um pouco de 1990 até 1995 que foi quando comecei na faculdade. Daí o video sobre o Livro “Estrada do Futuro”, falando um pouco sobre 1996. No video da minha Máquina do Tempo falo da importância de backups e alguns trabalhos que eu fiz por volta de 1996 a 1998. Teve os 2 videos curtos da Sua Linguagem é Especial? Onde falo sobre dois pequenos cases técnicos por volta do ano 2000.

Teve o video de Você não entende nada de Enterprise, onde falo sobre SAP, que foi meu período de consultoria entre 2002 a 2007. Finalmente, o video da História do Ruby on Rails que cobre um pouco entre 2007 a 2016. Mas ficou um buraco dessa história entre mais ou menos 1996 a 2002. Justamente o período final da Primeira Grande Bolha da Internet que explodiu no ano de 2001, junto com as Torres Gêmeas. O que eu estava fazendo naquela época?

(…)

Fiquem até o final do video que tenho alguns comentários a fazer sobre minha playlist de Eu Avisei, em particular o video sobre o estouro da Bolha de Tecnologia recente. Se quiser entender mais os princípios financeiros por trás dessa bolha, não deixe de assistir a playlist inteira. Até já aviso que esse video pode soar um pouco auto ajuda, especialmente pro fim, mas é o mais honesto que eu posso ser comparando minha situação 25 anos atrás com a situação de agora e talvez dar alguma perspectiva ou inspiração. Depois vocês me digam.

Mas vamos lá. O período entre 1996 até 2002 foi provavelmente quando eu mais aprendi tecnologias que não são mais usadas hoje em dia. A idéia é tanto um pouco de nostalgia pra vocês que estão na faixa dos 40 anos, mas também perspectiva pra vocês que estão na faixa dos 20 anos. O que o Akita estava fazendo depois da faculdade?

Pra quem não lembra, 1997 foi o ano que morreu a Princesa Diana, foi o maior rebuliço isso. Eu nem acompanhava mas lembro que falavam disso toda hora. Também foi o ano em que a J.K. Rowling publicou o primeiro livro do Harry Potter. Eu nem sabia disso, só fiquei sabendo que esses livros existiam mais perto de quase lançar o primeiro filme. Outra coisa engraçada, foi o ano que o Mike Tyson mordeu fora a orelha do Evander Holyfield, quem não lembra disso? Falando nisso, pro povo que curte perder tempo com documentário da Netflix, foi o ano que o O.J. Simpson foi julgado culpado.

E pra gente de tecnologia, foi o ano que o Steve Jobs anunciou sua volta pra Apple Computers, que na época tava negativo 1 bilhão de dólares, a dias de fechar as portas. Conseguem imaginar isso? A empresa mais valiosa de tecnologia hoje, em 1997 estava praticamente falida. Os anos 90 foram muito divertidos.

Enquanto isso, eu tinha 20 anos, indo pro 3o ano de faculdade. Quem assistiu os episódios anteriores vai lembrar que eu tava trabalhando como monitor na sala de computadores do CCE, aprendendo tudo que podia sobre UNIX, Internet, essa novidade chamada Web. Ao mesmo tempo, assim como a maioria de vocês de 20 anos, eu tava de saco cheio da faculdade. No meu caso, passava muito pouco tempo na minha faculdade mesmo, no IME. Eu preferia gastar meu tempo na sala de computação do CCE que ficava atravessando a rua, na Politécnica, e meus amigos eram todos da Engenharia Elétrica. Eu fazia Ciência da Computação e nessa época já quase não tinha nenhum amigo no meu curso mesmo.

Todo dia eu ficava deslumbrado com as novidades que surgiam. Estávamos no meio pro fim da transição da arquitetura de 16-bits pra 32-bits com os Pentiums. Estávamos no fim da transição de ambiente texto do MS-DOS pros gráficos do Windows, OS/2 e no caso de UNIX eu aprendi que existia Solaris, Irix. Estávamos entendendo como criar aplicações distribuídas nessa tal de Internet em vez de programas isolados feitos no meu antigo Clipper ou FoxPro. Novas linguagens estavam começando, como Java, Delphi. E naquela época não existia nada na Web ainda que chegasse perto de redes sociais.

Não existia Reddit, não existia Stackoverflow, não existia blogs, não existia Google. O máximo que a gente tinha eram sites que manualmente indexavam outros sites como o Yahoo ou Lycos, e as primeiras tentativas de indexação automática com sites como WebCrawler ou o famoso Altavista. Mas comparado com hoje, era hiper rudimentar. Pesquisar pra comprar componentes de computador, por exemplo, a gente ainda fazia via página de classificados nos jornais.

Foi naquela sala de computador da Politécnica, que tinha um quadro de avisos onde encontrei o anúncio do meu primeiro emprego. Uma agência pequena de novo esquisito, Kropki, não muito longe dali, de um professor da Escola de Comunicação e Artes na USP, a ECA, que era na mesma rua, passando a Politécnica, o IME que é minha faculdade, daí vinha a FEA que é a Faculdade de Economia, Administração e Contabilidade, daí era a ECA. Pouco antes da famigerada FFLCH, que recomendo passar longe. Enfim.

A agência em si, era caminhando pra fora do campus da USP, atravessando a ponte da Cidade Universitária em direção à Praça Panamericana. Uma caminhada de uns 5km a partir da minha faculdade, ou uns 40 minutos a pé. Na época eu considerava isso perto o suficiente pra ir a pé mesmo. Nessa época às vezes pegava o carro do meu pai emprestado, mas andava muito a pé e de ônibus mesmo, então era importante não ser longe demais e em São Paulo, 5km é o que chamamos de “aqui do lado”.

Fui até lá, e acabei sendo contratado como estagiário. Lá era uma agência que tinha meia dúzia de funcionários, uns 3 ou 4 designers que mexiam em Photoshop, alunos da ECA, ajustando capas de jogos de videogame, pra antiga Tectoy. Eles faziam as capas dos jogos de Megadrive, e tinham alguns outros clientes. Eles queriam entrar no mercado de multimídia e Web, mas eram mais usuários de Adobe do que qualquer outra coisa e precisavam de alguém de tecnologia, e esse alguém seria eu.

Lá tinha uns 3 ou 4 Mac Quadra ou Centris, não lembro exatamente. A linha feia bege da era do MacOS System 7 e 8, o período negro da Apple sem o Steve Jobs. Mesmo assim eu achava fascinante, afinal era a primeira interface gráfica comercial de sucesso e o Windows 95 ou 98 daquela época ainda era super cru em comparação. Infelizmente eu era o único que ia ter que usar um PC com Windows justamente pra experimentar as coisas novas saindo pra essa tal de Web.

De curiosidade, os Mac Quadra daquela época acho que eram os últimos modelos anteriores à migração pra PowerPC então ainda usavam os processadores Motorola 68000, como o 68040 de 33Mhz, talvez uns 16 Megabytes de RAM, HD externo SCSI. Foi a primeira vez que vi SCSI e zip drives da Iomega. O meu PC era mais novo e mais potente, um Pentium MMX acho que já de 100 Mhz, com uns 16, talvez 32 megabytes de RAM. Monitor Super VGA de 1024 por 768 pixels, um pouco mais do que o que chamamos de HD hoje em dia, que é 720p. RAM nos anos 90 era super caro, talvez a parte mais cara do computador.

Também de curiosidade, meu salário de estagiário naquela época foi de uns 500 reais. Ajustado pelo IPCA seria equivalente hoje a uns 2 mil reais. Super justo. Eu tava empolgado pra mexer mais na Web, mas queriam que eu aprendesse a fazer CD-ROMs. Na prática eu tava empolgado pra mexer em qualquer coisa que fosse no computador, e estava sendo pago pra isso, tanto fazia pra mim com o que eu ia ter que mexer.

Entenda. Não existia LinkedIn, nem Twitter, nem nada. Não existia eventos de tecnologia pra programadores. No máximo eventos corporativos de Microsoft ou Oracle. Meus colegas da faculdade estavam todos procurando programas de trainée numa Oracle da vida, ou bancos. Ninguém que eu conhecia tava indo trabalhar em agência. Eu deveria estar preenchendo formulários de programas de treinamento na indústria automobilística, seguros ou saúde, pra aprender a mexer em mainframes e Cobol. Mas eu nunca nem procurei saber como esse mercado funcionava. Eu achei esse emprego, tava meio de saco cheio da faculdade, liguei o “foda-se” e só fui.

Pra vocês terem uma idéia do que significava isso de CD-ROM, eu instalei um Windows Me num emulador chamado DOXBox-X, altamente recomendado se quiser rodar programas e até jogos de DOS daquela época, roda super bem mesmo num PC modesto de hoje. Uma empresa de tecnologia que era super reconhecida naquela época se chamava Macromedia, que fazia esse troço chamado Director. Director quando abre tem o que ele chama de stage, tipo um palco. Embaixo tem uma timeline.

Podemos abrir essa janela de casting, que é o nome que se dá ao grupo de atores escolhidos pra uma peça. O Director tem esse nome porque usa essa metáfora de um teatro, palco, atores, casting. Enfim, podemos inserir diversos tipos de objetos como bitmaps, clipes de video e no caso estou criando um objeto de vetor, semelhante ao que se faria com CorelDraw ou Adobe Illustrator. Olha só, aparece aqui na janela de casting. Agora posso arrastar pro stage, pro palco.

Daí posso criar keyframes, mover o objeto um pouco, ir mais pra frente, criar outro keyframe, mover o objeto mais um pouco e ir fazendo assim. Agora voltamos pro começo da timeline, damos play e voilá, uma animação super crua. E se isso pareceu familiar pra alguns de vocês, o Director começou sendo um software pra exportar executáveis pra gravar em CD-ROM, mas com a Web não ia demorar pra passar a exportar num formato distribuível pela Web instalando plugin em navegadores da época como o Netscape ou as primeiras versões do famigerado Internet Explorer. Era o formato Shockwave.

Com a evolução rápida da Web, a Macromedia simplificou o Director, focou mais na parte vetorial, as ferramentas mais simples de animação e chamou de Macromedia Flash. Essa é a origem do Flash, mas estou me adiantando. Deixa eu voltar pro Director. Assim como em Flash, todo mundo sabe que tinha uma linguagem derivada de Javascript pra programar interatividade, chamada ActionScript. O Director também tinha uma linguagem, só que ainda mais rudimentar, declarativa, chamada Lingo.

Por exemplo, posso adicionar um script aqui num dos frames pra pausar. Pronto, rebobino a fita, dou play de novo e ele pára aqui. Se tem o comando “pause”, deve ter o comando “resume”. Posso adicionar um novo comportamento nesse sprite, no evento “mouseUp” que é quando eu termino de apertar o botão do mouse, posso adicionar “resume” usando essa ajuda rudimentar aqui que lista todas as funções do Lingo. Resume sprite 1. Dou play de novo, ele pausa, clico no ator e … erro.

Handler not defined. Maldito erro genérico, Javascript deve ter se inspirado em Lingo. Bom, vamos procurar no Stackoverflow então. Só que em 1997 não tinha Stackoverflow, nem Google, nem fóruns de discussão. Eu tinha um livro impresso. O software tem essa documentação local aqui. E era isso. Nem se eu perguntar hoje pro ChatGPT ele sabe me dar uma boa resposta. E agora em 2023 obviamente não lembro mais o que significa isso. A única coisa que me ocorre é uma gambiarra. Já que resume não funciona, estou aqui no frame 6, então vou dar comando pra pular pro próximo frame e torcer pra continuar. Go to frame 7. Como eu disse é uma linguagem declarativa.

Rebobina, dou play, pausa, clico no ator e boom, ele continua como eu queria. E meu dia a dia era assim: mensagens de erro que não diziam coisa nenhuma, ficar fuçando a documentação e tentando coisas até conseguir fazer funcionar. Imagino que não é muito diferente do que a maioria de vocês fazem hoje em dia, só que eu tinha bem menos opções de onde pesquisar erros. Foi fazendo assim que consegui compilar meu primeiro CD, que foi esse aqui do lançamento do Volks Parati 4 portas.

Se não me engano foi uma campanha pra dealerships, pra treinamento dos vendedores de concessionárias, mas enfim, é como se fosse um site web estático, mas em formato de CD-ROM. “E por que não um site de uma vez?”, alguém poderia perguntar. Por que internet em 1997 era altamente opcional. A maioria da população ainda nem sabia o que era isso. Mesmo em pequenas empresas, no máximo o povo tinha conexão discada via iG ou Terra ou America Online, ou UOL. E a conexão média era de 19 kilobits por segundo.

Uma imagem de 160 pixels por 150 pixels, metade do que seria a tela de um Nintendinho, com 7 bits de cor, dava uns 20 kilobytes. Imagine múltiplas imagens dessa. Levava vários segundos a minutos pra montar uma tela como essa via web. Por isso a Web de 1997 era bem mais rudimentar do que era possível fazer num CD-ROM, que já vinha com todas as imagens, clipes de video, áudio e tudo mais local, num CD de 650 megabytes. Streaming de video e áudio era impossível naquela época. Só que todo mundo pagou uma grana investindo nos tais kits multimídia, como da Creative Labs, e queriam ver videos e áudio. O que a gente fazia em CD era impossível de fazer na Web.

Assistam meu video sobre compressão, de 25 TB pra 5 gigabytes, onde explico sobre cores, algoritmos de compressão e tudo mais. Boa parte do meu trabalho era converter Jpegs com 8 bits de cor em GIFs com paleta de cor menor pra fazer versão web de algumas coisas. Naquela época, o mais comum eram monitores VGA de 800 por 600 pixels, que seria o nosso “4K” considerando que o padrão era tipo 320 por 240 num sistema operacional texto como MSX, Commodore ou consoles como Super Nintendo ou Megadrive. E com 256 cores.

Olha alguns dos sites que eu fazia naquela época, vou só passar aqui alguns slides de fotos de tela, mas deve dar pra dar uma noção de quão limitado era a tecnologia da época. Hoje em dia vocês estão acostumados no mínimo a Full HD que é 1080p e pelo menos 8 bits de cor com milhões de cores possíveis, ou HDR com 10 ou 12 bits de cor em 4K nos monitores mais avançados. Pular de 80 colunas por 24 linhas em monitor de 240p, pra VGA colorido em 768p, é como vocês pulando de Full HD pra 4K hoje em dia.

O CD-ROM mais complicado que eu fiz, foi o projeto do lançamento do Fiat Marea. Esse foi particularmente difícil porque a Fiat ainda tava mudando detalhes como opcionais do carro, cores de tecidos, e coisas assim enquanto a gente tava montando o CD. Os designers tinham que fazer coisas como mudar a cor dos tecidos nas fotos antigas direto no Photoshop, porque não ia dar tempo de tirar novas fotos em estúdio com os novos materiais. Foi a primeira vez que eu vi Photoshop sendo usado pra coisas desse tipo e isso explodiu minha cabeça naquela época. Foi vendo isso que decidi aprender mais sobre essa parte gráfica e aprender Photoshop.

Se eu montasse o CD do jeito tradicional, como eu mostrei no começo, até que não era um projeto difícil. Mas eu era um aluno de ciências da computação aprendendo coisas como Delphi, Java e esse troço novo na época chamado Orientação a Objetos. E eu ficava tentando adicionar objetos em tudo. Delphi era basicamente Pascal com objetos, tanto que chamava Object Pascal. Mas eu usava ainda o Turbo Pascal 6 de DOS, que não tinha classes, mas tinha objetos rudimentares, e eu queria adicionar suporte a pelo menos encapsulamento e talvez herança nessa linguagem rudimentar de Lingo pra Director.

Tá vendo esse menu principal? Ele aparece em todas as seções do CD. Cada seção o Director recomenda organizar como um arquivo separado, daí um evento num arquivo basicamente carrega outro arquivo. Seria como um anchor em HTML que tem a URL pra carregar outra página. Eu queria fazer um objeto reusável entre todos, o que vocês chamariam hoje de componente. Obviamente isso é um caso de uso não documentado, que não tinha em nenhum livro. E óbvio que deu um monte de bug que eu tive que varar muitas noites pra resolver. E quando digo muitas, quero realmente dizer MUITAS noites sem dormir.

Lembro até hoje que por minha culpa, quase não deu pra lançar o CD. Entenda: hoje em dia se alguma coisa dá pau, fácil, só subir um commit de correção, deployar e em alguns minutos tá corrigido. Mas um CD exige um compromisso que nenhum de vocês vê mais hoje: uma vez prensado, não tem como corrigir os CDs distribuídos. Esses CDs do Fiat Marea iam ser distribuídos em revistas da Editora Abril como Quatro Rodas e Playboy, e uma vez queimado o CD Gold, o master, não tem mais como corrigir.

O processo todo já tava atrasado de qualquer jeito porque a Fiat não parava de fazer modificações de última hora que exigia mudar textos da especificação dos modelos, opcionais, e tudo mais, e em cima disso toda vez que a gente ia apresentar pro gerente de contas da Fiat, minha programação dava um bug inesperado. No último dia, literalmente na última hora, lembro de compilar a última versão, gravar num CD na agência, pegar o carro, tipo 10 horas da noite e ir até a Zona Norte de São Paulo, onde ficava a antiga Sonopress, a fábrica que prensava os CDs em massa.

Pensa, eu era estagiário, tinha 20 anos, fui sozinho com o CD embaixo do braço pra mostrar pro gerente de contas mais rabugento, mau educado e nervoso da face da Terra, roendo todas as unhas das mãos e dos pés, porque depois de tantos dias de bugs, eu tava com minha confiança por um fio. E por sorte, nos 45 do segundo tempo, navegamos por todo o CD e funcionou sem bugs.

Ali ele deu ok pra Sonopress prensar. Lembro até hoje, saindo com ele, no estacionamento, ele me parou e ventilou tudo que tinha que ventilar na minha cara. Eu não lembro de uma palavra do que ele disse, só que eu fiquei ali, sei lá, 11 horas da noite, paralizado no meio do estacionamento vazio, só ouvindo. Foi a primeira comida de rabo sério que tomei. Vocês acham que eu sou rabugento nos videos? Volta aqui depois que experimentarem terem saliva voando na sua cara de alguém gritando.

Eu queria ter uma moral da história, tipo que depois disso eu me tornei mais cuidadoso, mais prudente, que me ajudou de alguma forma, mas tem uma coisa que descobri recentemente que talvez explique como reagi na época: eu fiz teste preliminar com psicólogo e de fato, parece que eu tenho um certo grau de Asperger, tipo um autismo leve. Eu compartimentalizo. Nada se torna gatilho pra eu desistir ou fazer alguma coisa por conta de algum evento traumático ou importante de alguma forma. Eu compartimentalizo, embrulho, enterro e sigo em frente. Não tenho idéia de como outras pessoas lidam com isso, porque uma pessoa mais sensível provavelmente teria abandonado tudo naquele dia.

Eu já tive que ouvir outras pessoas ventilando mais do que seria profissional, mas naquele nível, felizmente foi a primeira e última vez. Eu não sei fazer as coisas como as outras pessoas esperam que eu faça. Se eu coloco uma coisa na cabeça, quero tentar fazer, independente do trabalho que vou ter. Foi o que falei no video de Por que fazer o que Ama, só que não. Eu não faço as coisas que eu gosto, eu faço as coisas porque eu gosto de saber se consigo fazer. Depois que consigo, perco o interesse, e procuro outra coisa.

Na faculdade eu tava empolgado com UNIX, com Delphi, com Java, HTML, Javascript, não muito diferente do que muitos de vocês hoje devem estar vendo. Talvez Python, que ainda não era popular na época. Mas na agência me pediram pra aprender a fazer CD-ROM com Director. Eu nunca tinha ouvido falar nisso até entrar lá, nunca tinha planejado gastar 1 ano fazendo CD-ROM. Mas quando ouvi essa proposta, coçou os dedos. Eu queria saber se conseguia fazer. E não só fazer, mas fazer de formas que não era comum. O preço disso era que eu ia varar noites, tomar comida de rabo, mas eu entregava. Essa sempre foi minha motivação: entregar.

Em paralelo eu fazia os sites estáticos, em HTML puro. Aliás, na época não existia CSS ainda, tá? Formatação era usando tags como “font” e atributos de estilo inline com “style”. Aos poucos fui mexendo em mais tecnologias Web. A internet começou a ficar um pouco mais rápida, pulamos pra modems de 56 kilobits por segundo, depois pra 128 kilobits quando o Speedy, Ajato e outros provedores de banda larga começaram a chegar. Daí migrei de Director pra Flash, e comecei a aprender ASP.

Por volta de 1998 eu fiz um pequeno trabalho pra construtora Camargo Correa que envolvia indexar vários documentos PDF que eles tinham pra fazer tipo um motor de busca, um search engine, usando o antigo Microsoft Index Server que depois acho que virou Indexing Services. Isso tinha no IIS que vinha nos antigos Windows NT 4. A idéia era fazer um pequeno site de intranet, que seria acessado só internamente, pra conseguirem pesquisar rapidamente a biblioteca de PDFs deles.

De novo, 1998 foi quando o Google tinha acabado de ser fundado, literalmente funcionando da garagem. Nessa época já existiam várias tecnologias pra pesquisar conteúdo. Todo mundo rapidamente começou a perceber que com a microinformática sendo largamente adotada, documentos digitais começando a ganhar peso, o volume de conteúdo aumentava exponencialmente e precisávamos dar um jeito de organizar tudo e facilitar pesquisa.

Eu sabia disso em 1998? Não tinha nem idéia, só viria a começar a usar Google talvez no ano 2000. Eu era assim: “ow, tem que fazer um site pra pesquisar documentos”. Eu sabia como? Não tinha nem idéia, daí ia fuçar como resolver. Microsoft era uma das poucas empresas que tinha boa documentação online no MSDN. Assim esbarrei em Index Server. Pra isso precisava aprender ASP, daí lá vou eu aprender ASP e ao mesmo tempo tinha que saber Microsoft SQL Server. Eu sabia o que era SQL? Não. Lá vou eu aprender. Tudo pra fazer esse um projetinho.

A gente já ouvia falar da tal da Oracle, que na época era uma das maiores gigantes no mundo de tecnologia com seu banco de dados que eu sabia toda grande empresa usava. Eu nunca tinha visto um, só sabia que era difícil. E não era como se desse pra ir no site e baixar. A licença custava milhares de dólares, vinha em pacote físico, com livros, CDs e tudo mais. Não era acessível pra meros mortais como eu. E foi aí que a Microsoft foi inteligente, porque um SQL Server, eu conseguia baixar, aprender e usar, tudo online. E foi assim que comecei a aprender sobre SQL.

Comecei com o SQL Server 6.5 e de curiosidade, o SQL Server começou como um port do antigo banco de dados da Sybase pra OS/2, em 16 bits, em 1989. Saiu a versão 4.2 pra NT em 1993 e o 6.0 saiu em 1995. A versão 7 sairia um pouco depois que eu comecei a aprender. Foi a versão que eu mais usei.

De qualquer forma, a vida daquela pequena agência tava chegando no fim por volta de 1998. Acho que trabalhei lá só uns 2 anos e nesse período aprendi HTML, Director, Flash, comecei a aprender ASP, SQL Server. Mas pelo jeito o dono não soube administrar bem a empresa, ela foi diminuindo, até que só sobrou eu e mais um outro funcionário e passamos a trabalhar da sala de professores na faculdade, na ECA. Fiquei pouco tempo lá, porque um amigo meu me chamou pra trabalhar na empresa dele. Como parecia que não tinha mais pra onde ir mesmo, resolvi aceitar.

Essa empresa foi a STI, um dos primeiros provedores de internet do Brasil. Começou como uma BBS e evoluiu pra internet. E lá trabalhava meu vizinho. A gente se conhecia desde adolescente e aprendemos a mexer em computador juntos. No episódio dos primeiros 5 anos eu falo dele, o Thiago Madeira, que teve sua própria BBS antes de ir pra STI enquanto eu ia pra faculdade e foi ele que tinha o contato que me colocou como monitor da sala de computação da USP pra baixar pirataria pra BBS dele. Contei essa história no outro video.

Enfim, já era quase meio de 1999 e a empresa tinha um problema. Por anos toda a administração era controlada por um software feito por um dos co-fundadores, no antigo Clipper de DOS, que eu conhecia e programava no começo dos anos 90. Ele controlava tudo: cadastro de cliente, faturas, cobranças, suporte técnico e mais. Programas em Clipper eram feitos pra funcionar com um único usuário numa única máquina, mas ao longo dos anos 90 criaram várias gambiarras pra compartilhar o arquivo de banco de dados via redes, como em infraestrutura da antiga Novell Netware.

Dava pra ver que era a clássica empresa que nasceu em garagem e cresceu rápido: o servidor já tava perto do último suspiro, era um PC de gabinete aberto, com um ventilador apontado pra ele, ligado em rede pra todo mundo da empresa conseguir acessar. A forma de fazer isso era bloqueando o arquivo de banco de dados, fazendo alguma operação, daí desbloqueando pro próximo poder usar. Essa é a forma mais rudimentar de banco de dados que existia, mas funcionou por anos, até a empresa ter dezenas de funcionários e milhares de clientes.

Mas esse não era o maior problema, porque eles tinham dinheiro de sobra pra colocar tudo num hardware mais moderno. O problema era que Clipper foi feito nos anos 80, numa época onde 640 kilobytes de RAM era o máximo. Onde a gente literalmente escovava e economizava bits onde dava, em particular nos tipos de data. Pra que gravar 1980 se só gravar 80 já era suficiente? Economizava 2 bytes por registro fazendo isso. Daí na hora de mostrar era só concatenar “19” na frente e pronto. Quer saber quantos anos se passaram de 1990 até 1998? Só fazer 98 menos 90. Ponto.

Mas em breve, teríamos contas assim: 2000 menos 1998 dá quanto? Não dá pra fazer 00 menos 98. Dá pau. Esse é o famoso Bug do Milênio ou Y2K como chamamos hoje. A solução correta era recompilar num Clipper mais novo, que tinha correção de ano 2000, vasculhar o código-fonte onde faz contas com datas e checar se não tem nada hardcoded com 2 bytes e ir ajustando. Daí fazer uma versão mais nova que funcionaria depois do ano 2000.

Só que era uma empresa de tecnologia, nova, com pessoas novas, com um co-fundador técnico, coisa rara na época. Foda-se, vamos reescrever tudo em tecnologias mais modernas. Na época, era justamente pra fazer tudo em 32-bits, com a moderníssima linguagem ASP, pra funcionar em cima de SQL Server, num Windows NT, coisa profissa. Obviamente eu fiquei empolgado, afinal, era justo as coisas que eu tava começando a aprender por causa do último projeto na agência. Alguém vai me pagar pra eu continuar aprendendo? Bora.

O problema: tinha menos de 6 meses pra fazer as coisas funcionarem, já estávamos por volta de junho de 1999. Lembrem-se que existem coisas como plano semestral. Tem partes que já iam começar a falhar se fôssemos imprimir boletos no futuro. A partir de agosto de 1999 já ia passar a barreira pra janeiro de 2000. Eu não tinha idéia do trabalho que algo assim poderia dar, se tivesse talvez não tivesse concordado e sugerido um plano mais convencional como tentar ajustar em cima do código legado mesmo. Mas eu era um moleque de 22 anos que só queria a oportunidade de mexer com coisas novas.

Por sorte a equipe que foi formada era muito boa. Eu não era o melhor mas certamente era o mais arrogante, não tenha dúvidas disso. Na minha cabeça tudo dava. Eu não lembro mais de todos os detalhes, mas precisávamos fazer ferramentas de atendimento pra todo o pessoal do suporte técnico que atendia os clientes, tipo ferramenta de help desk, mais um banco de conhecimento com todos os truques que se sabia pra ajudar os novos atendentes. Precisava fazer ferramenta da parte financeira, consolidação de contas, impressão de boletos, gerenciar vendas e por aí vai. Era tipo um mini ERP dessa empresa.

Falando em Bug do Milênio, muita gente de fora achava que ia chegar 31 de dezembro de 1999 e na virada do ano tudo ia quebrar. Inocentes, tudo já ia começar a quebrar pelo menos 6 meses antes, em alguns lugares antes ainda. Que nem o caso de boletos que eu falei. Como você imprime um boleto datado pra janeiro de 2000? As empresas não estava às cegas assim não, todo mundo já tava tendo que lidar com esse problema muitos meses antes do que a população em geral imaginava.

Lembro até hoje de outro episódio “what the fuck” que passei. Se não estou enganado, todo mês imprimiam os boletos pra mandar por correio pra todos os milhares de clientes. E não lembro detalhes, mas justamente acho que se o cara contratava um plano semestral, já mandavam os 6 boletos de uma só vez. E por isso já por agosto ia ter o problema do ano 2000 que acabei de explicar. Em determinado momento de 1999 as pessoas já iam receber boletos datados pra pagar no ano 2000.

Lembrando também que falei que o sistema antigo em funcionamento era em Clipper, ou seja, com banco de dados que é só um arquivão gigante em formato DBF, sem servidor intermediando. Também falei que era um arquivão compartilhado numa rede Novell, que rodava em DOS com sistema de arquivos FAT16. Quem já lidou com isso sabe: esse sistema de arquivos não tem absolutamente nenhum tipo de funcionalidade de prevenção e correção de erros. Basta cair a luz uma vez pra começar a dar muita merda. Dados corrompidos era rotina.

Precisávamos fazer engenharia reversa desse arquivo pra dar carga no SQL Server. Só que à medida que abríamos esse arquivo dava pra ver que tinha registros corrompidos no meio do caminho. Povo de data science sabe o que significa “limpar dados”. Essa foi minha primeira experiência usando SQL como se não houvesse amanhã pra limpar e várias queries pra garantir que tava tudo certo. Diferente de data science, que se tiver algum errinho não costuma ser um grande problema porque dá pra lidar com margens de erro, quando falamos de contabilidade, não pode ter uma vírgula fora do lugar. Ninguém pode receber cobranças erradas. Qualquer pequeno volume de erros significava congestionamento no atendimento pra resolver.

Daí finalmente fizemos uma primeira versão que ia imprimir os novos boletos pela primeira vez. Não lembro, talvez agosto ou setembro de 1999. Fiz um monte de queries, ainda tinha uns bugs que eu não tava satisfeito, mas chegamos no momento de “acho que tá bom o suficiente”. Mandamos rodar e as impressoras no andar de baixo começaram a imprimir. Pensa que ia levar a noite inteira imprimindo pro serviço de entrega ir buscar as caixas na manhã seguinte.

O escritório do STI ficava numa cidade chamada Santana de Parnaíba, depois de Alphaville aqui de São Paulo, quase 30 quilômetros de distância da casa dos meus pais onde eu morava. 45 minutos de carro sem trânsito ou 2 horas, que era o que eu levava todo dia pra voltar. Eu passei o trânsito todo da volta com pulga atrás da orelha. Cheguei em casa, jantei e tal, deitei pra dormir e foi aí que me ocorreu: tinha um bug que ia foder todos os boletos!

Lembro que levantei no susto, peguei o carro sei lá, meia noite e fui correndo pro escritório. Eu tive meu momento de “parem as máquinas!!!” E passei a madrugada tentando corrigir o tal bug. Queria lembrar o que era exatamente, mas era um bug lazarento. Eu acho que consegui resolver e finalmente deu pra continuar imprimindo a tempo de acabar pra entrega de manhã. Eu tenho poucas memórias daquela época. Acho que deu certo porque não lembro de repercussões tão negativas. A gente sabia que podia ter um certo grau de erro, mas era importante não ser demais pra não congestionar o suporte.

Meus primeiros 10 anos seriam uma sucessão de eventos desse tipo: pegar desafios que eu não tinha idéia de como fazer, varar noite tentando resolver, causar muitos bugs que não sabia como corrigir, e arrancar os cabelos tentando descobrir. Muito me admira que eu ainda tenho cabelo. Enfim, acho que chegamos muito perto de conseguir substituir o sistema antigo pelo novo, mas aí aconteceu um evento inesperado: a STI foi adquirida por uma outra empresa maior, a PSINet.

Por causa desse merge mudou muita coisa, não sei se nosso sistema foi usado ou não ou se iam adotar outro, mas foi onde vi meu primeiro layoff, demissão em massa. Num merge de várias empresas, acaba que muitas posições ficam redundantes, daí demitiram muita gente de uma só vez. Ouvi falar que muitos ficaram descontentes, saqueram o escritório, levaram computador, monitor e coisas assim.

No meu caso foi diferente, porque minha equipe, que era próxima dos co-fundadores, foi levada pra montar outra empresa. Eu não tinha outra coisa pra fazer, fui junto. Montaram outro escritório e me pediram pra pegar um produtinho que eles compraram pra envio de email e falaram pra eu fazer uma interface gráfica pra ela. O problema que tinha que ser em PHP. Eu passei meses mexendo em ASP e tava super fluente, mas beleza, lá vou eu aprender outra coisa. Ainda bem que eu tinha aprendido um pouco de UNIX e Linux na faculdade porque agora ia precisar mexer com Linux e Apache.

Esse produtinho foi batizado de Internet Email Grátis ou ieG, um dos primeiros produtos independentes, que não era atrelado a um provedor, pra dar email grátis pra qualquer um. Pense um Gmail rudimentar, 6 anos antes do Gmail. Eu tava explorando a idéia de uma interface gráfica Web que seria parecido com um aplicativo nativo de Windows de verdade, daí fiz uma versão Web do Outlook Express, antes do Outlook pra Web sair de verdade. Ponto de comparação naquela época acho que já tinha Hotmail.

Esse produto foi fácil, daí formou uma nova equipe e nos pediram pra fazer outro produto: um Geocities brasileiro. Pra quem não sabe o que é Geocities, era um produto web pra qualquer um conseguir ter sua própria homepage pessoal gratuita. A contrapartida era deixar colocar um banner no topo pra monetizar. A nossa ia se chamar HomePage Grátis ou HPG. Quem começou a mexer com internet no começo dos anos 2000 vai se lembrar de HPG. Esse produto explodiu, todo mundo tinha um site hpg.com.br/alguma coisa. Pensa, era uma época que ainda não era difícil conseguir domínios de 3 letras.

Você podia andar num shopping center e ver a URL hpg da loja na vitrine, ou em outdoor, ou pintado nos ônibus. Esse produto explodiu. Eu participei da primeira versão, feita com PHP e Perl. E foi assim que aprendi Regular Expressions, porque todo mundo ficava tentando achar jeitos de burlar os banners que a gente colocava e eu passava o dia fazendo Regex pra tirar os truques. Povo posta no fórum do UOL e eu ficava vendo qual era o novo truque e fazia uma nova regex pra filtrar o HTML e tirar, por exemplo, o javascript que eles colocavam. Nem precisava tirar tudo, bastava fazer o javascript do cara quebrar pra ele tirar.

Eu saí quando começaram a fazer a funcionalidade de templates de sites, pra facilitar quem não sabia escrever HTML do zero. Eu tinha 23 anos e na minha cabeça esse produto não fazia sentido. Mesmo com banners era muito caro manter o site de todo mundo de graça. Infraestrutura era muito mais cara naquela época do que agora. Mas eu também tava sendo muito cético muito cedo. Eu fiz tudo isso em menos de 6 meses. Mas um conhecido da época daquela primeira agência que fechou foi trabalhar pra uma agência grande de verdade, a F/Nazca, e me convidou pra ir com ele. Dado que eu tava cético com o modelo de negócios, tinha visto os layoffs da PSINet antes, resolvi pular fora do barco.

Seis meses depois o HPG foi vendido pro iG, o que elevou o iG acho que do sexto lugar no ranking pra segundo lugar só atrás do UOL na época. Sabem o que eu falei nos videos sobre startups de engordar o porco? Pra mim isso era uma novidade naquela época, foi a primeira vez que vi o modelo de negócios de gastar muito sem dar lucro, criar hiper relevância, pra ser adquirido caro por alguém maior. Hoje em dia isso é o arroz com feijão das startups. Mas mesmo assim, isso dá certo pra menos de 1% de todo mundo que tenta. Mas os co-fundadores eram todos pessoas bem conectadas no mercado por conta da experiência da STI e do merge com a PSINet. Não eram amadores. Mas eu não conhecia eles pessoalmente, então não tinha noção disso.

Mas tudo bem, eu não tinha stock options nem nada, não ia ganhar nada com a venda de qualquer jeito. Eu era só um programador e acho que tomei uma boa decisão, especialmente porque nesse próximo lugar também ia poder fazer coisas diferentes. A F/Nazca era uma das maiores agências do Brasil na época onde as grandes eram nomes como W/Brazil ou Almap. Hoje são WMcCann, Publicis, Africa, DPZ&T. A Publicis acho que comprou a F/Nazca anos atrás, mas em 2019 o fundador Fabio Fernandez, o “F” em F/Nazca, saiu e acho que iam fechar. O fim de uma era.

E o Fabio Fernandez era publicitário extravagante clichê da época. De novo, era ano 2000, estávamos caminhando rapidamente pro pico da Bolha da Internet. Ninguém sabia que era uma bolha ainda, especialmente porque ninguém sabia direito o que fazer na Web, muito menos agência publicitária. E pra ser o diferentão o Fernandes quis montar uma equipe tipo uma Tropa de Elite da Web, fora dos escritórios da agência. Era uma equipe pequena, nem meia dúzia de pessoas, focadas só em Web, e a gente ia ficar num escritório virtual no World Trade Center de São Paulo.

Pra ter uma noção do que eu quero dizer com extravagante, ele fez um anúncio pra empresa inteira na forma de cartas deixadas na mesa de todo mundo, dizendo que estavam demitidos. Aí acho que ia ter um evento no mesmo dia pra anunciar que na verdade tava todo mundo demitido da “antiga” agência publicitária tradicional mas estavam todos recontratados na “nova” agência Web. Entenderam? Puta piada de mau gosto que acho que rolou vários processos trabalhistas depois. Mas imaginem eu, era meu primeiro dia, e a primeira coisa que ouvi foi que tava demitido e recontratado. Eu achei engraçado na época, mas eu era só um moleque.

Enfim, nessa equipe eu trabalhei em algumas peças em Flash primeiro. Tive que desenferrujar meu Flash e fazer duas peças de campanha que eles iam mostrar em Cannes. Eram umas coisas bem idiotas. Só de exemplo, uma das peças era uma campanha das tintas Suvinil falando sobre suas novas máquinas de misturar tintas pra você ter a cor que quiser.

A idéia era o banner ficar fixo na tela e na verdade o navegador inteiro se mexer pra todos os lados simulando a máquina misturando a tinta. Isso era uma época que Javascript dava controle de tudo do navegador, incluindo a posição no desktop da pessoa. Imagina abrir um site e as janelas ficarem se mexendo do nada. Ainda bem que não pode mais fazer isso.

Enfim, meu chefe nessa época era um gêniozinho um ano mais novo que eu e que manjava muito de tecnologia, o Bruno Mosconi. Foi com ele que aprendi o conceito de que livro não é despesa, é investimento. Ele deixava a gente comprar os livros que precisasse. É uma prática que até hoje eu tenho na minha empresa por causa disso. Mas hoje em dia o acesso a informação desse tipo é muito mais fácil, tem de graça. Na época não tinha. Era ano 2000, Google mal tinha 2 anos ainda.

Lembro que foi a primeira vez que mexi com Python também por causa de um site de astrologia de um cliente, que ele queria implementar num gerenciador de conteúdo chamado Zope. Pra quem é de Python, o Zope depois se tornaria Plone. E foi com ele também que ouvi falar de Ruby pela primeira vez, mas não usei naquele ano ainda. F/Nazca foi o lugar onde trabalhei por menos tempo, só uns 3 ou 4 meses. No HPG também foi pouco, menos de 6 meses. De novo, minha memória não tá muito boa mas acho que essa operação Web não tava dando certo aí eu tive que procurar outro lugar.

Essa foi a primeira vez que realmente tive que procurar emprego. Postei meu currículo na minha homepage do HPG, até tive contatos por lá. Recrutador vasculhando qualquer site existe desde aquela época. Mas de novo, foi por causa dos contatos que fui fazendo ao longo desses primeiros anos que me levaram a algumas boas entrevistas e acabei entrando numa pontocom, que é como chamávamos as startups da época, que foi a PSN, ou Panamerican Sports Network.

Eu contei sobre eles nos episódios de Sua Linguagem Não é Especial, mas recapitulando, a empresa maior era a Hicks, Muse, Tate and Fürst. Pra quem é de futebol, vai lembrar que era a dona do Corinthians e do Cruzeiro no ano 2000. Embaixo tinha sites como a PSN.com junto com o canal de TV a cabo PSN, patrocinava o Alan Prost na Fórmula 1. Pois é, eu fui webmaster do Corinthians. Depois assistam esses outros episódios.

Lembro que cometi minha primeira grande gafe que todo iniciante arrogante faz. Logo na primeira semana, fui olhar o código deles e era um go-horse atrás de outro go-horse. O código foi feito por uma terceirizada americana e foi a primeira vez que entendi que só porque é gringo não quer dizer que é melhor. Puta código zoado da porra. Pensa um ASP macarrônico com HTML misturado com Basic tudo em arquivões de milhares de linhas. Escrevi um e-mail super textão com page downs e page downs de críticas e mandei pra todo mundo sem pensar. Descobri só quando tava pra sair que por causa daquele e-mail todo mundo me odiava no começo. Eu só repeti o que todo mundo já sabia. Uma nova equipe já tinha assumido a zona e já tava consertando, eu que peguei o bonde andando. Fica a dica: Não seja essa pessoa.

Na PSN eu fiquei pouco tempo também, até dezembro de 2001, cerca de 1 ano e meio. E foi lá que tive a oportunidade de ir pros Estados Unidos pela primeira vez, pra conhecer a equipe que trabalhava de Miami. Pra ter uma noção de como faz tempo, não existia celular com internet, pra me localizar eu tinha que imprimir mapas do site da prefeitura da cidade. E pra tirar foto eu tive que comprar uma câmera descartável numa farmácia e mandar revelar. Acabei perdendo essas fotos. Eu só voltaria a viajar pros Estados Unidos quando entrei na Locaweb em 2008, 7 anos depois. Mas em 2001 aconteceram outros dois episódios que me marcaram.

O primeiro foi em setembro de 2001 quando cheguei de manhã cedo no escritório e tava todo mundo na frente das TVs e eu fiquei confuso “o que aconteceu?” Aí vieram me contar “você não viu?? jogaram um avião no World Trade Center”. E eu paralizei e falei “aqui do lado??” Lembrando que na F/Nazca trabalhei de um escritório no World Trade Center, de São Paulo, que fica no bairro do Brooklin Novo, na famosa avenida Berrini que muitos já consideraram o Vale do Silício do Brasil. A PSN ficava num prédio a alguns quarteirões de distância. Pensa meu alívio quando falaram “não, o de Nova Iorque!” ahhhhh então tá, cadê meu café?

E o segundo episódio foi o famoso Crash da Bolha da Internet no mês seguinte, em outubro. Na verdade o pico da NASDAQ foi em março de 2001, onde tinha subido absurdos 400% desde 1995 e em 2001 caiu quase 80% de uma só vez. Ela ainda tentou subir de novo no meio do ano, mas aí veio a segunda perna do crash e a partir daí não parou mais de cair até quase o fim de 2002. Eu não tinha idéia do que isso significava. Na PSN nos disseram que descobriram que alguns executivos tavam roubando, negócios ruins, e o fechamento do canal de TV, das operações na Web. Eu quase apaguei a luz do escritório por último.

Eu não era muito informado com as notícias. Não acompanhava nada de mercado financeiro. Pra mim, essa bolha que começou em 1995, quando eu entrei na faculdade, parecia tudo normal. Só depois do fechamento abrupto da PSN que me toquei que na verdade eu tava no meio de uma bolha e nem tinha me dado conta. Notaram que desde 1996 eu fui indo de trabalho em trabalho sem nenhuma real dificuldade? Eu ia conhecendo pessoas, elas gostavam do meu trabalho, me indicavam ou me chamavam pro próximo negócio e eu só ia seguindo a vida assim.

E essa seria a segunda vez que eu ia ter que procurar emprego. Fiquei só uma semana desempregado. Mesmo com o crash da bolha, não significa que acabou todos os empregos. É isso que eu quis dizer no video do Crash da Bolha de agora também. Toda empresa, seja ela de tecnologia ou não, a partir de agora ia precisar manter essa tecnologia e evoluir, mesmo que fosse mais devagar.

De novo, mandei alguns emails e quem respondeu foi o Antelio, que eu falo no episódio de SAP, engenheiro que conheci naquele projetinho da agência na Camargo Corrêa. Ele saiu, virou consultor SAP e me chamou pra trabalhar. Ele ia me ensinar SAP e eu ia ensinar Web pra eles. Convenientemente, o escritório da consultoria era no mesmo prédio onde ficava a PSN que tinha acabado de fechar, só mudei de andar. Eu passei mais de meia década nessa região da Berrini.

Lembram do projetinho da STI pra resolver o problema de ano 2000? Obviamente ela não foi a única empresa com esse problema. Literalmente toda empresa que adotou tecnologia dos anos 80 e 90 tiveram que ajustar seus sistemas, ou investir em modernizar e substituir por coisas novas com eu fiz. Mas em empresas gigantes, não dava pra refazer tudo do zero. E foi aí que empresas como SAP ou Oracle ganharam terreno no Brasil. Foi a era de ouro das consultorias pra implementar novos ERPs não só pra resolver o problema no bug do milênio como implementar novos processos e tecnologias. Eu conto um pouco disso no episódio de SAP, depois dêem uma olhada.

E lá ia eu aprender mais uma plataforma que nunca tinha imaginado que ia ter que aprender: SAP. Mas tudo bem, de 1996 até fim de 2001 eu tive que aprender Delphi, HTML, Javascript de primeira geração, Flash, ASP, PHP, Perl, SQL Server, MySQL, Apache, um pouco de Python. O que é um pouco de SAP? E nesse período entre 2002 a 2006 eu ia voltar a usar tecnologias Microsoft como ASP e finalmente usar Java comercialmente.

Durante a depressão na área de novas tecnologias que ia durar de 2002 a 2008 eu fiquei focado em mercado corporativo com integração de SAP com Web, depois migrei pra tecnologias open source com Ruby on Rails em 2006 e me preparando pra pegar a nova onda que eu nem sabia que ia recomeçar com mais força por volta de 2008. Foi quando começou a aparecer Twitter, Uber, Airbnb, Pinterest, Foursquare, Spotify, Netflix e todos os nomes que vocês conhecem hoje.

De novo, não é porque teve crash da bolha que a tecnologia parou. Foi entre 2002 a 2008 que as sobreviventes se consolidaram. Google e Amazon viraram gigantes nesse período de seca. Foi nesse período que blogs e redes sociais nasceram. Muitos tentaram e morreram, Orkut, MySpace, e aí apareceu o Facebook, depois o Instagram. Mas o ecossistema maior mesmo só apareceria depois do Crash da Bolha Imobiliária de 2008. A correção desse crash criaria o ambiente propício de juros baixos e dinheiro fácil pra investimento que seria o combustível pra bolha que duraria até agora. De novo, assista minha playlist “Eu Avisei” onde explico detalhes de porque.

Eu não sou um guru, não prevejo o futuro, nem nada disso, eu sou um animal muito simples: eu gosto de tecnologia, alguém quer me pagar pra mexer com tecnologia, eu vou, só isso. Foi só isso durante toda minha carreira. Veja: minha carreira nasceu numa época que precede o conceito de influencers, de cursos online, de redes sociais. O primeiro evento de programação que eu participei foi a RailsConf nos Estados Unidos em 2008. Eu já tinha 31 anos e fazia 13 anos que entrei na faculdade. Só aí passei a interagir mais com as comunidades de desenvolvimento de software. É o que eu conto no video da História do Ruby on Rails.

Eu entendo o problema de todos vocês hoje: sofrem de information overload. Tem informação demais, pior, muita informação conflitante e ruim mesmo. Um influencer diz pra seguir caminho X, outro influencer diz pra seguir caminho Y, o grupo do Discord fala que caminho X é uma bosta, pessoal do Telegram fala que caminho Y é uma bosta, na sua timeline do Twitter tem caminhos de A a Z e nenhum consenso. Eu consigo imaginar o turbilhão de incertezas infladas que tem na sua cabeça nesse momento.

Pare um segundo e pense: eu, Akita, estou perto de aposentar uma carreira que começou em 1990. Informação naquela época era muito cara, de difícil acesso. Porra, se eu não tivesse me dedicado sério a aprender inglês, como conto no video sobre inglês, não teria conseguido fazer nada do que resumi nesse video. Tudo que eu aprendia só tinha disponível em inglês, não tinha a opção de português. Conseguem imaginar isso?

Mais do que isso: só conhecia outros programadores que trabalhei junto nessas empresas e projetos. Não conhecia outros programadores de fora, então não tinha nenhum modelo, ninguém pra me influenciar e, felizmente, ninguém que eu achava que precisava seguir. Eu simplesmente fazia as coisas por pura intuição.

Mais felizmente ainda: não existiam coaches falando bullshitagem sobre coisas como networking. Eu aprendi a fazer networking de verdade. Por exemplo, na época da STI e HPG tenho dois exemplos: tinha dois programadores júniors como eu na equipe. Um se chamava Fernando Nemec. Depois do HPG ele foi trabalhar como programador na recém criada parte web do jornal Folha de São Paulo. Hoje ele é o diretor de tecnologia da Folha Online.

O outro se chamava Adriano Caetano. Depois do HPG ele abriu seu próprio ecommerce, um dos primeiros do Brasil, chamado LinuxMall. Eu comprei muitos CDs de Linux com ele. Hoje ele é Sócio Diretor da VTEX, uma das primeiras plataformas de ecommerce e uma das maiores do Brasil. Coincidentemente saiu um video dele contando essa história no YouTube, vou deixar o link na descrição.

Vocês ficam olhando pra caras como eu e esquecem que o júnior da sua própria equipe, colega da sua faculdade, vai ser o próximo founder, CTO, CEO da startup inovadora de amanhã. Ele confia no resultado do seu trabalho hoje o suficiente pra te chamar pra trabalhar com ele? Se você não consegue impressionar nem o júnior que trabalha do seu lado, porque você acha que eu me interessaria? Só porque você fez mandou um email engraçadinho no LinkedIn? Ou porque ficam só no blá-blá falando que é esforçado? Sério?

É difícil resumir mais de 5 anos em um video curto como esse, mas meu ponto era mostrar o seguinte: principalmente no começo de carreira, eu nunca me defini como “programador ASP” ou “programador Java” ou “administrador de SQL Server”. Minha especialidade não era nenhuma dessas ferramentas. Sem planejar muito, eu só me especializei em resolver problemas de tecnologia. Minha arma secreta foi Aprender a Aprender. Eu simplesmente gosto de tecnologia e de resolver problemas com tecnologia.

Nunca parei pra pensar: “será que esse tal de ASP vai ter carreira pros próximos 10 anos?” ou pior “será que esse tal de Director e CD-ROM é uma boa carreira pros próximos 10 anos?”. Eu literalmente aprendia e produzia numa plataforma nova todo ano durante esse período. Se em 1996 eu tivesse pensado “puts, esse tal de ASP é muito novo, não dá pra ter uma carreira nisso, vou ficar no Clipper, vou ficar no Director”, e daí se toda vez eu esperasse 2 ou 3 anos “pra ver se ia vingar”, teria perdido a primeira Bolha da Internet, pior, teria sido mais uma vítima do crash.

Eu passei totalmente ileso. Quando migrei de pontocom com ASP pra mundo corporativo com Java e SAP, na minha cabeça isso não era um passo pra trás ou um downgrade. Era só mais uma página. Porque eu não era definido pela linguagem, ou modelo de negócio. Vejam como o Java que fui aprendendo aos poucos desde 1996 viria a se tornar útil em 2002 quando entrei em consultoria. Vejam como o ASP que aprendi de sopetão em 1999, deixei de lado pra aprender PHP em 2000, voltaria em 2001 na PSN. Não existe uma receita. E não existe falta de oportunidade, existe falta de vontade de pegar pra resolver. Ah, vou fazer um curso, quando eu aprender daí vou procurar. Aí já é tarde demais, o bonde já andou e você ficou no fim da fila.

No episódio da Sua Linguagem Não é Especial, eu mostrei como não ficava também só fazendo o que o trabalho exigia. Em 2000 eu tava um pouco empolgado com .NET que tava pra sair, acho que tava em Beta nessa época. No trabalho ninguém ia usar .NET, mas fiz minha própria versão de um mini framework ASP.NET só que em ASP clássico, só pra ver se dava. Que não foi diferente de quando tentei aplicar orientação a objetos no Lingo de Director alguns anos antes. Eu não fazia o que o livro dizia, só queria ver o que dava pra fazer. Na minha cabeça nunca teve o conceito de “não é assim que todo mundo faz”. Eu sempre tô cagando e andando pro que “todo mundo” faz.

Notem outra coisa: em nenhum momento eu cito cursos. Porque eu nunca fiz nenhum. Primeiro que não existia Udemy nos anos 90. Segundo porque intuitivamente entendia: porra, Java saiu ano passado, obviamente não tem curso pra isso. Flash acabou de sair enquanto eu tô aqui fazendo Director, óbvio que não tem curso pra isso. Eu nunca esperava que fosse ter um curso. Eu via que tinha um livro, em inglês, ia na Livraria Cultura no Conjunto Nacional da Avenida Paulista, a única que eu sabia que dava pra encomendar livro importado, esperava um mês pra chegar e era isso. Amazon foi só a partir do ano 2000.

Outra coisa: quando falei que tava aprendendo sobre orientação a objetos. O livro de Design Patterns do Gang of Four tinha acabado de ser lançado em 1994. UML também tinha acabado de ser inventado. Essas coisas ainda não eram consenso. Existiam várias metodologias antes da Rational. Eu, por exemplo, tinha um livro de uma metodologia chamada Fusion. Mas pelo jeito não fez sucesso porque como isso precede o Google, nem tem registro se pesquisar a respeito.

O Manifesto Ágil seria assinado em 2001 que é quando eu termino minha história nesse video. Tudo sobre o assunto só seria publicado depois. O ponto é: eu, aluno de faculdade em 1995, não tinha como saber que essas coisas se tornariam relevantes anos depois. O você de hoje tentando escolher a ferramenta “ideal” não tem idéia do que realmente vai ser importante daqui 5 anos. Não tente adivinhar agora, é perda de tempo. E não, nenhum guru, influencer, coach, nem mesmo eu, tenho como dizer o que vai ser relevante daqui 5 anos especificamente pra sua carreira, porque a carreira de cada um vai ser diferente.

E antes que alguém vá encher o saco na bolhadev, quando eu falo que varava noite na época, não foi pra vangloriar que trabalhar a noite é admirável. Pelo contrário, eu varava noite porque eu não era bom e prometia mais do que conseguia entregar. Eu só era sem noção mesmo. Isso é pessoal, não recomendo ninguém copiar. Vai de cada pessoa. Com cabeça de hoje, talvez tivesse dito mais “não”. Mas por outro lado talvez não tivesse aprendido tanta coisa tão rápido.

Com 20 anos, meu objetivo não era ter qualidade de vida, era aprender tudo que pudesse aprender porque minha única motivação era resolver problemas novos. Cada pessoa tem motivações diferentes, nunca use minha história como parâmetro pra sua. As épocas são completamente diferentes. Vocês tem mais opções hoje do que eu tinha nos anos 90.

Falando do povo comentar, não sei se notaram, mas nenhuma das empresas que eu trabalhei nesse período existem mais. Eu literalmente saía pra outro trabalho porque onde eu tava ia fechar. Uma vez só eu saí por conta própria, mas de 1996 até 2002 esse foi o padrão. Foi bizarro, já tava achando que eu tinha pé frio. Magina, mandar meu currículo e o recrutador ver que nenhum lugar existe mais. Mas não foram só as empresas que eu passei, no Crash, várias outras foram fechando ao longo do tempo. Muitas das empresas que a gente conhecia naquela época não existem mais. É a vida.

De qualquer forma, se pudesse mudar alguma coisa que fiz desde os anos 90, não mudaria nada. São as experiências que passei, boas ou ruins, que formam o que sou hoje. Foi fazendo merda, aprendendo a consertar e persistindo, que me definiu. Agora cada um de vocês tem que achar o que define vocês, e não vai ser me copiando. Os anos 90, infelizmente, acabaram. Os anos 2000 acabaram. Os anos 2010 acabaram. Os anos 2020 acabaram de começar, é nesse contexto que você existe.

Finalmente, alguns poderiam ficar impressionados. Pode parecer que fiz muita coisa nesse meu começo de carreira. Mas nem tanto, num outro extremo, lembram que falei que 1997 foi quando Steve Jobs retornou pra Apple? Pois bem, nesse meio tempo, ele limpou a casa, tirou a Apple da beira da falência, modernizou a linha de hardware lançando os famosos iMacs coloridos, finalmente conseguiu matar o antigo MacOS 9 e lançar o MacOS X que é a base dos Macs até hoje, e no ano que a bolha estourou, lançou o iPod, que mudaria a indústria de música pra sempre. Tem um documentário chamado The iPod Revolution que conta exatamente esse trecho da história, depois assistam, é fascinante.

Muito ou pouco é relativo. Parem de ficar se comparando, que coisa chata. Façam sua própria carreira, do seu jeito, e evoluam cada dia pra não se arrepender do dia anterior, só isso. Eu não virei o Steve Jobs, e tá ótimo, o que eu consegui fazer por mim durante minha carreira me deixa satisfeito. Poderia ter feito muito mais. Sempre dá pra fazer mais. Mas Akita, o que você recomenda pra mim? É a pergunta que eu mais recebo, e repetindo pela enésima vez, veja meu video de Não Terceirize suas Decisões e a playlist de carreira.

Eu sei que mesmo dizendo isso vocês ainda vão continuar me perguntando o que devem fazer, ou falar que vão tentar me copiar, mesmo eu falando não. Mas vamos aos fatos: eu disse pra vocês fazerem imersão de inglês em casa, substituir tudo por inglês. Acabei de mostrar a diferença que fez no meu começo de carreira. Como anda o inglês de vocês?

Agora o mais óbvio, em vez de perguntar o que eu fazia, que tal perguntar o que eu não faria? Uma coisa que me lembrei escrevendo esse episódio é que a primeira balada que eu fui foi só por volta de 2002 ou 2003. Foi quando comecei a beber socialmente também. Lembrem, entrei na faculdade em 1995. Fui em uma festa na faculdade, uma única cervejada. Não participei de nenhum evento, festa ou balada de 1996 até 2002, que é o período que cubro neste video.

Por que? Primeiro porque não tinha dinheiro. Eu começar a sair coincide com minha transição de júnior pra pleno e ganhar salário de consultor corporativo. Faz muita diferença. Além disso tinha tanta coisa tão interessante acontecendo no trabalho toda hora, cada hora um bug mais cabeludo pra resolver, eu passava minhas noites dormindo no escritório. E não porque me mandavam, mas porque eu não queria ter que perder tempo indo pra casa e tendo que voltar depois. Meu PC do escritório na época era sempre melhor que meu PC de casa. E não tinha laptop acessível, então tinha que usar lá mesmo. Eu preferia ficar lá.

E mais, que séries eu maratonava na TV nos anos 90? Literalmente não consigo me lembrar de nenhuma. Depois que entrei na faculdade, quase não assistia TV. Recomecei a ver séries só lá por 2004 ou 2005 com Os Sopranos e 24. Lembram que falei que não tinha nenhum influencer que seguia? Vocês perdem horas e horas diariamente acompanhando gente desinteressante e irrelevante que não contribui em absolutamente nada na sua carreira. Eu não tive isso, portanto tive a vantagem de não perder meu tempo com gente inútil. Eu só gastava tempo comigo mesmo.

Teria sido melhor se essas coisas existissem naquela época? Google sim, sem sombra de dúvida, pra pesquisar as coisas mais rápido. Stackoveflow também. Todo o resto, principalmente a bolhadev? Absolutamente inútil. A opinião aleatória dos outros é inútil. Ninguém sou eu. Eu teria conquistado menos da metade do que fiz nesse período.

Podcasts de 3 horas, vai se fuder. Em 3 horas eu li a documentação inteira de uma nova linguagem. 3 horas todo dia? Porra. Quando você vai no banheiro? Ah, mas é quando eu tô no metrô voltando pra casa ou no trânsito. Ouça audiobooks de livros clássicos, de mais de 10 anos que ainda são relevantes hoje, não ebookzinho de influencer bosta que nem tem 10 anos de carreira direito. Já leu algum livro do Stroustrup, criador do C++? Ou do Dennis Ritchie, criador do C? Por que ainda não leu os originais em vez de ler as cópias baratas? Fica só falando de IA, IA, já leu alguma coisa do Marvin Minsky? Não né.

E esse foi o episódio do meu começo de carreira, que coincidiu com a ascenção e queda da primeira Bolha da Internet. E como podem ver, eu continuei crescendo sem parar. A próxima fase, pra quem quiser ver como foi, é o video de SAP, depois o video de Ruby on Rails. E por hoje é isso aí, se ficaram com dúvidas mandem nos comentários abaixo, quem quiser relembrar mais coisas dos anos 90 não deixem de mandar também, se curtiram o video deixem um joinha, assinem o canal e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais!

Este episódio levou literalmente MESES pra eu conseguir fazer. Entre atualizar o hardware da minha máquina, testar todo tipo de combinação de configuração, até conseguir rodar jogos da Steam, num Windows virtualizado, a quase mesma velocidade que nativo.

Hoje vamos entender o que é QEMU, KVM, Libvirt, como passar uma GPU da NVIDIA diretamente pra dentro de uma VM, e como garantir a máxima performance na virtualização, incluindo entender como diversos componentes de hardware e do Linux funcionam.

Este conteúdo vai ser DENSO, então não deixem de usar os capítulos abaixo pra se orientar e consultar todos os links que deixei listado aqui.

Capítulos

• 00:00:00 - Intro
• 00:00:44 - Cap 1: Meu Setup (até 2024, senão podem pular)
• 00:05:51 - Cap 2: Introdução à Virtualização | Por que não Dual Boot?
• 00:08:26 - Cap 3: O que é IOMMU | Setup das GPUs
• 00:13:46 - Cap 4: Redes Virtuais | Minha placa 10 Gigabits
• 00:17:57 - Cap 5: Criando a Máquina Virtual | Virt-Manager
• 00:19:51 - Cap 6: Recapitulando UEFI | O que é OVMF?
• 00:23:06 - Cap 7: Entendendo CPUs | Pinagem de CPUs
• 00:33:01 - Cap 8: O que é QEMU? E KVM? | Libvirt
• 00:38:58 - Cap 9: Limitando CPUs do Host | Cgroups
• 00:43:06 - Cap 10: Configurações de Performance | Features Importantes
• 00:45:32 - Cap 11: Monitor Virtual e Streaming | SPICE e QXL
• 00:47:22 - Cap 12: Configurando Áudio | Pulseaudio e Pipewire
• 00:50:01 - Cap 13: PCI Passthrough | NVIDIA GPU
• 00:50:27 - Cap 14: Keyboard, Video, and Mouse | KVM via EVDEV
• 00:52:47 - Cap 15: Instalando Windows em Disco VirtIO | Fedora VirtIO ISO
• 00:57:15 - Cap 16: Demonstrando Performance com Games | GPU Passthrough
• 00:57:53 - Cap 17: Anti-Cheat em Elden Ring | Dual Boot
• 01:00:24 - Cap 18: Lidando com Monitor com 2 Inputs de Video | Escolhendo Inputs
• 01:03:08 - Cap 19: Lidando com Suspend do Host | Desligando Suspend
• 01:05:04 - Cap 20: Conclusão | Mais Coisas
• 01:07:49 - Bloopers

Links

• https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF
• https://wiki.gentoo.org/wiki/GPU_passthrough_with_libvirt_qemu_kvm
• https://github.com/virtio-win/kvm-guest-drivers-windows
• https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.229-1/
• https://github.com/rockowitz/ddcui
• https://github.com/rockowitz/ddcutil/issues/35
• http://www.ddcutil.com/commands/
• https://github.com/olavmrk/usb-libvirt-hotplug
• https://getlabsdone.com/how-to-install-windows-11-on-kvm/#Add-the-windows-11-virtio-driver
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/virtualization_administration_guide/sect-virtualization-adding_storage_devices_to_guests-adding_hard_drives_and_other_block_devices_to_a_guest
• https://linuxhint.com/install_virtio_drivers_kvm_qemu_windows_vm/
• https://www.tecmint.com/manage-kvm-storage-volumes-and-pools/
• https://passthroughpo.st/simple-per-vm-libvirt-hooks-with-the-vfio-tools-hook-helper/
• https://www.libvirt.org/hooks.html
• https://archlinux.org/packages/extra/x86_64/qemu-emulators-full/
• https://unix.stackexchange.com/questions/30106/move-qcow2-image-to-physical-hard-drive
• https://libguestfs.org/virt-resize.1.html
• https://www.cyberithub.com/resize-qcow3-image-with-virt-resize-kvm-tools/
• https://loc-clan.com/files/win10
• https://www.reddit.com/r/VFIO/comments/l8g6iy/pc_suspends_itself_while_in_vm_due_to_suspend/
• https://www.linaro.org/blog/the-evolution-of-the-qemu-translator/
• https://github.com/foxlet/macOS-Simple-KVM
• https://github.com/foxlet/macOS-Simple-KVM
• https://passthroughpo.st/explaining-csm-efifboff-setting-boot-gpu-manually/
• https://passthroughpo.st/explaining-csm-efifboff-setting-boot-gpu-manually/
• https://github.com/vanities/GPU-Passthrough-Arch-Linux-to-Windows10
• https://github.com/rockowitz/ddcutil/issues/35#issuecomment-337919874

SCRIPT

Olá pessoal, Fabio Akita

Video de hoje vai ser mais pra mim do que pra vocês. Quem me acompanha no Insta sabe o que eu ando mexendo e alguns meses atrás viram que eu estava brincando com upgrade no meu PC, NAS e, principalmente, PCI passthrough da GPU pra máquinas virtuais. Quero mostrar como ficou, como estou usando, mais ou menos os principais conceitos envolvidos. Embora não seja um passo a passo, vou explicar coisas que normalmente não se vê numa instalação normal de Linux e detalhes sobre como um PC funciona. Mais importante, vou explicar todos os componentes pra rodar máquinas virtuais em Linux e como elas funcionam. Se queria aprender mais sobre virtualização, hoje é o dia.

(…)

Eu já fiz dois videos falando do meu setup anterior então assistam depois. Mas agora estou com um PC bem potente, com CPU AMD Ryzen 9 5950X de 16 núcleos ou cores e 32 threads, 2 pentes de memória DDR4 de 4 Ghz funcionando com perfil XMP, ou seja, com overclock, da G.Skill, placa mãe Aorus X570S. Não é a melhor placa mas dá conta do recado. Ela tem 2 slots M.2 pra NVME que é SSD muito mais rápido, um Samsung 970 Evo Plus de 2TB onde tá instalado Windows 11 nativamente como dual boot e outro NVME primário Samsung também de 1 TB onde está meu Manjaro GNOME.

Além deles preenchi 3 slots SATA com SSDs normais Samsung modelos 860 e 870 de 1 TB que uso só pra cache do DaVinci Resolve, outro de 4TB que era meu antigo drive pra jogos da Steam e que recentemente encheu então comprei um de 8TB pra mover tudo pra lá. Vou fazer esse de 4TB ser meu novo cache pro DaVinci por enquanto. Óbvio que não precisa de tudo isso só pra cache, mas não tenho outro uso pra ele por enquanto, então beleza.

O Linux boota usando a GPU primária da AMD, um modelo fraquinho que é o RX 6400. Essa placa não é muito melhor que uma antiga NVIDIA GTX 1050 de 2016. Mas é mais do que suficiente pra coisas como tocar video 4K sem perder frames, renderizar aplicativos de produtividade como terminal ou editor de texto. Só pra programar e navegar na Web é muito mais do que suficiente. Mas obviamente é  imprestável pra games mais pesados que um CS:Go. 

Pra renderização pesada de video quando edito os episódio do canal com DaVinci Resolve, ou pra brincar de modelagem 3D com Blender ou pra jogos pesados como God of War da vida, aí tenho uma GPU secundária que fica desligada no Linux. A NVIDIA RTX 3090 com 24 Gigabytes só de memória de video. Esse sim é um monstro. 

Recentemente saiu a RTX 4090 que tem quase o dobro da performance da minha, mas também custa o dobro do preço, usa muito mais energia e ocupa quase o dobro do espaço dentro do gabinete, e pra funcionar decentemente o certo seria trocar minha placa mãe pra uma que suporte memória DDR5 e trocar minha CPU da série 5000 pra nova série 7000 que também acabou de sair pra não ter gargalo. Na prática o custo-benefício ainda não compensa. Vou fazer esse upgrade só daqui mais uns 2 anos.

Falando em resolução, eu uso setup de dois monitores, a principal é a Asus ROG TUF de 31", resolução de 2160 por 1440 pixels, ou seja, 2K a 144 hz. O topo de linha pra gamer seria um monitor de micro LEDs 4K de 300 hz HDR+, mas pro meu uso tá mais que bom. Eu não participo de esports então mais que 1440p e 144hz eu nem ia perceber tanta diferença e só ia pesar mais na GPU. Nessa configuração consigo jogar qualquer jogo pesado da Steam em Ultra High com Ray Tracing e ainda ter mais de 100 frames por segundo.

Meu monitor secundário é um Samsung de 29" 4K e 60hz. Esse eu exagerei um pouco. É o monitor que uso na vertical pra deixar coisas como meu Discord, Gmail, gráficos da bolsa e coisas assim pra ficar dando uma olhada. Poderia ser um monitor de 24" e não precisava ser 4K porque uso em 1440p pra ficar igual ao principal. Enfim, o resto não é importante pro video de hoje mas só pra ficar completo, tenho um microfone BM 800 e uma webcam Logitech Brio de 1080p de resolução. Não sou, nem quero ser podcaster nem streamer. Pra calls de Zoom tá mais que bom.

Pra áudio, em vez de usar o que vem na placa mãe liguei um DAC externo da Topping via USB. DAC é um conversor digital pra analógico. Ele recebe o áudio digital via USB e converte em onda pra mandar pra um pre-amp, que pega esse áudio analógico convertido com sinal baixo e amplifica pra nível de linha pra mandar pras caixas de som ou fone de ouvido. As caixas de som não nem nada de especial, são 2 Edifier. Pra usar na mesa perto de mim é o suficiente. Já o fone que uso é um Sennhaiser HD 650 que é um modelo de entrada pra quem quer um som de referência, não modificado.

Meu mouse é um Logitech MX Master 3 sem fio, o melhor mouse de produtividade que existe. Super confortável e excelente pra trabalhar em edição de video por exemplo. Ele não é feito pra jogar, embora nada impeça. Um mouse gamer tem metade do peso desse Logitech Mas como falei, não participo de esports e também não jogo FPS. Não curto Valorant, Apex Legends, Overwatch nem nada disso. Só jogo single player e com gamepad. E gamepad os meus preferidos são o de Xbox One X, depois o modelo SN30 pro+ da 8BitDo que compartilho com meu notebook, e o de PS4 pra emuladores como Dolphin ou CEMU pra jogos da Nintendo porque gamepad de PS4 tem acelerômetro e giroscópio, coisa que do Xbox não tem.

Todo mundo que acompanha o canal sabe que sou um sommelier de teclados e meu favorito até hoje é o Moonlander da ZSA. Dá bastante trabalho pra treinar e se acostumar, mas depois que aprendi realmente a usar um teclado split, separado no meio, com layout ortolinear, não consigo mais voltar pra um teclado normal. Eu sofro um pouco quando preciso usar do notebook. Quem não sabe o que é isso, assista meu terceiro video sobre teclados, que explico em detalhes.

O objetivo hoje é eu conseguir instalar uma máquina virtual Windows em cima do meu Manjaro e passar a GPU da NVIDIA inteiramente pra ele. Meu Manjaro continua funcionando normalmente via a GPU da AMD, e na máquina virtual a RTX 3090 vai ficar exclusiva só pro Windows virtualizado. Muitos podem se perguntar “ué, mas não é mais fácil só fazer um dual boot?” E sim, é mais fácil mesmo. Mas vejam esta tela do programa Virt Manager que eu instalei. 

Tudo isso são máquinas virtuais. Eu tenho uma instalação de Garuda que é outra versão de Arch Linux mais voltado pra gamers. Eu tenho um Ubuntu que uso pra testes e eu tenho 4 instalações de Windows 11. Uma que está como dual boot, instalado numa NVME e outras 3 que rodam num disco virtual em rede. Eis porque eu não queria só depender de dual boot: queria poder instalar outros Windows pra tarefas ou testes diferentes em separado, sem ter que reparticionar meu SSD toda hora e ficar reconfigurando dual boot. Do jeito que fiz, posso instalar um novo OS virtualizado a qualquer momento, ou destruir também, sem afetar a estabilidade do meu sistema.

Veja que tenho um MacOS também. Infelizmente é lento porque Apple parou de dar suporte pra GPU da NVIDIA faz alguns anos. Só GPUs antigas da NVIDIA funcionariam, como a GTX série 1000 de mais de 5 anos atrás, e só até o MacOS Mojave de 2021. Simplesmente não existem drivers pra usar a RTX 3090 num Mac. Pra conseguir acelerar esse MacOS virtualizado precisaria passar a GPU da AMD, mas como é minha principal, que o host Manjaro usa, ia ficar complicado então por enquanto não vai rolar Mac.

Falando em suporte de hardware e abrindo a página de PCI passthrough do ArchWiki, a primeira coisa que ele vai explicar é que precisa checar se o meu hardware suporta o que precisa. A primeira coisa é mais óbvia, minha CPU precisa suportar instruções de virtualização o VT-x ou VT-d. Tem que entrar na BIOS e checar se tá ativado. Muitas vezes vem desligado. Hoje em dia toda CPU suporta sem problemas, mas CPUs de uns 5 anos ou mais pra trás, é bom checar. No Wiki também fala sobre modelos de placa mãe. Mas de novo, só se preocupa com isso se seu hardware for muito velho.

Os passos 1, 2 e 3 do Wiki podem ser automatizados por essa ferramenta gpu-passthrough-manager, instala com yay ou pacaur ou seja lá qual gerenciador de AUR você usa. Eu gosto do yay. Ele vai fazer duas coisas importantes: configurar a linha de comando que carrega a kernel no boot pra habilitar IOMMU e depois que rebootar, vai separar a GPU da NVIDIA pra não carregar mais os drivers no boot, já que precisa estar desligado pra passar pra máquina virtual. Vamos entender.

IOMMU, ou Input Output Memory Management Unit é um recurso que ligamos na kernel e que a CPU por baixo precisa suportar. A grosso modo é assim, a CPU e dispositivos como teclado ou placa de video, normalmente se comunicam via endereços de memória direta entre um e outro. O problema é que se a CPU de verdade já está falando com o dispositivo, não teria como outra CPU virtual compartilhar os mesmos dispositivos. 

Em vez disso o controlador de IOMMU cria endereços virtuais que mapeiam pros reais e esses endereços virtuais podem ser passados pra máquinas virtuais, dando acesso direto aos dispositivos sem ter que passar pela CPU host pra intermediar essa comunicação. Isso é crucial pra máquina virtual conseguir falar diretamente com a GPU ou com outros dispositivos, por exemplo se colocar uma segunda placa de rede de verdade no PC, poderia passar inteira pra máquina virtual.

O Wiki explica como ligar isso, mas depois pede pra criar um script com esse código aqui e executar. O resultado vai ser algo parecido com isso aqui. Esses são os diversos grupos de IOMMU que meu sistema organiza. O que me importa é este Grupo 30 que tem só dois dispositivos, a RTX 3090 e um controlador de áudio também da NVIDIA. E o importante é que não tem mais nenhum outro dispositivo compartilhando o mesmo grupo. Se tivesse, na hora de passar a NVIDIA pra máquina virtual precisaria passar o outro dispositivo nada a ver junto, e dependendo do que fosse, poderia ter problemas. O ideal é estar assim: o que eu quero passar, isolado num grupo separado. Significa que passamos pelos pré-requisitos, meu hardware suporta o que quero fazer.

Até esse ponto, se fizer uma instalação normal de Manjaro, o identificador de hardware acha tanto minha AMD RX 6400 quanto a RTX 3090 e carrega os drivers dos dois. Mas pra poder passar pra máquina virtual, preciso que no boot, o driver da NVIDIA não seja carregado. Pra isso vamos usar um truque: carregar um driver dummy, de mentira, que vai se pendurar e bloquear a GPU. Pra isso usamos um driver VFIO que é um módulo que vem na kernel do Linux. Aquela ferramenta que falei antes, o gpu-passthrough-manager vai fazer isso pra gente, só selecionar os dois dispositivos da NVIDIA e deixar ele fazer o trabalho. Na Wiki tem o jeito manual também, mas vou pular.

Agora chegou a hora de instalar e configurar o software de virtualização propriamente dito. Precisamos dos pacotes qemu-desktop, libvirt, edk2-ovmf e o virt-manager. Pra rede precisa do pacote dnsmasq. Quando instalar tudo, só habilitar o libvirt pro SystemD carregar no boot com sudo systemctl enable libvirtd e já dar start nele também. Pronto, do ponto de vista de preparo e instalação já tá tudo pronto. Agora é a parte divertida, configurar a máquina virtual propriamente dita.

Uma máquina virtual vai se conectar com os mesmos dispositivos que seu Linux Host, o que boota nativamente de verdade, no caso o meu Manjaro. Coisas como os NVME  posso deixar outra máquina usar, se e somente se, não estiverem montadas. Lembra a diferença? Uma coisa é um dispositivo como /dev/nvme1n1 outra coisa é o ponto de montagem /mnt/blabla que aponta pra uma partição no device. Se ficou confuso é porque você pulou meus videos de Linux onde explico isso. Se não sabe como Linux boota e como funciona por baixo, não vai entender nada deste video também. 

Enfim, o ponto é que é possível passar dispositivos de armazenamento entre meu host e o guest contanto que só um deles tenha pontos de montagem. Aliás, pra facilitar, vou dizer host sempre que me referir ao meu Manjaro principal, e guest ou convidado é a máquina virtual. Continuando, dispositivos USB como teclado, mouse, hubs e tudo mais suportam hot swap. Isso deve ser intuitivo, podemos desconectar e reconectar que o OS reinicializa a quente, sem precisar rebootar. Quando ligamos um dispositivo USB no guest, é como se estivéssemos tirando o cabo do host e ligando no guest.

Placa de video só dá pra passar via grupo de IOMMU e se estiver descarregado, ou seja, com o driver stub de VFIO bloqueando. O driver VFIO é como se fosse um plugue esperando a tomada da máquina virtual ligar nele, saca? Só aí que a placa mãe vai ser ativada. Os monitores, por sua vez, via cabo HDMI ou DisplayPort estão conectados fisicamente nas placas de video e não na placa mãe, então quem controla os monitores são as placas de video. 

Cada monitor suporta ligar vários cabos de entrada neles. Normalmente só ligamos um, mas já devem ter visto este menu que permite selecionar input sources diferentes, as diferentes portas na parte de trás. É assim que dá pra compartilhar um monitor com mais de um computador e ficar alternando os sinais de entrada. Meu monitor secundário vertical, o Samsung, tá ligado na placa da AMD. Meu monitor principal, o Asus, também tá ligado no AMD, então no boot o Wayland vê os dois e configura setup de extensão do meu desktop. 

Antes que alguém pergunte, pra ter papel de parede que enche os dois monitores desse jeito uso um programa chamado HydraPaper. Ele funciona via esse programa gráfico mas também dá pra chamar via linha de comando, daí não é difícil fazer um script pra colocar no cron e assim mudar o papel de parede de tanto em tanto tempo. Fica de exercício pra vocês. Voltando, esse monitor Asus também tem outro cabo HDMI ligado nele, que se conecta com a placa de video da NVIDIA, que neste momento permanece desligado. Já já vamos acordar ele.

Mas não é só com placa de video que preciso me preocupar. Esqueci de mencionar, mas minha placa mãe X570S vem com uma placa de rede embutida de 2.5 Gigabits por segundo, que é excelente já que a maioria dos PCs e notebooks no máximo vem com placa de 1 Gigabit. E lembrando que 1 Gigabit é mais que suficiente pra maioria das pessoas porque a conexão de internet de provedores ainda é faixa de 100 megabits, ou seja, 1 Gigabit é 10 vezes mais banda do que precisa pra uma pessoa assistindo YouTube. Mas pra editar video via rede é pouco. Eu explico sobre isso nos videos da mini-série de redes vejam lá depois.

Eu queria poder guardar os videos que gravo pro canal, que são em 4K formato DNxHR, que é pouco comprimido pra manter qualidade, no NAS e apontar o DaVinci Resolve direto pra uma pasta de rede aberto nesse NAS. Assim não preciso ficar copiando os arquivos pro meu PC e depois copiando de volta pro NAS. Pra isso a velocidade entre os dois precisa ser alta. Por isso resolvi comprar um switch e uma placa de video PCI Express de 10 Gigabits, que é 1000 vezes mais rápido que seu plano de internet de 100 megabits.

Eu não vou passar essa placa diretamente pra máquina virtual porque uso ela no host também. Como quero compartilhar a mesma placa entre duas máquinas, preciso tipo criar uma placa de rede virtual, como o dispositivo TAP que expliquei no episódio de VPN e uma rede entre a placa virtual ou a placa real, aí tenho algumas opções. Vamos abrir o aplicativo Virt-Manager, que é uma interface gráfica que facilita configurar as coisas. Essa interface é opcional porque tudo que vou mostrar graficamente pode ser feito via linha de comando usando o comando virsh. Por exemplo, no meu terminal posso digitar sudo virth net-list --all e mostra as duas redes virtuais que já tinha configurado na minha máquina: default e network.

Voltando pro Virt-Manager, posso abrir no menu “Edit” e “Connection Detail” e olha só as mesmas duas redes aparecendo. Clicando em “+”  posso criar uma nova rede virtual, mas não preciso porque já tenho essa daqui que chamei de “network”, podia ser um nome mais criativo. Mas o importante é o nome do dispositivo virtual, a placa de rede de mentira, que dei o nome de “virbr1” porque na rede “default” já tinha “virbr0”. Configurei pra ser uma rede usando NAT pra sair pela minha placa real cujo nome é “enp4s0”. E como sei esse nome?

Lembram dos videos de rede? No terminal posso usar o comando “ip” pra mexer na rede. Se fizer ip link show mostra todos os dispositivos de rede. Lembram que falei que minha placa mãe já vinha com rede embutida de 2.5 Gigabits, esse é o dispositivo “enp8s0” que aparece logo embaixo do loopback. Estou escondendo o MAC Address deles, claro. Em seguida temos o “enp4s0” que falei que é a placa externa de 10 Gigabits. Em seguida temos dispositivos virtuais, “virbr0” e “virbr1”. No fim tem um “wl” alguma coisa que é o Wi-Fi que não uso, mas também veio embutido.

Do ponto de vista do sistema operacional, tanto “enp4s0” quanto esse “virbr0” são placas de rede. Posso criar quantos dispositivos virtuais quiser. Posso criar um separado pra cada máquina virtual ou conectar várias máquinas na mesma placa. E cada placa pode usar diversas estratégias pra se conectar na rede. Vamos entender essa opção “mode”. Olha só, isolated é fácil, impede a placa virtual de se conectar na rede e na internet. Só vai conseguir enxergar outras máquinas virtuais, mas como o nome diz, ficam isoladas do resto do mundo.

Todas as outras permitem acessar tanto a rede interna quanto a internet. Se escolher Bridge, vai se comportar como se fosse uma nova máquina de verdade conectada na rede. Vai procurar e encontrar o DHCP do modem da Vivo, igual meu PC de verdade faz no boot, pegar um IP e navegar normalmente. Se escolher NAT, como eu fiz, ele pega um IP privado atrás do meu PC de verdade e usa NAT pra falar na rede e acessar a internet. 

Routed nunca precisei usar então não sei os detalhes e Open acho que é se quisesse que a máquina virtual ficasse exposta diretamente na internet pública, que não é nosso caso. Então na prática ou escolho Bridge ou NAT. Tecnicamente, Bridge deveria ser mais performático, já que não precisaria passar por um NAT intermediário. Mas não lembro se tive problemas ou se não senti nenhuma diferença, mas vale testar entre os dois.

Pronto. Rede tá ok. Agora podemos começar o processo de criar a máquina virtual. É com esse ícone de “mais” no topo. Escolho a primeira opção pra procurar a ISO de instalação do Windows. Ele detecta corretamente. Caso fosse uma distro de Linux que não detectasse,  precisaria escolher manualmente o mais próximo, mas pra agora vamos pro próximo passo. 

Agora posso escolher quanto de RAM e quantas threads da minha CPU quero dar pra máquina virtual. Não vou mexer aqui porque isso vou mudar mais pra frente, então vamos pro próximo passo. E agora é a parte pra criarmos um HD virtual ou apontarmos pra um SSD de verdade na máquina. Vou só criar um HD virtual. 

Nos meus videos, como de WSL, mostrei como faz pra criar um HD virtual formato de VMWare ou Hyper-V que é o formato VHD ou VHDX, literalmente Virtual HD. Mas o QEMU gosta de usar outro formato, o QCOW2 que significa QEMU Copy-On-Write versão 2.

COW permite que esse HD virtual seja usado simultaneamente por duas ou mais máquinas virtuais diferentes, cada uma vai continuar criando blocos novos tipo num snapshot diferente. Isso também significa que esse HD virtual suporta snapshots, suporta voltar pra versões anterioes, mesmo se dentro não estivermos usando BTRFS. O formato QCOW2 acho que é mais avançado que um VHD. Além de snapshots também suporta compressão e encriptação.

Posso escolher deixar gravar no diretório padrão, mas prefiro criar num diretório que separei só pra isso no meu NAS. Então escolho “Manage” e nessa janela escolho um pool, que é um diretório e mando criar um novo volume, dou um nome qualquer, formato qcow2 e uns 100 gigabytes. Tanto faz o tamanho porque esse arquivo é dinâmico, na realidade só vai realmente gastar o que precisar, então no começo não ocupa espaço nenhum. Ele não precisa já pré-reservar o espaço todo. E agora no último passo mando deixar customizar mais antes de fazer o primeiro boot.

Esta é a tela mais detalhada que mostra tudo que vai ter nesta nova máquina virtual. Vamos um a um nos itens que importam. Logo no Overview tem uma mudança importante. Precisamos garantir que estamos com o Chipset Q35 em vez do antigo legado i440FX e que o Firmware seja UEFI mas a versão OVMF com secboot, que é secure boot. Fodeu, um monte de letrinhas né? Vou explicar. Chipset, como o nome diz, é o conjunto de chips na placa mãe que controla memória, processador, I/O e tudo mais. Queremos os chips mais novos.

UEFI já expliquei nos videos de armazenamento. Muita gente ainda chama de BIOS, mas UEFI é a evolução da BIOS. Dentre outras coisas,  é quem dá suporte a HDs com partições GPT, que permite partições de tamanho superior a 2 terabytes e um número enorme de partições. Toda UEFI moderna nem precisa de um bootloader como Grub. Se a partição tiver uma pasta EFI, vai conseguir bootar direto. Na minha placa-mãe, por exemplo, é só apertar F12 no boot que me dá um menu pra escolher de qual partição quero bootar, o que facilita fazer dual boot.

OVMF significa Open Virtual Machine Firmware. É um firmware, o UEFI propriamente dito, ou seja o software que boota primeiro logo que liga o computador e é responsável por checar e inicializar todos os dispositivos do sistema, achar o bootloader da kernel do sistema operacional em alguma partição GPT e passar o controle pra continuar o boot. Numa placa mãe de verdade esse firmware costuma ser mais complexo porque tem uma interface gráfica. Meu Aorus por exemplo, se apertar a tecla Delete no boot, abre essa tela gráfica fancy aqui. O OVMF tem telas em modo texto bem mais simples e com bem menos opções, porque é pra máquinas virtuais.

Escolhi a versão com Secure Boot porque Windows 11 passa a exigir a existência de um chip de segurança TMP e o firmware precisa ter suporte pra conseguir falar com esse chip. Pronto, podemos confirmar e agora precisamos adicionar uma versão virtual desse chip. Só adicionar novo hardware, escolher TPM, que vai ser emulado, mas selecionar as opções avançadas pra ser modo TIS e versão 2.0 que é o que o Windows 11 não vai reclamar. 

Um secure enclave como esse TPM, no mundo real, é um chip separado da CPU que vai conter coisas como chaves privadas que jamais vai dar pra ler diretamente, incluindo outras credenciais como certificados digitais. Também vai ter gravado a configuração da sua máquina que a firmware vai informar pra ele, assim nos próximos boots dá pra detectar se alguém modificou o hardware, que é o que normalmente se reclama com Secure Boot. 

Muitos gamers odeiam Secure Boot e TPM não porque eles são ruins, mas porque software de Anti-cheat, de detecção de trapaças que muitos jogos instalam justamente fazem modificações muito semelhantes ao que um vírus, malware ou rootkit faria na kernel do sistema. O problema é a existência de anti-cheats mau feitos. 

Enfim, isso é assunto pra outro dia. O importante é que temos como adicionar um TPM virtual pro Windows achar a aceitar. Mas já aproveito pra avisar que o anti-cheat de alguns jogos, como o Easy usado no Elden Ring, conseguem detectar que está rodando em máquina virtual e não permite entrar online, só dá pra jogar offline. Pra mim isso não é problema, mas pra alguns pode ser.

Agora chegou a hora de configurar a CPU. Problema que essa interface gráfica não permite modificar tudo que preciso. O que vou fazer é abrir a configuração de outra máquina que já tenho, copiar o XML do trecho de CPU e colar nessa nova máquina. Olha só, por padrão tenho uma linha pra quantas vcpus, depois o OS que é o firmware que acabamos de configurar, daí temos features da CPU e modo da CPU. Tudo isso precisamos mexer. Abrindo outra máquina que já tenho, começo copiando essas configurações de vcpu e cputune. 

VCPU é simples: quantas threads vou dar pra máquina virtual. Como  tenho uma Ryzen 5950X, posso dar bastante. Decidi dar metade, ou seja, 16 threads pra máquina virtual. O que é essa configuração longa que colei aqui? Eu dei 16 threads, e se não colocar esse bloco de “cputune”, essas threads vão ser controladas pelo scheduler de threads do Linux Host por baixo. É ineficiente porque no Windows ou outro OS guest do lado de dentro já tem um scheduler e por baixo vai ter outro scheduler e no final as 16 threads vão ficar embaralhadas entre as 32 totais, podendo mudar dependendo se o Host tiver alguma carga pra processar. 

Essa configuração depende do uso. No meu caso, se estou com um guest aberto, normalmente não estou fazendo nada pesado no host. 16 threads pra cada dá e sobra na real. Mas essa pinagem de vcpu pra thread real não é aleatório. De onde vem esses números? Pra isso preciso saber a topologia de núcleos e caches deste processador em particular.

Vamos lá, quando falamos CPU, estamos falando deste quadradinho aqui. Seja da Intel ou da AMD, é o processador central. Porém, quando o sistema operacional fala em “CPU” está se referindo a um único núcleo ou a uma única thread. Vocês já devem ter visto que a CPU do seu PC ou notebook pode ter 4 núcleos e 8 threads. Isso porque a maioria das CPUs modernas suporta um troço chamado HyperThreading, onde cada núcleo é compartilhado por até 2 threads. As duas ao mesmo tempo não conseguem funcionar em capacidade máxima, claro. 

Só uma única thread consegue saturar um núcleo. Mas no dia a dia, raramente você está saturando tudo, então 2 threads conseguem compartilhar os recursos de um núcleo e simular 2 processamentos paralelos. Enfim, quando ver em Linux falar em CPU pense que é a thread. Meu Ryzen 9 tem 16 núcleos e 32 threads ou 32 CPUs. Isso porque bem antigamente, de fato uma CPU era só um núcleo. Só dos anos 2000 pra cá que começamos a explorar múltiplos núcleos no mesmo die, ou processador, que é o quadradinho na minha mão.

Aproveitando, num terminal todo mundo sabe que se digitar ls vai listar os arquivos no diretório, certo? Mas sabiam que existem vários programas ls -alguma coisa? Faz o teste, abre um terminal, digita ls e dá “tab”. Olha no meu, vários comandos diferentes. Nos videos de Linux já mostrei o lsblk lembram? Que lista os dispositivos de bloco do sistema, no caso seus HDs ou SSDs. Olha só os meus. E se você usa Snap pra instalar programas vai ter essa poluição de dispositivos de loop aqui, mas pode ignorar isso.

Pra agora nos interessa lscpu com a opção “-e”. Ele lista todas as threads disponíveis no meu processador, o clock máximo e mínimo que aguenta e o clock atual no final. Não sei se sabiam disso mas hoje em dia os clocks são controlados dinamicamente. Eles aumentam ou diminuem dependendo da carga que mandarmos. Isso é importante pra economizar energia. Se estamos fazendo quase nada, o chip elege deixar as threads em clock mais baixo.

Alguém poderia pensar: “boa, quer dizer que quando eu mandar fazer coisas pesadas como renderizar video, vai subir todo mundo pra esse máximo aqui então?” E na realidade não. Depende do governador do sistema operacional, depende dos algoritmos e sensores de Precision Boost da AMD ou Turbo Boost da Intel. Eles tentam ser mais inteligentes do que só subir tudo pro máximo ou desligar tudo pro mínimo. 

Se eu forçasse todos pra ficar em 5Ghz, não ia aguentar muito tempo, porque todos os núcleos iam consumir mais energia, e esquentar muito mais. E todos atingindo temperaturas altas demais, tipo mais de 90 graus Celsius, o processador vai entrar em modo de proteção e fazer o que se chama de throttling, que é diminuir a energia e diminuir o clock pra conseguir resfriar.

Por isso que parece contra o bom senso, mas muitos fazem undervolting. Que é limitar a energia e evitar de chegar em clocks tão altos. Mas qual a vantagem disso, não fica mais lento? Pensa assim, é melhor todas as threads funcionarem por mais tempo abaixo de 4Ghz do que ir pra 5Ghz, esquentar demais, e daí a CPU forçar todo mundo pra baixo de 2Ghz até esfriar. Entenderam? Devagar e sempre é melhor que pico rápido e cansa rápido. Em notebook que não tem espaço, undervolting é a única solução. Em PC com espaço a solução é colocar um cooler melhor.

Enfim, clocks não importam pra hoje, mas se não conheciam é legal estudar as configurações de Precision Boost ou Turbo Boost que tem na UEFI da sua placa mãe. Placas baratas não permitem mexer muita coisa, mas as placas mais avançadas e mais caras costumam dar mais opções de tensão, corrente, e tudo mais que afetam os clocks. Mas vamos voltar pro lscpu. Pra fazer a tal pinagem de VCPU pra CPU real precisamos saber o número real das CPUs que é a primeira coluna, de 0 até 31. Mas os núcleos ou cores de verdade é a 4a coluna. Veja como cada núcleo tem 2 threads como expliquei agora pouco.

Mas e aí, é só pegar 16 quaisquer, colocar lá naquele XML e já era? Não, pra saber baixamos o pacote hwloc. Execute lstopo no terminal e vai aparecer uma janela gráfica parecida com essa. No lado direito mostra os dispositivos conectados em pistas ou lanes de PCI. São coisas como SSDs. Isso também não interessa, o importante é bloco maior na esquerda. Entenda, pra uma CPU, uma thread, funcionar de forma eficiente, ela precisa ter acesso aos dados que vai processar no momento em que for processar.

Se toda instrução tiver que pausar e esperar procurar na RAM e trazer pra CPU, tudo seria lento, a CPU ia desperdiçar clocks não fazendo nada além de esperar. Isso porque RAM é super lenta comparado com um registrador, que é quase instantâneo. Mesmo minha CPU rodando na média a 3.4Ghz e estar usando DDR4 de 4 Ghz, não é só o clock. O barramento é lento, tem distância física da CPU até os pentes de memória, tudo isso afeta o desempenho. Inclusive é uma das razões de notebooks modernos soldarem RAM na placa mãe: pra diminuir a distância física.

Pra evitar que uma CPU fique com fome de dados e pause, cada uma delas tem um pequeno cache L1, nesse caso de 32 kilobytes e um cache L2 de meio megabyte. Parece pouco, mas é bastante coisa pra uma única CPU e elas ficam literalmente grudados a milimetro de distância só. Se tudo correr bem, esses caches vão ter os dados que as CPUs precisam, na hora que precisam e nada pausa. L1 é a memória mais rápida e mais cara de todas, por isso tem tão pouco. L2 é um pouco menos rápido, e L3 é mais lento que L2. Preste atenção nesse diagrama.

A parte importante é que diferente de L1 e L2 que são exclusivos por CPU, o cache L3 é compartilhado com um grupo de CPUs, no caso temos dois blocos de L3 de 32 megabytes cada, compartilhado entre 8 núcleos cada. Digamos que tem uma thread de C ou Java rodando no núcleo 0. Por alguma razão o scheduler do Linux gostaria de usar o núcleo 0 pra outra coisa e resolve mover a thread que ainda não acabou do núcleo 0 pro núcleo 3. 

Como ambas compartilham o mesmo cache L3, se o estado dessa thread, quer dizer, imagine as variáveis dentro da thread, estiverem no L3, basta parar a thread do núcleo 0 e reiniciar no núcleo 3 que vai continuar de onde parou sem problemas. Mas digamos que o scheduler do Linux fosse burro e mandasse pro núcleo 15, o último.

Antes de conseguir iniciar a thread no núcleo 15, ele precisa primeiro copiar o bloco de memória do 1o cache L3 pro segundo cache L3, senão a nova thread não sabe como continuar o trabalho. Sacaram? Um scheduler de threads tem que ser inteligente pra gerenciar esse tipo de coisa. E essa é a dica pra podermos pinar, ou seja, reservar CPUs pra nossa máquina virtual: queremos pegar todas as CPUs embaixo do mesmo cache L3. No meu caso, os núcleos de 0 a 7 ou de 8 a 15. Vamos voltar pro terminal e ver a saída do comando lscpu de novo.

Eu arbitrariamente escolho usar os núcleos de 8 a 15 e nessa listagem significa pegar as threads de 8 a 15 e de 24 a 31. Agora vamos voltar pra configuração XML. Estão vendo aqui os atributos “cpuset”? São exatamente as threads de 8 a 15 e de 24 a 31. Eu mapeei pras CPUs virtuais ou VCPUs de 0 a 15. Essa configuração vai variar se eu quiser passar menos CPUs, ou se o processador tiver menos núcleos e com outra topologia de caches L3, por isso precisa usar os comandos lscpu e lstopo pra decidir no seu sistema. Cada um vai ser diferente dependendo do modelo de processador.

Essa opção “emulatorpin” é pra dizer pro controlador da máquina virtual onde rodar as tarefas que permitem a máquina virtual funcionar. Mas até aqui só dissemos pra máquina virtual, quais CPUs usar. Meu host Manjaro ainda enxerga todas as 32 threads e pode querer usar as mesmas que mandei o guest usar. Como fazer pro host só usar os núcleos do primeiro cache L3? De 0 a 7? Vamos de volta pra Wiki.

Tem várias formas diferentes,  poderia permanentemente limitar meu Linux a só usar os núcleos de 0 a 7, mas isso seria um desperdício quando não estiver usando máquina virtual. Em vez disso quero forçar o Manjaro a se limitar só quando iniciar a máquina virtual e pra isso  posso usar o SystemD. Lembra que SystemD faz bem mais que só gerenciar daemons no boot? Aqui ele gerencia os cgroups do sistema. Chegou a hora de explicar mais alguns termos que vocês não conhecem.

Antes de criarmos a máquina virtual falei que precisava instalar os pacotes do virt-manager, que é a interface gráfica pra criar a máquina virtual, mas também instalei qemu e libvirt sem explicar. Tentando ser curto é assim, o emulador propriamente dito é o QEMU que literalmente significa “Quick Emulator”. Ele quem vai simular a máquina virtual, rodar os programas virtualizados e passar instrução a instrução pra máquina de verdade por baixo. O equivalente VirtualBox ou VMWare ou Hyper-V seria o QEMU.

Na realidade ele faz bem mais que isso. Uma das principais funções é fazer tradução binária dinâmica. Pra quem usa Mac é o equivalente ao Rosetta. E pra quem não usa Mac, o que é Rosetta? 2 anos atrás a Apple saiu fora de usar processadores da Intel, que é padrão x86-64 e passou a usar chips M1 que eles mesmos desenvolveram, derivado de ARM. É meio como pular de um chip que fala português pra outro que fala chinês.

Funciona assim, digamos que eu tenha um programa compilado pra x86. Um trecho desse programa, em assembly poderia ser como esse aqui na tela. Não sei assembly de x86 então pedi pro ChatGPT gerar esse trecho pra mim, de bater o olho parece fazer sentido. Daí pedi pra escrever como seria a tradução que o QEMU faria pra  ARM64 e ele me deu esse outro trecho.

; x86-64

mov rax, [rdi] ; Load the value at the address in rdi into rax

mov rbx, [rsi] ; Load the value at the address in rsi into rbx

cmp rax, rbx   ; Compare the values in rax and rbx

jg greater     ; If rax is greater than rbx, jump to the "greater" label

jmp done       ; Jump to the "done" label

  

greater:

  mov [rdi], rbx ; Store the value in rbx at the address in rdi

  jmp done       ; Jump to the "done" label

  

done:

  ret            ; Return from the function

; arm64

ldr x0, [x1] ; Load the value at the address in x1 into x0

ldr x2, [x3] ; Load the value at the address in x3 into x2

cmp x0, x2   ; Compare the values in x0 and x2

b.gt greater ; If x0 is greater than x2, jump to the "greater" label

b done      ; Jump to the "done" label

  

greater:

  str x2, [x1] ; Store the value in x2 at the address in x1

  b done       ; Jump to the "done" label

  

done:

  ret          ; Return from the function

Estão vendo como os mnemônicos são diferentes? Em Intel existe a instrução mov pra carregar valores, mas em Arm a instrução se chama ldr. Se assistiram meus videos da playlist de Como Computadores Funcionam eu falo mais sobre como Assembly e instruções de baixo nível como esses funcionam, assistam lá depois.

Naquele pacote qemu-desktop que instalamos vem só dois emuladores: o qemu-system-x86_64 e o qemu-system-i386 que são os emuladores de plataforma Intel de 64 bits e 32 bits. Mas existem outros emuladores pra diversas plataformas como ARM. Pra isso tem que instalar o pacote qemu-emulators-full ou direto tudo com qemu-full e aí ganhamos emuladores como qemu-system-aarch64 pra ARM, mas olha a lista: tem os antigos MIPS, Alpha ou até Motorola 68000 mas tem coisa nova como Risc V. Quem tem interesse em programar baixo nível pra Risc V, pode criar máquina virtual com esse emulador. Leiam também a página de Wiki específica de QEMU depois pra aprender tudo.

Traduzir de uma arquitetura pra outra é bem lento mas no caso, pra rodar Windows de Intel em cima de um Linux compilado pra Intel, não tem tradução nenhuma envolvida. Só precisa pegar a instrução da máquina virtual e passar direto pra máquina real embaixo, é bem menos trabalhoso e por isso a performance é quase inteira mantida. Uma CPU virtual funciona uns 15 a 20% mais devagar por conta dessa intermediação do QEMU no meio. Mas sem configurar nada, mesmo de Intel pra Intel, um Windows rodaria lento emulado, e o culpado não é o QEMU.

A culpa são dos dispositivos da máquina: memória, HD, rede, e tudo mais é virtualizado em software, porque a máquina virtual não pode acessar o hardware diretamente, só a kernel do Linux rodando de verdade no metal é que pode. Por isso a AMD e Intel criaram as instruções VT-d, pra permitir passar acesso aos dispositivos reais diretamente, sem precisar gambiarrar com software no meio. Por isso lá no começo o Wiki manda checar se seu sistema suporta VT-d e VT-x.

Tendo essas instruções agora é tarefa da kernel do sistema operacional usar. No Windows isso é responsabilidade do Hyper-V. No MacOS é o “Hypervisor.framework”. Num BSD Unix o nome é bizarro, se chama “bhyve”, que significa “BSD Hypervisor”. Um hypervisor dá acesso às instruções VT-d e VT-x da Intel ou AMD-V da AMD, permitindo criar e gerenciar múltiplas máquinas virtuais rodando em cima deles. No Linux, o módulo responsável por isso se chama KVM, que significa “Kernel Virtual Machine”.

Eu detesto esse nome porque KVM também significa Keyboard, Video and Mouse e é uma caixinha onde conectamos, teclado, video e mouse, e podemos ligar em vários PCs diferentes, tipo numa lan house ou data center. Daí é só virar uma chavinha pra escolher qual PC queremos controlar. O nome deve ter sido de propósito porque o Kernel Virtual Machine ou KVM de Linux serve pra justamente gerenciar múltiplas máquinas também, só que virtuais.

Só o QEMU sozinho seria lento, pela falta de acesso ao hardware. Mas ele aceita usar aceleradores. E o KVM pode ser usado como acelerador e por isso chamamos a solução de “QEMU/KVM”. Entendido isso falta só mais um componente, o tal do “libvirt” que é o daemon que habilitamos no SystemD. KVM não é o único hypervisor que existe no Linux. Um pouco antes dele, existia outro chamado Xen, e tem alternativas comerciais, como o VMWare. 

Seria um saco ter que saber os comandos específicos de cada um, e é pra isso que o libvirt serve: ele é o intermediário que fala com hypervisors de Linux. Eu posso controlar qualquer um com o mesmo comando virsh que mencionei antes. A interface gráfica “Virt Manager” que usei pra criar a máquina virtual de exemplo, por baixo, provavelmente usa esse comando, e eu poderia ter criado a máquina direto do terminal com esse comando também, só fazer virsh create ...

O comando virsh é complexo, posso controlar todos os aspectos de um ambiente virtual come ele. Criar redes virtuais, pools de storage, snapshots e mais. Vale a pena estudar depois, mas pra hoje eu preciso de bem pouca coisa dele. Enfim, agora vocês sabem o que é libvirt, KVM e QEMU.

Antes dessa longa tangente eu tinha parado no problema onde já configuramos a máquina virtual pra só falar com as threads de 16 a 31 e agora precisamos obrigar o scheduler do Linux host a só falar com as threads de 0 a 15. Dessa forma cada sistema tem seu grupo de núcleos isolados. Isso é importante porque senão do nada o guest pode começar a engasgar quando o host ficar roubando as threads do guest.

Como falei antes, o libvirt é responsável por falar com o KVM pra fazer coisas como iniciar ou parar uma máquina virtual. Depois que minha máquina estiver configurada direitinho, é só fazer virsh start e o nome da máquina e pra desligar forçado, equivalente a apertar o botão de força de um PC, é só executar virsh destroy.  Felizmente o libvirt tem eventos e hooks, ou ganchos, onde podemos pendurar scripts. 

A Wiki nos manda criar o script /etc/libvirt/hooks/qemu. Toda vez que o QEMU iniciar ou parar, o libvirt vai chamar esse script. Se receber o comando started usamos o systemd pra ajustar a propriedade AllowedCPU de 3 cgroups pra permitir usar só as threads de 0 a 15. Dessa forma finalmente garantimos que de 16 a 31 vai mesmo ser só pra máquina virtual. E quando vier o comando “release”, ajustamos pra voltar a permitir usar todos os núcleos. Agora é só reiniciar o serviço libvirtd e pronto. Isso termina a longa configuração de pinar VCPUs.

Vamos testar pra ver se funciona. Primeiro, sem nenhuma máquina virtual rodando, vou executar o programa GeekBench, que todo canal no YouTube que faz reviews de processador usa, e pular direto pros testes de multi-core. Olha o htop rodando em outro terminal e sim, todas as minhas 31 threads estão sendo trabalhadas. Podemos cancelar e agora abrir uma máquina virtual qualquer que já tenho configurado. Fazendo isso o libvirt vai atirar o evento de started pro hook e executar aqueles comandos de systemd.

Pronto, o guest tá carregado, voltamos pro terminal e executamos o GeekBench de novo. Vou pular pros testes de multi-core como antes. Voltamos pro htop: só as threads de 0 a 15 estão saturados. As threads de 16 a 31 estão sem fazer nada, reservados pro guest poder usar sem ninguém atrapalhando. Sacaram? É assim que garantimos que se eu estiver jogando na máquina guest e o Host decidir processar alguma coisa, não vai sequestrar uma thread minha e causar engasgos no meu jogo. Conseguimos controlar o processador com sucesso!

Mas o que são aqueles system.slice, user.slice e init.scope? São control groups, ou cgroups. Cgroups é um recurso de Linux pra organizar processos em agrupamentos, daí podemos limitar acesso a recursos pro grupo todo. Nesse caso estamos limitando acesso à CPU pra esses 3 grupos e a kernel vai enforçar isso. Aliás, pra quem não sabia, é combinando cgroups com outro recurso da kernel, namespaces, que começa a formar as bases pra containers como Docker. Mas isso fica pra outro episódio.

#!/bin/sh

  

command=$2

  

if [ "$command" = "started" ]; then

    systemctl set-property --runtime -- system.slice AllowedCPUs=0-15

    systemctl set-property --runtime -- user.slice AllowedCPUs=0-15

    systemctl set-property --runtime -- init.scope AllowedCPUs=0-15

elif [ "$command" = "release" ]; then

    systemctl set-property --runtime -- system.slice AllowedCPUs=0-31

    systemctl set-property --runtime -- user.slice AllowedCPUs=0-31

    systemctl set-property --runtime -- init.scope AllowedCPUs=0-31

fi

Mais um detalhe, esse hook vai rodar toda vez que qualquer máquina for iniciada ou parada pelo QEMU. No meu caso sempre pretendo criar máquinas virtuais com exatamente os mesmos núcleos pinados, então pode rodar sempre. Mas se você quiser máquinas com mais ou menos núcleos, precisa de um hook diferente pra cada máquina. E isso é simples. Em vez do script anterior de systemd em /etc/libvirt/hooks/qemu eu colocaria este outro script mais complicadinho:

GUEST_NAME="$1"

HOOK_NAME="$2"

STATE_NAME="$3"

MISC="${@:4}"

  

BASEDIR="$(dirname $0)"

  

HOOKPATH="$BASEDIR/qemu.d/$GUEST_NAME/$HOOK_NAME/$STATE_NAME"

  

set -e # If a script exits with an error, we should as well.

  

# check if it's a non-empty executable file

if [ -f "$HOOKPATH" ] && [ -s "$HOOKPATH" ] && [ -x "$HOOKPATH" ]; then

    eval \"$HOOKPATH\" "$@"

elif [ -d "$HOOKPATH" ]; then

    while read file; do

        # check for null string

        if [ ! -z "$file" ]; then

          eval \"$file\" "$@"

        fi

    done <<< "$(find -L "$HOOKPATH" -maxdepth 1 -type f -executable -print;)"

fi

Não vou explicar linha a linha, é um script de shell. Se você entende de Linux é fácil. Toda vez que o QEMU iniciar uma máquina virtual, esse script vai rodar. Vai pegar o nome da máquina, digamos que seja  win11-video e vai procurar o esse script /etc/libvirt/hooks/qemu.d/win11-video/qemu e lá podemos colocar aquele script anterior de systemd mas agora ajustando exatamente quais CPUs vou permitir pro host pra essa máquina virtual em particular, sacaram?

O perfil de boost da CPU é controlado por uma coisa chamada Governador da Kernel. Sabe nas configurações de energia de qualquer sistema operacional, especialmente em notebooks, que você escolhe Balanceado, Modo de Economia ou Alta Performance? É isso. Normalmente o Linux se configura em perfil Balanceado, mas eu gostaria de forçar pra perfil de performance antes de iniciar meu Windows de games. Pra isso existe o comando cpupower. Só rodar cpupower frequency-set -g performance e pronto. Estude sobre cpupower depois pra descobrir se sua CPU tá em modo balanceado ou economia e você nem sabia. 

Voltando pra configuração XML, vou copiar e colar vários blocos. Isso tudo tá explicado na Wiki mas não compensa ir um a um. Em resumo, o bloco de features declara quais funcionalidades essa máquina vai ter, como ACPI que é um padrão pra controlar energia da máquina. Relevante aqui é esse trecho de KVM com estado escondido. Isso é uma tentativa do KVM de tentar esconder do sistema virtualizado que ele está numa máquina virtual. Antigamente GPUs da NVIDIA davam erro se descobriam que estavam sendo virtualizados, mas nos modelos mais novos isso não acontece. Talvez se tentar usar algo mais velho que uma GTX talvez precise, e também desse outro atributo de vendor_id em cima.

Nos blocos de baixo, importante é deixar CPU em modo “host-passthrough” e checar que a topologia está de acordo com todo o trampo que fizemos no bloco de pinagem antes. Aqui tá certinho, 1 soquete, com 1 processador, 8 núcleos e 2 threads cada, totalizando as 16 threads que pinamos. No meu caso que estou usando AMD Ryzen, precisa dessa feature “topoext”, senão não dá pra usar hyperthreading. Em Intel não precisa. E pronto, acho que isso resolve a configuração da CPU. O Virt-manager podia já fazer tudo isso automaticamente pra gente, mas até lá precisa saber esses detalhes todos pra tirar o máximo do processador. Por isso precisa ler a Wiki em detalhes.

Continuando, o Virt-manager já adicionou alguns dispositivos que podem ser estranhos como esse Display Spice e Video QXL. QXL significa “Qemu eXtended Logical” e é uma placa de video virtual. Podemos escolher outros modelos e eu preferi deixar em Virtio que tem essa opção de aceleração 3D. Não espere nenhuma mágica disso ser capaz de rodar games, mas já é alguma coisa. Esse dispositivo é necessário em máquinas onde não temos ou não queremos dedicar placa de video de verdade só pra ela como estou fazendo.

Na real, fiz um teste bem besta. Bootei o Ubuntu virtualizado com Video QXL e testei abrir o firefox e carregar um demo de WebGL. Daí eu desligo, mudo de QXL pra Virtio com aceleração 3D e não faz nenhuma diferença, tenho os mesmos quadros por segundo. Das duas uma, ou o QXL também faz aceleração 3D ou o Virtio não tá acelerando nada, mas seja lá qual for o caso, o resultado parece o mesmo então meio que tanto faz. Até porque o objetivo de usar esses dispositivos virtuais não é fazer nada pesado graficamente como animação 3D ou jogos. Pra renderizar a interface gráfica de janelas, a velocidade é mais que suficiente.

SPICE é um protocolo pra acessar a interface gráfica remotamente, mais ou menos como um VNC ou Remote Desktop de Windows ou mesmo passar X via SSH pra quem é de Linux, mas é mais performático. Nunca vai ser rápido o suficiente pra games, mas pro dia a dia é suficiente. Então, Display SPICE é o monitor virtual que vai mostrar o que sai da placa virtual com Virtio. E vai aparecer aqui nessa aba com ícone de monitor. Deixa eu mostrar como é com outra máquina virtual que já tinha configurado que é um Ubuntu. Nesse Ubuntu não passei minha NVIDIA, então só tem a placa virtual mesmo, já que uso pra testes e não pra jogar nem nada mais pesado. (liga máquina)

No meu caso, salvo pra casos de sistemas de testes como esse Ubuntu, pretendo passar a placa de video real da NVIDIA pra dentro do guest. Então depois que instalar o sistema operacional e os drivers, vou tirar o Video Virtio e o Display SPICE. Mas um terceiro dispositivo que ainda tenho um pouco de dúvidas é o Console PTY. Isso é um terminal virtual de texto que conecta num pseudo-terminal PTY do host. É uma das formas do host se comunicar com o guest e vice-versa. Antes podia arrancar isso fora, mas não sei se teve alguma atualização que sem o console eu não tava conseguindo bootar a máquina virtual direito, então só deixo lá agora.

Agora vem o dispositivo de som. Pra maioria dos casos pode deixar o que vem por padrão já. Ele emula um dispositivo ICH9 que permite entrada e saída em estéreo. Se precisar usar microfone, acho que essa é a melhor opção. Mas se tiver um home theater, no caso um receiver ligado no PC com configuração de surround ou 5.1, que significa duas caixas laterais frontais, duas caixas traseiras surround, um central pra voz e um sub-woofer que é esse .1, daí precisa mudar no XML pro modelo ser “usb”. Áudio via USB desse dispositivo suporta saída 5.1 mas não fornece entrada.

Áudio em Linux é outro ninho de ratos chato mas no geral, na maioria das distribuições Linux funciona assim: primeiro tem os drivers pro hardware de áudio, seja o que vem embutido na sua placa mãe ou dispositivos externos. Esses drivers são chamados de ALSA, que significa Advanced Linux Sound Architecture. Mas os aplicativos, como um tocador de música ou video, não fala diretamente com esses drivers.

Entre os aplicativos e os drivers existe um intermediário que roda em userland que normalmente é o Pulseaudio. Tem também o Jack mas nunca vi o Jack em distros populares. O Pulseaudio é quem permite múltiplos aplicativos acessarem saída de áudio, organiza e centraliza o controle de múltiplos streams. Sabe quando abre a configuração de som num GNOME  e ele deixa controlar o volume independente pra cada aplicativo? É o Pulseaudio. 

Eu não acompanhei a evolução, mas parece que o Pulseaudio, sendo um sistema antigo e legado, envelheceu mal pra lidar com o aumento no uso de multimídia de aplicativos modernos, especialmente necessidades profissionais, como editores de música que precisam trabalhar com dezenas ou centenas de streams de áudio de uma só vez e exigem baixíssima latência. Latência em áudio é crucial. Imagina um notebook de DJ no meio de um show enorme, e do nada latência dá um pico, trava e quebra o som no meio do show por 1 segundo. É o tipo de coisa que jamais pode acontecer. É um dos pontos fortes do MacOS, por isso todo mundo usa Macbooks em shows.

Pra combater isso nasceu um novo projeto, o Pipewire. Algumas distros modernas, como meu Manjaro, já começaram a substituir o Pulseaudio pelo Pipewire. Parece que Pipewire também tem suporte melhor a áudio via Bluetooth, então quem tinha problemas com fones sem fio, deve ter uma experiência melhor agora. Outra vantagem do Pipewire é ter uma camada de compatibilidade de API, daí aplicativos que esperam trabalhar com Pulseaudio conseguem se comunicar com o Pipewire. De qualquer forma, na configuração do QEMU não precisamos mexer nada. No XML que ele nos deu já vem esse canal de áudio apontando pra pulseaudio. Eu estou usando Pipewire no Manjaro e tá tudo funcionando então acho que funciona plug and play.

Áudio é um troço que dependendo do seu caso de uso, pode dar dor de cabeça. No Wiki que estamos seguindo, ele detalha direitinho como configurar pra pulseaudio, pipewire, jack, scream e mais. Se precisar muito tem como configurar na mão coisas como latência, bitrate. Por exemplo, pode dar problemas se no guest o som estiver configurado pra sair em 48 mhz e no host estiver pra 44 mhz. Se tiver sorte, como eu, não vai precisar mexer em nada. Mas só lembrando que se tiver problemas, tem que fuçar essa parte da documentação.

Chegamos no evento principal: passar a placa de video real NVIDIA pra dentro da máquina virtual. E se fez tudo direitinho lá no começo com IOMMU e VFIO, agora é só clicar em “adicionar hardware” aqui embaixo, escolher categoria PCI, e selecionar a RTX 3090 que tá separadinha já pra gente. Lembram como no mesmo grupo de IOMMU tinha esse dispositivo de áudio da NVIDIA? Precisa adicionar também, senão a máquina não vai bootar. Mas é só isso. 

Comparado com os outros dispositivos que tivemos que configurar, a GPU é a mais fácil. Mais fácil ainda que teclado e mouse, que é nosso próximo passo. O ideal seria ter dois teclados e dois mouses, um conjunto ligado no host, e o outro pra passarmos pra máquina virtual, mas seria bem pouco prático fazer isso. Lembra quando falei sobre o KVM que não é o módulo de virtualização do Linux? O KVM que permite usar um conjunto de teclado e mouse e monitor e ficar chaveando pra mudar de um PC físico pra outro PC físico? É o que vamos fazer.

O chaveador virtual de teclado e mouse se chama EVDEV que é acrônimo pra “event device”. Olha no Wiki o que ele manda fazer. Temos que listar o que tem no diretório /dev/input/by-id. No meu caso tem todos esses aqui, o mais importante são os dois primeiros. Basta no XML, dentro do bloco de “devices” adicionar o seguinte:

    <input type="evdev">

      <source dev="/dev/input/by-id/uinput-persist-mouse0"/>

    </input>

    <input type="evdev">

      <source dev="/dev/input/by-id/uinput-persist-keyboard0" grab="all" repeat="on"/>

    </input>

    <input type="mouse" bus="virtio" />

    <input type="keyboard" bus="virtio" />

Com isso, posso mover meu teclado e mouse pra dentro do guest ou pra fora no host apertando as teclas control da esquerda e da direita do teclado de uma só vez. No Wiki explica também se quiser mudar essa combinação de teclas. Só que na minha configuração de hardware em particular, o mouse não passa como deveria. Vamos entender porque. No terminal, podemos dar cat nesses dispositivos. Olha o que acontece se der cat no teclado.

Viram? Toda tecla que digito aparece o código aqui. É isso que o sistema operacional fica recebendo antes de traduzir pra letras. Vamos fazer a mesma coisa no primeiro dispositivo de mouse. Dou cat  e mexo o mouse e nada acontece. Isso porque estou usando um receptor sem fio USB que é esse outro dispositivo Logitech USB Receiver aqui em baixo. Tem 4 deles, mas depois de tentativa e erro descobri que é esse que termina com “event-mouse”. Só dar cat nele e olha só recebendo eventos. Portanto devo mudar o XML pra ficar assim:

    <input type="evdev">

      <source dev="/dev/input/by-id/usb-Logitech_USB_Receiver-if01-event-mouse"/>

    </input>

    <input type="evdev">

      <source dev="/dev/input/by-id/uinput-persist-keyboard0" grab="all" repeat="on"/>

    </input>

    <input type="mouse" bus="virtio" />

    <input type="keyboard" bus="virtio" />

Pronto, agora sim o meu mouse vai funcionar. Por isso precisa entender o que realmente está acontecendo e o que cada configuração significa. Falta só mais uma coisinha pra continuar que é baixar a imagem ISO de CD com os drivers pra todos os dispositivos virtuais que configuramos. Sabe, todo lugar que selecionamos a opção de “virtio”? O que é VirtIO? Como o nome diz é “Virtual I/O”, é um nome genérico pra um conjunto de drivers pra esses dispositivos virtuais. O instalador do Windows não tem idéia de que diabos são dispositivos virtio, então precisamos dar os drivers pra ele.

O link vai estar nas descrições abaixo, mas quem mantém esses drivers é a RedHat e tem todas as versões nesta página da comunidade do Fedora. Só escolher a versão mais recente aqui embaixo e agora baixar este arquivo de ISO de 500 mega. Todos os drivers que vamos precisar estão aqui.

Baixado, vamos voltar pra tela de configuração do Virt Manager. Adicionamos um novo hardware de storage, selecionamos o ISO que acabamos de baixar e configuramos pra ser um CD-ROM SATA. Olha aqui que tem outras opções, tem SCSI, tem USB e tem Virtio. Virtio não pode ser, porque Windows não sabe ainda o que é Virtio sem os drivers que estão justamente nesse ISO. USB não sei pra que serve. SCSI também não rola, porque o instalador do Windows também não detecta SCSI. Por eliminação vai ser SATA.

Padrão SATA é o mais comum e genérico e até o Windows consegue entender na instalação. Por isso tanto o ISO do instalador de Windows quanto o ISO dos drivers, vamos configurar como dispositivos de CD-ROM SATA. Mas o HD virtual, formato qcow2 que criamos, está como SATA, mas Virtio tem performance melhor, então mudamos. Só que assim o instalador não vai detectar o HD. Não tem problema, pra isso baixamos os drivers. Finalmente, chegou a  hora de bootar essa máquina.

Olha só como o video sai pelo Display SPICE que mostra aqui na própria janela. É basicamente um streaming do video gerado pela placa de video virtual Virtio. Ele vai detectar o CD-ROM e podemos fazer o boot, exatamente como faria se fosse instalar via pendrive no seu PC de verdade. Vou passar rapidinho essas primeiras telas porque todo mundo já viu isso antes.

Pronto, chegamos na parte que o instalador tenta achar o HD pra particionar, formatar e copiar os arquivos. Mas não acha nada, porque como expliquei antes, não tem nenhum HD SATA. Mas tem essa opção de “Load Driver”. Podemos navegar pro CD do Virtio e ir pra pasta “amd64” logo no começo. Meio burro que o Windows não vasculhe o CD inteiro pra achar os drivers, mas beleza. E olha só, achou o driver da RedHat de controlador SCSI Virtio. E uma vez carregado, sucesso, agora sim ele acha o HD virtual e vai conseguir formatar e instalar. A partir daqui vou acelerar bastante a instalação pra terminar rápido. Terminando em, 3 … 2 … 1 ….

Terminou! Eis que estou no novo Windows virtualizado. Mas não acaba aqui. Primeira coisa a fazer é abrir o Gerenciador de Dispositivos. Olha só que coisa feia, um monte de dispositivos que o Windows não tem idéia do que fazer. Pra resolver isso temos que manualmente clicar com botão direito e mandar instalar o driver a partir do CD do Virtio. E pronto, um dispositivo configurado, vamos pros próximos.

Agora sim, o Windows detectou corretamente tudo que precisava. Esses drivers Virtio são o que chamamos de drivers paravirtualizados. Em uma virtualização completa, o Windows não saberia que tá sendo virtualizado, ele ia ser iludido a achar que tá numa máquina de verdade. E todo driver responderia como se fosse um dispositivo de verdade por baixo e não um arquivo formato qcow2 fingindo ser um HD de verdade. Ou uma ponte com NAT fingindo ser uma placa de rede.

Já drivers paravirtualizados falam pro Windows: “ow, tu sabe que isso não é de verdade né?” e o Windows “porr, sérião? beleza, valeu por avisar, vamos trabalhar juntos nisso então”. E sabendo que é virtualizado ele pode se comportar diferente de um driver normal pra otimizar performance. É uma explicação bem grosseira, mas o importante é que o Windows guest sabe que tá numa máquina virtual e vai agir de acordo e cooperar com o host por baixo pra ter mais performance.

A partir daqui é vida normal que segue. Vamos deixar o Windows Update atualizar o que precisa e baixar o resto dos drivers. Enquanto isso podemos ir no site da NVIDIA e baixar o GeForce Experience, que serve pra otimizar as configurações da GPU pra cada jogo. Ele também serve pra monitorar atualizações dos drivers e vamos instalar por ele. De novo, baixar e instalar é demorado então vou acelerar e terminar em 3 … 2… 1…

Com todos os drivers instalados e tudo atualizado, rebootamos a máquina e tá tudo funcionando. O que podemos fazer agora é desligar a máquina e remover a placa de video virtual Virtio e o monitor virtual SPICE. A partir de agora o Windows vai usar direto só a RTX 3090 de verdade. Então vamos fazer isso. Sei lá porque sempre dá erro pra remover esses dispositivos e o mais fácil é entrar na configuração XML e apagar manualmente. Olha só que chato.

Feito isso, vamos bootar de novo. Mas dessa vez vou bootar outro Windows que já tá configurado, com Steam e tudo só pra demonstrar como fica. Nesse caso vou deixar o OBS também rodando por trás pra gravar o jogo.

(jogo)

O que acham? Isso é um game pesado rodando com velocidade normal como se estivesse num PC de verdade. Mas isso só é possível porque estou usando uma CPU parruda, a Ryzen 9 5950. Estou usando só metade dos núcleos, que são 16 threads, com uns 20% menos performance por thread. Mas isso é quase o equivalente a   rodar um processador Ryzen 5 por exemplo, que já é mais do que suficiente pra maioria dos jogos. 

Agora deixa mostrar um jogo incompatível com máquina virtual por causa do anti-cheat. Vamos carregar Elden Ring, esperar um pouco  e … olha só, dá pau e fecha. Ainda bem que no caso específico do Elden Ring a gambiarra pra carregar offline é simples. Basta ir com o explorer no diretório do jogo, apagar esse executável que carrega o anti-cheat e renomear o executável do jogo propriamente dito com o mesmo nome. Pronto. Vamos carregar de novo e olha só, não deixa entrar online mas pelo menos posso jogar sozinho, que é o que eu queria.

Eu não jogo online, mas quem joga uns Valorant da vida, não vai funcionar em máquina virtual pelo mesmo motivo: o anti-cheat vai detectar que tá em máquina virtual e se não tomar cuidado você pode ser banido. Assim como Elden Ring, alguns jogos tem jeitos de burlar isso mas de novo, tome cuidado pra não ser banido. Mas existe uma última saída caso eu quisesse muito jogar isso. Vamos abrir a configuração desta máquina virtual no Virt Manager.

Diferente da máquina virtual de testes que tava montando pra esse video, essa outra máquina que mais uso não foi instalado num HD virtual qcow2. Eu já tinha esse Windows em dual boot instalado direto no SSD NVME. Era meu sistema principal antes de instalar o Manjaro. Olha aqui a configuração de armazenamento no Virt-Manager. Em vez de apontar pra um arquivo .qcow2 está apontando direto pro dispositivo /dev/nvme0n1. 

Digamos que eu queria muito jogar Elden Ring ou qualquer outra coisa que tenha anti-cheat online. Não tem jeito, a única forma é rodar num Windows nativo sem virtualizar. Nesse caso tenho que desligar meu Manjaro, rebootar e no Grub escolho Windows. Vamos acelerar aqui o boot e olha só, notaram? É exatamente o mesmo Windows que tava funcionando virtualizado. Felizmente, até o Windows é inteligente o suficiente pra detectar os dispositivos de verdade e carregar os drivers nativos certos em vez dos VFIO da máquina virtual. Eu posso usar o mesmo Windows tanto em dual boot nativo quanto virtualizado pelo QEMU/KVM.

E a partir daqui é um dual boot normal, sem nada de virtualização, com o Windows tendo acesso a 100% da CPU e às minhas duas placas de video. No caso de games, é onde vou ter o máximo possível de performance, caso precise. Mas se precisar de alguma coisa do Linux, preciso fechar tudo e rebootar de novo, um puta saco. Mas vamos voltar pro Manjaro de novo e abrir o Virt Manager, quero mostrar uma última coisa.

Se eu iniciar o Windows virtualizado por aqui, veja no gráfico que tá carregando, mas meu teclado e mouse páram de funcionar e não vejo nada no monitor. Isso porque o EVDEV que configurei sequestra meu teclado e mouse, mas isso é simples, basta apertar as duas teclas de control ao mesmo tempo, e o controle volta pro host Linux, olha só. E o Windows tá mandando sinal de video pela RTX 3090 que liga na segunda entrada de video do monitor. Eu preciso apertar o botão de menu aqui atrás e navegar até achar o lugar que muda qual sinal de HDMI o monitor vai mostrar. Olha só, tá aqui o Windows.

Vamos voltar pro cabo que sai da placa AMD e ficar no Linux um pouco. Notaram uma coisa irritante? Toda vez que eu abrir uma máquina virtual que usa a placa da NVIDIA precisa botar a mão atrás do monitor, caçar o botãozinho às cegas e mudar o input. Não, tem que ter jeito melhor, e de fato tem. Pesquisando, esbarrei nesta ferramenta chamada “ddcutil”. Vale ler toda a documentação, mas deixa demonstrar o que ela faz.

Primeiro, vamos abrir o terminal e rodar ddcutil detect com sudo. E  detectou meus dois monitores. O primeiro é o Samsung vertical e o segundo é o Asus principal. Agora posso fazer ddcutil capabilities --display 2 --verbose e  lista todos os comandos que meu monitor Asus suporta. Olha só, posso mexer no brilho, contraste, cores, mas o que me interessa é esse comando hexadecimal 60 que é input source.

Teoricamente, se rodar ddcutil setvcp 60 0x01 deveria mudar pra entrada de DisplayPort e com 0x03 deveria ir pra entrada DVI. Mas por alguma razão essa lista tá errada ou incompleta, porque não listou os HDMIs. Eu não lembro mais onde foi que achei mas pro meu monitor Asus ROG TUF encontrei em algum lugar que os valores corretos são 0x0f e 0x12. Olha só, ddcutil setvcp 60 0x0f. Viram só? Mudou pra saída da placa NVIDIA. Podemos repetir o comando só que com 0x12  e olha só, voltou pra saída da placa AMD. 

Antes que alguém comente, sim, o que fiz com ddcutil teoricamente era pra funcionar com o comando xrandr mas por alguma razão não  funciona. Por isso procurei alternativas. Essas porcarias de servidor X.org e Wayland e essa transição até hoje ainda não tá 100%. Aliás, uma das razões de estar usando essa placa pequena AMD RX 6400 é justamente pra conseguir usar Wayland decentemente em vez de X.org. Dizem que NVIDIA já suporta ou vai suportar XWayland, mas ainda não parei pra ver isso. NVIDIA é um dos responsáveis pelo atraso na adoção de Wayland nas distros. Se for usar primariamente Linux, o recomendado é escolher placas de video da AMD.

Por último mesmo, tem um problema. Meu Manjaro eu deixo configurado pra depois de algum tempo, 1 ou 2 horas sem usar, fazer o sistema dormir pra economizar energia. Não gosto de desligar a noite antes de dormir e ter que esperar bootar de manhã. O problema é que enquanto estou usando a máquina virtual, o host tá como se ninguém estivesse usando. Então depois de 1 ou 2 horas, o host resolve que quer dormir. Só que quando isso acontece, congela a máquina virtual, porque o hypervisor vai dormir também, e aí trava tudo e eu preciso forçar um reboot no botão do PC.

Então criei um script chamado bin/suspend que aceita opção “on” ou “off” pra ligar ou desligar a função de dormir do GNOME usando o comando gsettings. Tem outras formas de fazer, se estiver em KDE ou outro gerenciador vai ser diferente, mas isso deve dar uma dica pra quem estiver interessado. Com esse comando, antes de ligar a máquina virtual eu rodo bin/suspend off e isso vai desligar a suspensão. E quando desligar a máquina virtual rodo bin/suspend on pra religar a função de suspensão da máquina e pronto.

Aproveitando, resolvi criar um script chamado bin/vmstart onde passo o nome da máquina. Olha o que ele faz: primeiro muda o governador das CPUs pro modo de performance. Em seguida desliga a configuração de suspensão do host. Finalmente, usa o comando virsh start pra iniciar a máquina virtual. Nesse momento a máquina vai bootar mas não adianta mudar a entrada do monitor já pra placa da NVIDIA porque até o Windows carregar não vai ter nenhum sinal de video. Então forço um sleep de 30 segundos e depois rodo o comando ddcutil pra mudar a entrada automaticamente. Vamos ver funcionando?

Rodo bin/vmstart win11-real que é minha máquina Windows principal onde tem meu DaVinci Resolve, Photoshop e onde edito os videos aqui do canal. Mais alguns segundos … e pronto, olha só, Windows carregado. Agora posso iniciar qualquer das minhas máquinas virtuais via linha de comando, sem precisar abrir o Virt-Manager. 

Esse video já tá longo pra caramba, e isso porque pulei o que são Huge Pages na configuração de memória RAM, pulei falar de I/O threads e como reservar threads só pra operações de I/O, pulei falar de como dinamicamente mover coisas como meus gamepads USB pra máquina virtual automaticamente via “udev”, pulei falar sobre como é mais fácil plugar um hub USB. Enfim, o Wiki tem um montão de detalhes a mais. É uma aula de como configurar seu hardware e mesmo que você não vá montar uma configuração complicada como a minha, recomendo dar uma boa lida com muita atenção.

Além da página de Wiki do Arch também recomendo ler a página de Wiki do Gentoo. Ele tem informações extras que complementam a do Arch e uns truques e correções importantes. Como eu disse, esses dois Wikis são excepcionais e pra montar configurações complicadas assim, toda informação extra é bem vinda. 

Com isso, finalmente consegui fazer uma coisa que vinha querendo faz mais de uma década: ter uma máquina com duas placas de video e conseguir passar uma delas pra máquinas virtuais funcionarem com performance máxima, especialmente pra games. Essa solução é melhor que dual boot porque posso subir quantas instalações de Windows ou Linux quiser, destruir quando não quiser mais, sem me preocupar em estragar o boot ou perder alguma coisa. Meus arquivos de HD Virtual qcow2 ficam no meu NAS que tá conectado com rede de 10 Gigabits, então mesmo bootando remotamente, a performance é muito boa. 

Como falei no começo, o objetivo era documentar tudo que tive que pesquisar pra montar esse setup antes que começasse a esquecer os detalhes. A partir daqui vou sempre ficar mexendo scripts, coisinhas aqui e ali pra ajustar performance ou conveniência.

O mais bizarro que não vou mostrar no video é que hypervisors suportam nesting, ou seja, máquina virtual rodar outra máquina virtual. Eu consigo virtualizar o Windows e, de dentro dele, instalar WSL e rodar Linux via Hyper-V em cima do Windows que tá em cima do QEMU/KVM. É Inception na veia. Além disso posso rodar o Garuda Linux, abrir o Steam que roda via Proton, que é uma camada que usa Wine e várias outras bibliotecas pra emular Windows. 

E falando em emulador, no outro Windows só pra jogos também instalei vários emuladores como o PCSX2 de PS2 ou RPCS3 de PS3 ou Yuzu de Nintendo Switch e mais. Emulador rodando dentro de emulador. Esse é o nível que eu esperava atingir 21 anos atrás quando comecei a mexer com máquinas virtuais. E por hoje é isso, se ficaram com dúvidas ou tiverem sugestões em cima desse setup, mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais!

Finalmente vou falar sobre linguagens que você goste ou use, mas vou fazer isso do meu jeito: escovando bits e explicando como muita coisa funciona por baixo de Python, Javascript e outras linguagens que talvez você não sabia antes de concluir na segunda metade onde discuto onde cada linguagem pode ser melhor aproveitada e porque.

Capítulos

• 00:00 - Intro
• 01:36 - Cap 1 - Perl e Regex | Anos 90
• 06:18 - Cap 2 - Estilo C e ICU | strftime
• 10:25 - Cap 3 - Tudo de Python é em C! | Linguagem “Grude”
• 17:54 - Cap 4 - Tudo de Node.js é em C! | LibUV
• 22:31 - Cap 5 - Compilado vs Interpretado | ABI de C
• 28:21 - Cap 6 - Interoperabilidade: Marshalling/Unmarshalling | FFI
• 36:21 - Cap 7 - Onde cada Linguagem é mais Forte? | Rust
• 38:09 - Cap 8 - Sistemas Distribuídos | Apache Java
• 42:41 - Cap 9 - Produtividade > Performance? | Apps Comerciais
• 48:31 - Bloopers

Links

• https://github.com/python/cpython/search?p=2&q=ifdef+MS_WINDOWS
• https://github.com/python/cpython/blob/a87c46eab3c306b1c5b8a072b7b30ac2c50651c0/Modules/_ssl.c
• https://github.com/pandas-dev/pandas/blob/main/requirements-dev.txt
• https://github.com/numpy/numpy/wiki/Building-with-MSVC
• https://github.com/scipy/scipy
• https://github.com/jupyter/notebook
• https://github.com/openjdk/jdk/search?l=c%2B%2B&p=99
• https://github.com/libuv/libuv
• https://github.com/tensorflow/tensorflow
• https://github.com/tensorflow/tfjs
• https://github.com/pytorch/pytorch
• https://github.com/nodejs/node/search?q=libuv
• https://www.npmjs.com/package/async-await-retry
• https://stackoverflow.com/questions/11996988/how-good-is-oniguruma-compared-to-other-cross-platform-regexp-libraries
• https://www.baeldung.com/jni
• https://www.elastic.co/blog/found-zookeeper-king-of-coordination
• https://github.com/akitaonrails/ObjC_Rubyfication
• https://zaiste.net/posts/shell-commands-rust/#

SCRIPT

Olá pessoal, Fabio Akita

Hoje é dia de fazer um episódio que vinha postergando faz anos: falar sobre as principais linguagens de programação em uso no momento. Quem acompanha o canal sabe que evito ao máximo mostrar código dessa ou daquela linguagem, de vez em quando mostro uns trechos de javascript porque sei que a maioria sabe um pouco pelo menos, e em muitos casos uso pseudo-código que não existe quando o foco é o conceito.

Eu tenho algumas linguagens favoritas, obviamente Ruby, um pouco de Elixir, Crystal, todas linguagens meio parecidas em sintaxe, embora diferentes por baixo, e mesmo assim acho que nunca mostrei código delas em nenhum video. Mas hoje quero compartilhar algumas curiosidades técnicas e opiniões pessoais que muitos assistindo provavelmente nunca pararam pra pensar. A intenção não é fazer prós e contras, falar bem ou mau de qualquer linguagem. A idéia é fazer você enxergar sua linguagem favorita com outros olhos.

(…)

Já vou avisar: meu objetivo não é dizer que linguagem X é melhor que linguagem Y nem nada disso. Então os macacos de auditório de torcida organizada podem se retirar. Programação não é pra isso e código não liga pra sua “lealdade” a essa ou aquela tecnologia. Na verdade tecnologia e inovação recompensam a deslealdade. Quem conhece mais tecnologias diferentes sempre vai ser melhor e na verdade esse video é pra mostrar isso. Iniciantes vão ter seus níveis de ansiedade indo pras alturas porque vou mostrar um monte de coisas que nunca viram. Não se aflijam, anotem os termos que não conhecem, estudem, depois voltem pra assistir de novo.

A primeira coisa que quero levantar é o seguinte: Python. Nos últimos anos aumentou rápido de popularidade, principalmente por causa de projetos como Jupyter Notebooks, Pandas, Tensorflow, PyTorch e outros projetos relacionados a data science e machine learning. Se você se interessa por essas duas áreas, acho que é seguro dizer que maioria dos cursos e artigos a respeito vai usar uma ferramenta feita em Python. Por isso parece que Python é a linguagem que se deve aprender, certo?

Não está errado e não me entenda mau: apesar de não ser minha linguagem favorita, não tenho nenhum problema com Python. O que quero demonstrar hoje é mais dar uma perspectiva pé no chão. Primeiro de tudo, na minha opinião, Python estava no lugar certo na hora certa. Nos anos 90 a linguagem de script mais popular no nascente mundo de Linux foi Perl.

Acho que muitos iniciantes aqui nunca ouviram falar, mas muitos scripts de configuração e administração de sistemas Linux eram escritos em Perl. E quando a web começou a surgir, as primeiras aplicações interativas web, o que conhecemos hoje como programação back-end, era ou em C ou em Perl, porque essa linguagem era mais flexível pra lidar com strings, com um HTML, por causa da sua principal funcionalidade: Regular Expressions ou Regex.

Mais especificamente PCRE ou Perl Compatible Regular Expressions. Quem programa em Objective-C ou Swift pra iOS e Mac e já tentou usar regex, deve ter notado como é um pouco diferente do regex compatível com Perl. Isso porque a Apple, a Microsoft usam regex com sintaxe baseado em ICU que é International Components for Unicode. Eles são parecidos mas tem pequenas diferenças que podem confundir quem não sabe que existem dois padrões diferentes de regex.

Enfim, por causa de regular expressions, Perl sempre foi muito usado pra processar textos, logs, até coisas como sequências de DNA em pesquisa de genoma e coisas assim, já que envolve muito pattern matching de sequências. Porém, na virada do século, o pessoal de Perl quis dar passos maiores que as pernas. Eu lembro que queriam desenvolver um novo Perl, o Perl 6, como uma virtual machine que suportasse múltiplas sintaxes de linguagem por cima, o projeto Parrot.

Esse ciclo de desenvolvimento levou anos e nunca chegou no fim. O Perl 5, que foi a última grande versão de Perl ficou estagnado e sem novidades por muito tempo. Enquanto isso outras linguagens evoluíram mais rápido e de forma mais pragmática, e uma delas foi o Python. Não sei se foi a RedHat quem adotou primeiro, mas o fato é que com a incerteza no futuro do Perl, acredito que muitos começaram a migrar pra Python.

Python também tinha uma sintaxe e ergonomia muito mais modernas. Perl não era originalmente orientado a objetos, embora tivesse como gambiarrar classes com bless. Era uma linguagem dinâmica de tipagem fraca, então bugs por causa de coerção de valores e tipos errados não era incomum. Mas Perl influenciou todas as linguagens de script que vieram depois, incluindo Python, Ruby e o mais óbvio, PHP. De onde vocês acham que variáveis com cifrão vieram? De Perl.

O principal legado de Perl, na minha opinião, foi popularizar a viabilidade de linguagens dinâmicas pra aplicações web e popularizar o uso de regular expressions pra pattern matching de textos. Várias linguagens até hoje usam a sintaxe específica de Perl, como em Ruby, Node.js, acho que Go também porque usa a biblioteca “re2” que é compatível com PCRE.

Na realidade, nem todas são 100% compatível com Perl. Por exemplo, em Python, se usar a biblioteca “re”, o método match tem comportamento como se toda regex começasse com crase, que em Perl significa dizer pra começar o matching do começo do string. Ele também não tem o operador global “/g”, pra isso se usa o método “re.sub()”. São pequenas diferenças, mas pode confundir quem conhecia regex de Perl, por exemplo, se costuma usar Vim como editor, que suporta regex Perl.

De qualquer forma, linguagens que quase totalmente suportam a sintaxe de regex de Perl são Python, Javascript, PHP, Ruby. Como falei antes, a biblioteca “re” de Python é só uma casca pra biblioteca Oniguruma, que em japonês significa carro do demônio, sei lá porque. A gem Oniguruma de Ruby é a mesma coisa. A classe RegExp de Javascript também. Oniguruma é uma das melhores e mais rápidas bibliotecas de regex que existem. Mas não é a única. Linguagens como C#, C++, Go usam outra biblioteca, a “RE2”. Não confundir com Resident Evil 2.

Acho que nem a Oniguruma e nem a RE2 forçam a sintaxe de Perl. Eles oferecem o motor, mas os detalhes da sintaxe, cada linguagem pode configurar como quiser. Por exemplo, C# tem a opção de usar “verbatim string literal” que é escrever a regex com arroba na frente, assim não precisa escapar caracteres especiais dentro do regex com barra ao contrário.

Algumas linguagens não usam o estilo Perl e sim a sintaxe ICU, de International Components for Unicode. Exemplos disso são a classe java.util.regex de Java, a classe icu::RegexPattern de C++, a classe NSRegularExpression de Swift da Apple, as funções “preg_*” de PHP. Eu pessoalmente gosto mais da sintaxe Perl. Quando precisava usar ICU pra programar mobile de iOS em Swift ou Objective-C, lembro que vira e mexe tropeçava na sintaxe.

11 anos atrás fiz um pequeno experimento em Objective-C pra importar o Oniguruma e adicionar sintaxe de regex de Perl pra programar iOS. É uma das poucas coisas que ainda sobrou no meu GitHub. Maioria dos meus códigos sempre foi pra projetos de cliente por isso tenho bem pouca coisa aberta. Essa foi uma delas. 11 anos atrás foi 2011, pouco mais de 2 anos depois que a App Store abriu oficialmente.

Além do regex não ser compatível com Perl, formatação de data e hora também não era compatível com a biblioteca Time de Linux. Sabe a função strftime? Onde podemos pedir pra formar data e hora usando uma string de template como “%d/%m/%Y %H:%M:%S”?

Em Objective-C e depois Swift, usando a classe DateFormatter com o método dateFormat, o mesmo template fica assim: “dd/MM/yyyy HH:mm:ss”. É bem diferente e isso me incomodava porque Ruby usa o mesmo padrão de C mas de novo, Objetive-C e Swift usam o padrão ICU.

Diferente de Regex onde a sintaxe Perl ainda é forte em muitas linguagens em vez do formato ICU, no caso de formatação de data e hora, o formato ICU é mais forte do que strftime de C. C++, Python, Ruby, Elixir ainda usam o formato de C, mas Swift, Java, C#, até PHP e JavaScript usam o formato ICU. Tecnicamente, por serem padrões internacionais de Unicode, o formato ICU é quem deveria ser considerado o “correto”, mas por direito, formatos derivados do mundo Unix e Linux continuam sendo usados.

E de novo, naquele projetinho de biblioteca que fiz pra Objective-C, além de importar Oniguruma, também implementei uma versão de formatador de data e hora usando a função “strftime” da biblioteca “time” de C. Assim eu poderia usar os formatos de Linux e contrariar o formato ICU. E por que? Só pra mostrar que era possível.

E eu contei essas duas histórias pra ilustrar um ponto. Não sei se vocês entendem que muita coisa de Javascript ou Python não são escritos em Javascript ou Python e sim em C. A classe RegExp de Javascript ou “re” de Python são meras casquinhas mas por baixo chamam bibliotecas escritas em C.

Eu digo isso porque muitas linguagens são escritas nelas mesmas. O compilador de Rust é escrito em Rust. O compilador de Go é escrito em Go. Muito do OpenJDK de Java é escrito em Java. Linguagens compiladas costumam muitas vezes ser escritos nelas mesmas. Isso não torna automaticamente uma linguagem melhor ou pior. Apenas facilita pros desenvolvedores das linguagens não ter que ficar mudando de linguagem o tempo todo. Por exemplo, escrever o compilador em C mas as bibliotecas em Rust. Lembrei disso quando conversei com os criadores e mantenedores de Ruby e eles comentando que escrevem mais C que Ruby.

Isso é mais uma curiosidade, não comecem a brigar em Reddit dizendo que sua linguagem é melhor porque é bootstrapped, ou seja, escrita nela mesma. Mais importante é o seguinte: linguagens interpretadas de script como Python, Ruby, Javascript ou PHP herdam muitas características da plataforma onde nasceram: do C. Diferente de Java ou Go que é na maior parte escrita nelas mesmas, linguagens de scripts costumam parecer mais “cascas” pras funcionalidades de C.

Veja a função de formatação de data e hora “strftime” de Ruby ou “datetime.strftime” de Python. Por que acha que tem esses nomes? Porque herdaram da função strftime da biblioteca time, cujo cabeçalho se chama “time.h”. Se num Linux, abrir um terminal e digitar “man strftime” vai dar os detalhes da função original de C. Essa função fica disponível numa biblioteca compartilhada chamada “libc” ou “glibc”, que praticamente todo programa que roda em Linux carrega e usa.

Vamos ver mais exemplos? Em Python, claro, muitos dos métodos do módulo “os” são derivados da libc. Temos “os.mkdir()” pra criar diretórios, não por acaso, é o mesmo nome do comando que você usa em qualquer terminal de linha de comando pra criar diretórios, porque ambos usam a mesma função da libC. Ou “os.getenv()” que é o mesmo nome da função da libC pra pegar variáveis de ambiente. Tem funções do módulo “ctypes” que, como o nome diz são “tipos de C”, como “ctypes.memcmp()” que compara dois blocos de memória e retorna um inteiro. Em particular vários métodos do módulo “math” herdam funções do cabeçalho “math.h” da libC como “math.sin()” pra calcular seno ou “math.pow()” pra calcular a potência de um número.

A mesma coisa vale pra Javascript, Ruby, PHP. E eu quero pegar esse gancho pra voltar pros projetos mais populares de Python. Vamos pegar o Pandas que é uma ferramenta muito poderosa, flexível e razoavelmente amigável de usar pra fazer análise e manipulação de dados. Povo de data science acho que começa aprendendo Pandas. Se abrirmos a página do projeto no GitHub, podemos ver que a maior parte é escrita em Python mesmo.

Mas essa não é a história toda. Como todo bom projeto moderno de Python, tem um arquivo de “requirements” que lista as dependências que o projeto precisa carregar pra funcionar, vamos dar uma fuçada. Tem uma quantidade enorme de bibliotecas, mas 2 das principais incluem o numpy e scipy. Vamos começar pelo numpy que é importantíssimo porque fornece coisas como array multidimensional, funções de álgebra linear, transformada de Fourier e mais.

Vamos abrir o projeto no GitHub e olha só: um terço é código C. Um dos pontos fortes do numpy é justamente facilitar integrar com bibliotecas em C e Fortran. É por isso que pra gerar o pacote pra Mac, por exemplo, o script que tá na wiki manda instalar o pacote de Fortran. Ou na página de wiki pra Windows, precisa do MSVC que é o pacote de compiladores de C e C++ do Visual Studio da Microsoft. Sim, pra gerar o pacote de um projeto de Python, precisa de compiladores de C, C++ e Fortran. Sabiam disso?

O numpy é requisito pra usar o scipy que é um conjunto de módulos científicos pra estatística, otimização, integração, álgebra linear, processamento de sinais e imagens e muito mais. Ele usa os arrays multidimensionais de numpy por exemplo. E no que SciPy é feito? Quase um quinto do código é Fortran e quase outro quinto é C e C++. Ou seja, pelo menos dois quintos do projeto todo também não é em Python e também precisa de compiladores de Fortran, C e C++.

Todo projeto de data science feito em Python precisa usar numpy e scipy, que são os grandes diferenciais, e eles são feitos em boa parte em Fortran, C e C++ e não em Python. E isso não é pra minimizar, denegrir, ou falar mal de Python, mas sim pra quem não sabia entender que só porque a cara da frente é numa linguagem, não significa que por baixo do capô também é.

E o Tensorflow que todo mundo fica hypado pra machine learning? Vamos ver a página no GitHub? Olha só, bem mais da metade do código é em C++, só um quinto dele é Python. O grosso, o motor mesmo, é todo em C++. E o PyTorch que é redes neurais acelerado por GPU? Metade desse código é em C++. E isso porque eu não estou olhando as dependências no arquivo de requirements.

Uma parte significativa que não tá contando aqui é a biblioteca de CUDA da NVIDIA e os shaders pra aceleração em GPU, que podem ser escritos em várias linguagens, incluindo Python mas compilam pra HLSL ou GLSL que é o OpenGL Shader Language. Eu falo sobre linguagens de shaders e GPU no video da longa história de CPUs e GPUs, depois dêem uma olhada.

Pra usar esses projetos, sabendo um pouco de Python é suficiente, mas se alguém queria realmente entender como redes neurais, aceleração via GPU pra esse tipo de computação realmente funciona, obrigatoriamente não é Python e sim C++ e linguagens de shaders pra GPU. Eu estou sendo pedante nisso porque da forma como muita gente faz propaganda, parece que é tudo feito em Python e basta saber Python pra resolver tudo nessa área, o que não é verdade.

E de novo, meu objetivo não é pegar no pé do Python. Como contei no começo, ele estava no lugar certo na hora certa quanto Perl 5 foi desaparecendo. Linguagens de script como Perl ou Python, que foram feitos pra funcionar muito perto do sistema operacional, são ótimos pra funcionar como cascas pras bibliotecas de alta performance feitos em C ou C++.

Era esse tipo de coisa que se fazia com Perl, que era menos ruim do que escrever scripts de SH ou Bash, e depois passamos a usar Python que, com sua sintaxe bem simples e espartana, caiu como uma luva pra administradores de sistemas que precisavam fazer coisas rápidas.

Com o tempo passou a ser adotado em distros com programas como o Conda que é escrito em Python e serve pra instalar e gerenciar pacotes. Não confundir com Anaconda que é outro projeto pra computação científica. Daí o pessoal de pesquisa do Google passa anos desenvolvendo um Tensorflow da vida em C++. Nesse estágio ele é difícil de usar, precisa saber C++. Em cima dele fizeram scripts em Python e um ferramental com mais usabilidade e mais simples de usar pra maioria das pessoas. Essa é vantagem do Python.

Diferente do Tensorflow de Python, o tfjs ou Tensorflow.js é na maior parte escrito realmente em TypeScript e Javacript. Assim como em Python as partes que exigem performance e falar diretamente com o hardware como GPUs, são feitos em C++, mas na versão de Javascript ele pode rodar no navegador e utiliza o suporte a WebGL e Web Assembly. A versão de Javascript não faz tudo que a de Python mas é suficiente. Tem o Tensorflow Lite pra rodar em smartphones também. Enfim, o principal é entender que quando precisamos de performance normalmente precisamos mais do que Python.

E pra não pegar só no pé do Python, Javascript é similar. Tudo que é impressionante e roda rápido no navegador não é mérito do Javascript e sim do navegador que oferece APIs como WebGL pra dar acesso à aceleração via GPU. E todo navegador é feito em C++. Entendam, toda linguagem interpretada depende muito do sistema operacional e outras bibliotecas instaladas.

Voltando ao ponto onde linguagens como Python, Javascript ou PHP dependem de bibliotecas como a LibC, - tanto que os nomes das funções são as mesmas das versões em C -, e se a LibC costuma vir em toda distro Linux mas não em Windows ou Mac, como que faz pra rodar Python em Windows? Vamos pro GitHub do CPython e vou te mostrar o que tem embaixo do tapete. Se procurarmos dentro desse repositório por “ifdef MS_WINDOWS” temos 8 páginas de resultados e olhem esses trechos.

Se nunca programou em C e não sabe o que é pré-processamento, deixa eu pegar um arquivo aleatório desse resultado. Vamos abrir o arquivo “_ssl.c”. Olha aqui na linha 628 tem um “ifdef MS_WINDOWS”. Se não existisse pré-processamento seria como se tivéssemos duas versões desse arquivo. Um chamado “_ssl.c” que teria esse trecho assim e outro arquivo chamado “_ssl.c-ms_windows” cujo trecho seria escrito dessa outra forma aqui. Conseguem ver a diferença?

O compilador, se estiver em Windows, vai compilar o código com esse “if” a mais chamando essa função “SetFromWindowErr” que só precisa no Windows. Em Linux ou Mac esse código não existe. E isso acontece em dezenas de arquivos, 8 páginas de resultados no GitHub. Ocódigo do CPython pra Windows é diferente da versão de Linux.

Por isso o CPython de Windows não é igual ao CPython de Linux que não é igual ao CPython de Mac. Isso vale pra tudo PHP de Windows, Javascript de Windows. Então vamos falar de Node.js. O Node é basicamente um projeto de C++. Um quinto desse projeto é só C++ mas precisamos falar de uma das dependências, o libuv. O coração da principal funcionalidade do Node, que é o famoso eventloop, o reactor, é implementado quase 100% em C. Vamos abrir a página dele no GitHub. Olha só aqui embaixo, 97% de C, mas o resto é só coisas administrativa, por isso é 100%.

E o que é a libuv. Novamente, sendo uma biblioteca de C, num terminal de Linux podemos usar o comando “man” que, se alguém tinha dúvida, significa “manual” e não “homem”. Normalmente bibliotecas de C instalam sua documentação nesse formato. E como diz aqui, esse projeto foi feito pelos desenvolvedores do Node.js pra ser uma biblioteca com capacidade pra rodar em diversas plataformas como Windows, Mac, BSD e é quem abstrai as funcionalidades de I/O assíncrono que o Node precisa pro seu reactor.

Cada sistema operacional implementa I/O assíncrono diferente. Linux costuma ter suporte a epoll, UNIX BSD tem Kqueue, Windows tem IOCP que é I/O Completion Ports, que muitos argumentam que é superior a epoll ou kqueue. Ou seja, a principal funcionalidade do Node só é possível porque quem de fato fornece o músculo é o sistema operacional. O libuv é mais uma casca em C++ pra abstrair essas diferentes formas de fazer I/O assíncrono e tornar possível o Node rodar em qualquer sistema operacional.

E o Deno, o competidor que muitos consideram melhor que o Node? Eu nem quero tentar entrar nessa discussão de quem é melhor. Mas se abrirmos a página GitHub do Deno, vemos que mais da metade, mais de 60% é escrito em Rust. Ahhh será que é por isso que ele é melhor que o Node então? Na verdade não. Se procurarmos por libuv nesse repositório, vemos que o Rust importa as mesmas funções do libuv do Node, então em termos do eventloop, ambos fazem a mesma coisa. Claro que podem parametrizar pra se comportar diferente, mas a fundação é a mesma e, de novo, é C++.

Eu poderia passar o dia todo dando exemplos em Ruby, em PHP, e até mesmo em Java. Mas ué, tudo que é de Java não era escrito todo em Java? Na realidade não. Como último exemplo, vamos abrir a página do OpenJDK e olha aqui embaixo, 13% do Java é escrito em C++. Mas o que? Vamos ver, olha só, muita coisa do HotSpot que é o motor do JIT ou Just in Time Compiler da JVM é escrito em C++. Nem mesmo o Java, que nasceu nos anos 90 com a frase de “Write Once, Run Anywhere” é puramente feito em Java. E se isso não ficou claro, olha a página de resultados de arquivos C++: tem pelo menos 100 páginas de resultados, uma parte considerável da JVM não é feito em Java.

E isso não é perseguição. Ruby, PHP, DotNet, Go, Rust, Swift, e todo o resto tem partes consideráveis que depende de C e C++, coisas como a LibC, coisas de criptografia como OpenSSL ou alternativas como libsodium. Imagina se toda linguagem tivesse que fazer criptografia do zero? O mundo já tem bugs de segurança demais. É melhor todo mundo reusar o que já existe de melhor e mais maduro.

E isso só falando em Linguagens. Quem fez Ciências da Computação decentemente não perde muito tempo com discussões de melhor linguagem. Mas pessoal de desenvolvimento web, por alguma razão vira e mexe entra nesse tipo de argumento. Então só pra complementar, além de linguagens, no mundo web temos diversos outros serviços e componentes que precisamos usar no nosso dia a dia.

Por exemplo, no que é escrito o banco de dados Postgres? É mais de 85% de C. E o MySQL, mais especificamente o MariaDB? Metade é C++ e quase 40% é C. Bom, mas isso deve ser porque são velhos né, um banco de dados mais novo como MongoDB deve ser em outra coisa mais moderna? Não, 72% é C++.

E o Redis que usamos pra cache ou filas o tempo todo? É quase 80% de C. Mas não significa que tudo é em C ou C++. Vejamos o banco de dados distribuído Cassandra, esse é quase 100% feito em Java e não é o único. O Apache Kafka que é o sistema de filas que falei no episódio passado, é quase 75% em Java e 22% em Scala, que é outra linguagem que roda na JVM então 97% é Java. E falando em sistemas de fila, outro com excelente reputação e maturidade e que, se não me engano, era uma das estrelas por trás de serviços como Whatsapp, é o RabbitMQ que é escrito em Erlang, a plataforma por trás da moderna linguagem Elixir.

E aqui vem outra coisa que eu queria explicar. Tanto Java quanto Erlang são muito bons pra construir sistemas distribuídos, de forma mais produtiva do que fazer em C ou C++. Go também serviria, mas ele ainda é muito novo comparado com os outros, talvez o próximo grande banco de dados seja em Go, não sei. Ele ainda não se provou nesse espaço. Então deixa eu dar minha perspectiva sobre onde cada linguagem tem mais força.

Todo sistema operacional hoje é feito numa mistura de C e C++. E quando eu falo sistema operacional ou OS quero dizer coisas como a kernel e drivers de dispositivos, os componente que rodam no Ring Zero de maior privilégio. Todo o resto, nossos programas e scripts rodam no Ring 3, que tem menos privilégios, o que chamamos de userland. Todo programa em userland precisa usar o kernel do OS como intermediador pra falar com dispositivos como SSD, placa de rede, placa de video, teclado, mouse e tudo mais. O único que tem permissão pra falar com o hardware diretamente costuma ser o kernel e seus drivers, que rodam no mesmo espaço de memória.

Isso não vai mudar por muito tempo. A kernel XNU da plataforma Darwin do Mac, a kernel NT do Windows, a kernel do BSD UNIX, que eu não lembro se tinha codinome. Dispositivos Android usam a kernel do Linux. Dispositivos iOS como iPhone usam uma kernel derivada do MacOS. Existem outras de nicho, mas essas são as principais e vão continuar sendo por muito tempo. E todas elas tem uma coisa em comum: são escritos em C e C++. E porque isso importa já que no final, depois de compilar, vira tudo um binário?

Porque essas kernels expõe suas funcionalidades como funções de C, que podemos interfacear com os diversos arquivos de cabeçalho com extensão “.h”. Pra realmente entender isso, precisa entender um pouquinho de como compilação de C funciona. Eu expliquei parte disso em episódios como do Hello World, a diferença de arquivos texto e binário e o episódio de linguagem interpretada versus compilada. Depois assistam pra entender.

A explicação que vou fazer agora acho é um pouco errado, mas é pra simplificar o modelo na cabeça. Se alguém tiver uma explicação de forma mais simples, mandem nos comentários abaixo. Mas pense num driver, como driver da NVIDIA pra placa de video, ou driver pra placa de rede e coisas assim com uma DLL de Windows ou uma biblioteca .SO de Linux. A kernel depois que boota começa a carregar esses drivers. Pense um “import” em Python ou Javascript.

As estruturas de dados e funções que esses drivers implementam vão existir no mesmo espaço de memória que as outras estruturas da própria kernel. É como se a kernel já viesse embutida com esses drivers. Uma vez carregado, o driver enxerga tudo que a kernel enxerga e vice versa. Lembra ponteiros? A kernel pode manipular diretamente uma struct de uma placa de rede, por exemplo.

Isso é necessário porque no nível da kernel gostaríamos de ter a maior performance possível, o menor número de abstrações. A kernel ideal não desperdiça recursos fazendo indireções e abstrações. Por causa disso você nunca vai conseguir fazer um driver em Javascript, Python, Java ou Erlang.

O interpretador de Javascript, como o Google V8 ou o Spidermonkey da Mozilla, assim como a JVM de Java ou a BEAM de Erlang, poderíamos classificar mais ou menos como máquinas virtuais. A intenção delas é abstrair o sistema operacional por baixo, a kernel. Assim um programador de Python pode escrever praticamente o mesmo código pra rodar em Mac ou Windows ou Linux e o interpretador do Python vai se virar pra fazer funcionar embaixo. A JVM é a que mais esconde o OS por baixo, Python ou Javascript escondem menos e às vezes precisa fazer um “if windows faça X else if Linux faça Y” mas é raro precisar.

Pra ser capaz de criar um driver de dispositivo que consiga interagir direto com a kernel, em particular carregar no mesmo espaço de memória, precisa ser uma linguagem compilada que gera binários com a mesma ABI de C, ou seja cujo binário seja compatível com binários gerados pelo compilador de C em termos de tipos de dados básicos terem o mesmo tamanho, mesmo alinhamento, mesmo layout de structs e unions e chamadas de funções sigam as mesmas convenções, tipo uma compatibilidade de API no nível binário.

Outra coisa que talvez você não saiba de linguagens compiladas como C, C++, Rust, Nim, D ou Go e linguagens tecnicamente interpretadas como Python, Ruby, Javascript, PHP, e até Java, C# ou Erlang e Elixir. Eu digo “tecnicamente interpretadas” porque Java não gera binário nativo. Sim, Java ou Javascript tem coisas como JIT na JVM ou V8, que no final pode gerar binário de alguns trechos, mas originalmente não são binários nativos. Só em tempo de execução.

O problema de não ter binário nativo de antemão é que não sabemos o endereço de funções e estruturas de dados. Por isso não temos como fazer um código de C que aponta diretamente pra essas estruturas usando coisas como ponteiros. Mesmo assim é possível integrar binário feito em Rust ou C com programas em Java ou Javascript. Por exemplo, um JavaScript consegue importar bibliotecas como OpenSSL, só que um String de Javascript não é um tipo de dados igual a um String de C. Um String de Python não é igual a um String de C#, então como faz pra uma linguagem falar com outra?

A única forma do binário gerado por uma linguagem conseguir usar um tipo de dados diretamente via ponteiro de outra linguagem, só é possível se são binariamente iguais, tenham a mesma ABI. Quando não tem, precisa existir um processo de conversão. Você já deve ter ouvido falar dos termos serializar e desserializar ou marshalling e unmarshalling. A grosso modo, no mundo de web seria mais ou menos como converter uma estrutura XML num JSON ou vice versa.

O que acontece quando se chama uma API que só devolve XML mas precisa passar pra uma classe ou outra biblioteca que só entende JSON? Precisa converter, só que conversão tem o seguinte defeito. Veja este exemplo de XML que a API hipotética devolveria, ela tem 845 bytes.

<product>
  <name>Playstation 5</name>
  <sku>PS5</sku>
  <manufacturer>Sony</manufacturer>
  <category>Video Games</category>
  <description>
    The Playstation 5 is the next-generation gaming console from Sony, featuring lightning-fast loading, stunning graphics, and immersive gameplay.
  </description>
  <specifications>
    <specification name="CPU">AMD Zen 2</specification>
    <specification name="GPU">AMD RDNA 2</specification>
    <specification name="Memory">16 GB GDDR6</specification>
    <specification name="Storage">1 TB NVMe SSD</specification>
    <specification name="Dimensions">39 x 10 x 26 cm</specification>
    <specification name="Weight">4.5 kg</specification>
  </specifications>
  <pricing>
    <price currency="USD">499.99</price>
  </pricing>
  <inventory>
    <quantity>50</quantity>
  </inventory>
</product>

Digamos que fizemos um código pra converter de XML pra JSON ou seja, faz marshall entre os dois formatos, e eis o JSON equivalente:

{
  "product": {
    "name": "Playstation 5",
    "sku": "PS5",
    "manufacturer": "Sony",
    "category": "Video Games",
    "description": "The Playstation 5 is the next-generation gaming console from Sony, featuring lightning-fast loading, stunning graphics, and immersive gameplay.",
    "specifications": {
      "specification": [
        { "name": "CPU", "value": "AMD Zen 2" },
        { "name": "GPU", "value": "AMD RDNA 2" },
        { "name": "Memory", "value": "16 GB GDDR6" },
        { "name": "Storage", "value": "1 TB NVMe SSD" },
        { "name": "Dimensions", "value": "39 x 10 x 26 cm" },
        { "name": "Weight", "value": "4.5 kg" }
      ]
    },
    "pricing": {
      "price": {
        "currency": "USD",
        "value": 499.99
      }
    },
    "inventoryQuantity": 50
  }
}

Esse JSON é um pouco menor, com 808 bytes. O importante é o seguinte: nesse instante a função que converte tem em memória as duas versões, ocupando o total de 845 + 808 que dá mais de 1600 bytes. Agora pense no nível de uma struct de C versus um objeto JSON de Javascript. Não tem como criar um ponteiro pra um objeto JSON a partir de um código C e tentar usar como se fosse uma struct. Se fossem compatíveis, não precisaria duplicar memória, mas como não são compatíveis, precisamos fazer marshalling, duplicando a memória usada.

Eu acho que muito iniciante não pensa assim, mas comece a enxergar onde memória é duplicada. Por exemplo, quando você abre seu navegador e pede uma página web pra amazon.com por exemplo, sabemos que o servidor web da Amazon vai processar o que precisar pra no final gerar um string gigante que é o conteúdo HTML pra te responder. Esse HTML está ocupando memória no servidor. Quando ele envia pra você, e chega no seu navegador, o navegador tem uma cópia dessa string. Tanto o servidor web quanto seu navegador tem uma cópia do mesmo HTML, duplicando memória nos dois lugares. Isso é inevitável.

O mesmo vale pra um script feito em Javascript ou Python. Lembra da tal função strftime pra formar data e hora que falei lá no começo do episódio? Por baixo é uma função em C. No Python criamos a String “%d/%m/%Y” pra formatar a data e chamamos “datetime.strftime”. Por baixo essa função vai chamar a função da LibC que também chama “strftime”, pra isso precisa criar uma String de C, mas a String de Python não é compatível com String de C, então precisa converter e isso vai duplicar esse String.

Esse é um dos custos escondidos que tem em várias linguagens quando integram com bibliotecas locais feitas em C por exemplo, ou quando fazemos chamadas remotas pra APIs de microserviços ou servidores de banco de dados. Várias estruturas de dados como Strings estão o tempo todo sendo duplicados pra converter num formato que o outro lado entende. O exemplo que dei de XML e JSON são pequenos, nem 1 kilobyte, mas no mundo real, quem já trabalhou em projetos de verdade sabe que estamos transitando documentos muito maiores que isso, de centenas de usuários o tempo todo. É uma das razões de tanta diferença no uso de recursos entre diferentes linguagens ou diferentes bibliotecas.

Quando Java tinha a noção de escrever tudo em Java, ou seja, tudo rodando dentro do mesmo processo da mesma JVM, onde todas as bibliotecas também seriam em Java, não era só pra ser bonito. Uma das vantagens é que se tudo fosse feito em Java, internamente não precisa ter marshalling e unmarshalling, poderia lidar diretamente com referências pras estruturas de dados. Sendo que se integrar como uma biblioteca feita em C usando o recurso de JNI ou Java Native Interface, precisa existir uma tradução entre o layout do espaço de memória de Java pro espaço do C. O mesmo vale pra outras linguagens que não trabalham com os mesmos tipos de C.

Se ficou abstrato até aqui, deixa eu mostrar um exemplo super besta em Python. Considere o seguinte trecho de código em Python:

# Import the extension module
import c_extension

# Call the py_c_function function with a Python string argument
c_extension.py_c_function("Hello, C function!")

Aqui eu estou importando um módulo qualquer feito em C e em seguida chamo uma função declarada nesse módulo passando um String qualquer. Vamos ver como teríamos que fazer essa função em C.

#include <Python.h>

// Declare a C function that expects a char* as a parameter
void c_function(const char* s) {
  // Do something with the C string here
  printf("C function received string: %s\n", s);
}

// Define a Python wrapper function for the C function
static PyObject* py_c_function(PyObject* self, PyObject* args) {
  // Extract the Python string argument from the Python tuple
  PyObject* py_s;
  if (!PyArg_ParseTuple(args, "O", &py_s)) {
    return NULL;
  }

  // Convert the Python string to a C string
  const char* s = PyBytes_AsString(py_s);
  if (s == NULL) {
    return NULL;
  }

  // Call the C function with the C string
  c_function(s);

  // Return None to indicate that the function succeeded
  Py_RETURN_NONE;
}

Primeiro declaro a tal função c_function que recebe uma string e imprime na tela. Um string em C é só um array de caracteres que termina com caracter nulo. Já uma string em Python é um objeto, uma estrutura de dados bem diferente. Por isso embaixo declaramos uma segunda função chamada py_c_function que recebe um objeto Python cujo tipo é um ponteiro pra PyObject chamado args. O primeiro parâmetro é o self que todo método de Python declara explicitamente, o equivalente this em Javascript, por exemplo.

O importante nessa função é essa PyBytes_AsString que vai devolver o ponteiro pro array de chars que está nessa variável py_s. Agora, praquele código em Python conseguir chamar esse código em C, precisamos de outro código que vai intermediar isso, escrito em Cython com extensão “.pyx” mais ou menos assim:

# c_extension.pyx

# Declare a C function that expects a char* as a parameter
cdef void c_function(const char* s) nogil:
    # Do something with the C string here
    printf("C function received string: %s\n", s)

# Define a Python wrapper function for the C function
def py_c_function(s: str) -> None:
    # Convert the Python string to a C string
    cdef const char* cs = s.encode()
    # Call the C function with the C string
    c_function(cs)

Esse é o código que faz o tal marshalling, ou conversão, do objeto de String do Python pra um array de char, é isso que faz o método “encode” da String, duplica a string. Isso é importante porque o objeto de String de Python está sob controle do garbage collector de Python. Digamos que ele decida que ninguém tá usando mais essa String e limpa da memória. Mas no lado do C, que o garbage collector não enxerga, a String ainda era necessária, daí iria crashear o programa. Mas passando uma cópia separada, agora cada um tem seu próprio string e um não pisa no pé do outro, mas o custo disso foi duplicar essa string.

É assim que linguagens como Python, Javascript, Ruby ou PHP fazem pra falar com funções de bibliotecas em C: via marshalling e unmarshalling de estruturas de dados, onde cada lado gerencia a memória do seu jeito. No lado do Python o garbage collector dele se vira com os objetos que ele criou. E do lado do C vai usar, por exemplo, malloc e free, pra lidar com seu espaço de memória. Por isso que precisa duplicar memória na comunicação entre eles e por isso é mais pesado.

E qual a diferença com uma linguagem que compila binário nativo compatível com C como Rust? Vamos fazer a mesma coisa usando Rust agora. Eis um exemplo de um código Rust que chama uma função de alguma biblioteca C qualquer que recebe uma String como parâmetro, e sendo em C, sabemos que String de C é sempre um ponteiro pra um array de chars terminado em nulo:

use std::ffi::CString;
use std::os::raw::c_char;

// Declare the C function using the extern keyword
extern "C" fn c_function(s: *const c_char) {
    // Do something with the C string here
    println!("C function received string: {}", unsafe {
        CStr::from_ptr(s).to_str().unwrap()
    });
}

fn main() {
    // Create a Rust string
    let s = "Hello, C function!".to_owned();

    // Convert the Rust string to a CString
    let c_string = CString::new(s).unwrap();

    // Call the C function with the CString
    unsafe { c_function(c_string.as_ptr()) };
}

Esse “extern C” é pra declarar a assinatura da função C externa que vamos chamar, cujo nome é c_function de novo e o parâmetro é o ponteiro pro array de char. Na função main começamos criando um String de Rust. Só que, assim como no caso do Python, um String de Rust é um objeto, uma estrutura de dados diferente de array de char, por isso criamos uma CString que existe no módulo “std::ffi” pra converter o String de Rust num String de C. Finalmente, dentro de um bloco inseguro, unsafe chamamos a função de C passando esse novo String de C como ponteiro.

Assim como em Python, tivemos que duplicar a memória pra converter os strings. Mas em Rust podemos pular a parte de criar a string de Rust e direto já trabalhar com String de C. Pra demonstrar isso deixa eu começar fazendo uma nova função em Rust besta que recebe um String e converte tudo pra maiúsculo:

fn rust_function(s: &str) -> String {
    // Do something with the Rust string here
    s.to_uppercase()
}

Simples, recebe uma referência pra um String e retorna outro String. Agora vamos ver a mesma função mas usando direto String de C em vez do String de Rust:

use std::ffi::CString;

fn rust_function(s: CString) -> CString {
    // Convert the CString to a slice of c_char
    let s_slice: &[c_char] = s.as_ref();
    // Iterate over the slice and uppercase the characters
    let s_uppercase: Vec<c_char> = s_slice
        .iter()
        .map(|&c| c.to_ascii_uppercase())
        .collect();
    // Create a new CString from the uppercase characters
    CString::new(s_uppercase).unwrap()
}

Eu não sou super fluente em Rust então não sei se tem jeito melhor de fazer isso, mas veja a diferença. Agora o parâmetro é direto um string de C e devolve um string de C também. Um objeto de String de Rust tem métodos conveniente como “to_uppercase” pra transformar tudo em maiúsculo. Mas pra trabalhar em cima de um String de C, precisamos manualmente iterar caracter a caracter do array e transformar em maiúsculo com o método “to_ascii_uppercase”.

Pra fazer código Rust compatível com estrutura de C sem ficar convertendo em objetos nativos de Rust, que são mais convenientes mas duplica memória, precisamos praticamente escrever C usando sintaxe de Rust. Não vai ser o código mais bonito do mundo, mas em casos mais complexos que esse certamente vai ser melhor do que escrever C na mão, porque podemos contar com os recursos mais avançados de gerenciamento de memória e segurança que o compilador do Rust nos fornece. Mas se alguém tinha dúvidas de como trabalhar com Rust e C, por exemplo, na kernel do Linux, esse é um exemplo besta que ilustra como é mais ou menos.

Agora é minha opinião, mas dado o que expliquei até agora, o que eu penso de linguagens é o seguinte: se quiser fazer programação de sistemas, ou seja, coisas de baixo nível como drivers de dispositivo ou mesmo componentes de infraestrutura como a stack TCP, o certo é usar C, C++ e agora Rust ou até linguagens meio desconhecidas mas de mais alto nível e compiladas como Nim ou a linguagem D, que como o nome diz, foi pensado pra ser sucessor de C mas nunca conseguiu popularidade, talvez porque Rust e Go surgiram no meio do caminho e meio que roubaram os holofotes.

Numa camada acima vem construção de ferramentas de administração e infraestrutura. Antes muitos faziam bibliotecas em C como um oniguruma pra regex, e pra facilitar o uso, criavam clientes com linguagens dinâmicas de script como Python ou Perl da vida. Mas Rust e Go tornaram menos dolorido escrever esse tipo de software. A sintaxe é mais moderna e limpa do que C ou C++ então não é incomum que não precise mais fazer scripts de Python por cima pra facilitar o uso. Exemplo disso é um Docker, feito em Go. Antigamente alguém poderia criar um libdocker em C e um script chamado Docker em Python que integra com essa lib pra ser a ferramenta de linha de comando. Agora podemos usar só Go ou só Rust.

Go e Rust geram binários quase tão eficientes quanto C ou C++ e no caso de Rust até mais eficientes e mais seguros em muitos casos. Nos últimos anos o mundo Linux ganhou várias ferramentas como o terminal Alacritty feito em Rust que eu gosto bastante, e tem esta página com várias ferramentas alternativas escritas em Rust que eu uso no dia a dia como o “exa” que substitui o “ls”, o “procs” que substitui o “ps”, “fd” que substitui o “find” e muito mais, depois dêem uma olhada.

Depois entramos na categoria que não expliquei muito que são sistemas distribuídos. São softwares como bancos de dados ou sistemas de armazemento de volumes grandes de dados. Aqui eu vejo muitas soluções que saíram do ecossistema Apache, como Apache Hadoop, Apache Solr, Apache Spark, Apache Kafka, Apache Cassandra e muito mais, todos feitos em Java. Precisava ser em Java? Não, por exemplo, existem alternativas como a DataStax que é Cassandra escrito em C++.

Mas o que surgiu desse esforço massivo da Apache foi um ecossistema de bibliotecas e ferramentas que facilitam o desenvolvimento de sistemas distribuídos, como o famoso ZooKeeper que é o componente responsável pelo consenso entre diversos nodes de um sistema distribuído. Se isso soou grego, pensa assim. A grande vantagem de um banco de dados Cassandra é conseguir aumentar a capacidade adicionando novos servidores no cluster. O sistema se coordena pra receber esse node e passa a distribuir o armazenamento e processamento pra ele. Se um node falha, o sistema de consenso lida com isso também, via eleições por exemplo. São soluções pra quem precisa lidar com petabytes de dados, não é pra tech startup pequena sair usando.

A grande vantagem do Java é ser mais produtivo e menos doloroso do que C++. Uma coisa é fazer algo relativamente “pequeno” em quantidade de linhas de código como uma ferramenta de linha de comando ou driver, outra coisa é criar um software massivo com milhões de linhas de código pra lidar com processos complexos como coordenação de dados massivos em nós de um sistema distribuído. Java foi a escolha certa na época, talvez a única escolha. Pouca gente conhecia Erlang e a sintaxe também nunca foi muito familiar pra quem se acostumou a herança de sintaxe do C. Hoje em dia um novo Cassandra poderia ser feito ou em Elixir ou em Go, mas sendo sistemas super complexos e já maduros, não existe motivo pra reescrever tudo nessas linguagens.

Erlang foi uma oportunidade perdida e Elixir apareceu uns 5 ou 10 anos mais tarde do que deveria. Se tivesse aparecido no começo dos anos 2000, certamente seria uma das linguagens mais usadas hoje. O ZooKeeper que eu falei, boa parte de suas funcionalidades existem por padrão no Erlang, que também usa uma máquina virtual e foi feito pra criar serviços distribuídos no mercado de telecomunicações nos anos 80. Ele estava muito à frente do seu tempo, muito antes de começarmos a nos preocupar com escalabilidade horizontal em tamanho de internet no fim dos anos 90.

Só que naquela época as opções era fazer tudo em C++, que é eficiente mas é masoquismo, ou C# mas aí estava fechado no ecossistema de Windows da Microsoft, ou Java, que era multiplataforma e bem mais amigável do que C++. Por eliminação, escolhemos Java. Só que a JVM não foi criado pra sistemas distribuídos como Erlang, então empresas como Apache precisaram criar essa infraestrutura, componentes como o ZooKeeper, Storm, Flink.

Eu posso estar superestimando, mas acredito que se fosse fazer tudo que tem no portfolio da Apache em Elixir, seria mais produtivo e menos difícil hoje. Mas nunca vamos saber, porque a essa altura do campeonato, não vale a pena tentar reescrever um ecossistema inteiro. A Apache já resolveu esses problemas com Java e equiparou as funcionalidades como Erlang. Pra entender qual é essa grande vantagem do Erlang, assista essa minha palestra onde explico como isso funciona dentro da VM do Erlang.

Do ponto de vista de sistemas distribuídos, outra alternativa moderna é Go. Só que Go tem bem menos ferramentas do que Java ou Erlang, que tiveram muito mais tempo pra amadurecer. Assim como Java, primeiro precisaria criar a mesma infraestrutura. Algoritmos de consenso, sistema de arquivos distribuídos, sistema de processamento de batch, streams distribuídos, armazenamento em cluster e assim por diante, antes de conseguir fazer os equivalente Spark, Kafka ou Cassandra. De novo, é tudo especulação da minha parte, porque a realidade é que se eu precisar de sistemas distribuídos, vou olhar o ecossistema Java da Apache.

O que nos leva a criação de aplicações comerciais, como eu chamaria. Coisas que a maioria aqui assistindo provavelmente vai lidar mais. Aplicações web. Seja feito em Ruby on Rails, ou Django com Python, ou Laravel com PHP, ou Spring Boot com Kotlin, ou Express com TypeScript e assim por diante. Aqui vem uma divisor: os softwares que falei até aqui como uma kernel de OS, driver de dispositivo, ferramentas de linha de comando de Linux, ou até um Kafka ou Cassandra tem uma coisa em comum: o ideal é que eles mudem pouco, que a maior parte das melhorias sejam em pequenas otimizações de performance, segurança, estabilidade. Eu não quero meu banco de dados mudando tanto que a cada nova versão dá crash.

Já aplicações web, que lidam com consumidor final, seja um chat, ecommerce, rede social, ferramentas de produtividade como um Figma ou Canva, ele competem pela atenção e o dinheiro das pessoas. Pra competir, uma precisa adicionar rápido funcionalidades que superam do concorrente. Mesmo que apareça um bug novo que alguns vão reclamar, o importante é que dê pra subir correções rápido. Pra isso queremos linguagens que facilitem produtividade mais do que performance. Sim, daria pra fazer sistemas mais eficientes escrevendo 100% em Rust, ou Go, ou mesmo Java e Elixir, mas até certo ponto é mais fácil treinar pessoas em Python ou Javascript e elas se tornam mais rapidamente produtivas nessas plataformas.

Esse é o motivo de porque não jogamos fora Python ou Javascript: porque taxa homem é mais caro do que custo de CPU por hora. Essas linguagens são mais limitadas como mostrei antes: não servem pra desenvolvimento de coisas com drivers ou protocolos de consenso nem processamento de imagem ou video, mas são ótimos pra fazer código cola mais fácil de usar, importando binários feitos em linguagens mais eficientes como C ou Rust. Portanto podemos usar um Python da vida pra 80% das funcionalidades mais “mundanas” e usamos C, Go ou Rust pra fazer as partes mais difíceis e integramos com uma extensão usando FFI.

Daí temos o mundo mobile, Android e iOS. Pra aplicativos simples, pense num iFood, AirBnb, até um Facebook ou Instagram, podemos apelar pra frameworks mais pesados mas, de novo, mais produtivos como React Native ou Flutter, que evita que a maioria dos desenvolvedores precisem saber como o baixo nível funciona e produzam mais rápido. A maioria dos smartphones hoje já tem mais de 2 gigabytes de RAM, e dá desperdiçar um pouco.

Claro, se todo mundo usa React Native, todo mundo vai estar limitado nas mesmas coisas que ele suporta. Pra se diferenciar, fazemos a mesma coisa que falei no mundo Web: criamos componentes mais eficientes, de mais baixo nível em Swift pra iOS ou Kotlin pra Android e integramos nesses frameworks. Quem souber o baixo nível sempre vai ser um profissional mais valioso. É obrigatório? Não. Mas você quer evoluir na carreira e ganhar mais no futuro? Então sim, precisa saber. Sabe tudo que vim mostrando de exemplo na primeira metade do episódio? Sim, aquilo tem que parecer arroz com feijão pra você se considerar um especialista no assunto.

Daí chegamos nas categorias mais hypadas e consideradas mais modernas como data science, machine learning e inteligência artificial. E aqui o mais importante é tirar o máximo proveito do hardware, em particular de conjuntos de instruções como AVX, SSE ou CUDA em GPUs NVIDIA ou OpenCL em GPUs AMD. Pra isso precisamos voltar pro nível de C++. Como expliquei antes, tudo de data science em cima de Python começa em bibliotecas como numpy e scipy, que são feitos em C e Fortran. Machine learning como um Tensorflow começa em coisas como CUDA e C++. Mesmo em javascript, depende de acesso à GPU via WebGL dos navegadores. Não é a linguagem a parte mais importante e sim acesso a esses componentes de computação paralela de vetores e matrizes de dados.

Eu disse no episódio anterior comentando sobre o ChatGPT que no mundo de deep learning, criar modelos como de geração de imagens do Dall-e 2 ou geração de textos como GPT3, custam astronomicamente caro e nenhum de nós vai ser capaz de criar nada perto disso. Só quem tiver acesso a conseguir trabalhar nos centros de pesquisa de uma OpenAI ou Microsoft da vida que vai ter essa oportunidade. Mas pra coisas úteis do dia a dia não precisamos de um GPT. Machine learning com tensorflow e modelos ordens de grandeza mais simples já são úteis pra escopos específicos. Detecção de movimento é um exemplo, pra aplicações de realidade aumentada.

Muitos não pensam nisso, mas algoritmos mais “simples” como de relevância que é basicamente classificação estatística já é extremamente útil pra coisas como ecommerce conseguirem mostrar “produtos recomendados pra você”. Ou sistemas como Elastic terem pesquisa fuzzy com relevância, como um mini Google, onde o usuário não precisa escrever os termos exatos, mas mesmo assim ele consegue devolver resultados relevantes. Tudo isso já existe e já usamos em diversos sistemas, de ecommerces a redes sociais. A maioria dos desenvolvedores nem sabe o que é um Elastic ou Solr e acha que vai entender como funciona um ChatGPT. Tá longe, bem longe.

Enfim, eu sei que o episódio de hoje talvez tenha sido denso, mas eram alguns pensamentos aleatórios que tinha na minha cabeça fazia tempo que queria dar dump. Se você é iniciante, não espere compreender tudo que eu disse de uma só vez, pesquise os termos que não conhecia, volte de novo. Quem já tem experiência já sabia tudo que eu falei, talvez dê alguns insights pra complementar. O objetivo não era dizer que essa ou aquela linguagem é a melhor ou a pior.

Cada uma estava no lugar certo na hora certa, não necessariamente foram escolhidas por serem as melhores. E mesmo surgindo coisas novas consideradas melhores, não saímos reescrevendo. Maturidade é sempre mais importante que novidade. Se ficaram com dúvidas mande nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais!

Vamos entender mais sobre Jobs Assíncronos, a diferença de usar Promises ou Bull. E um pouco mais sobre o comportamento do famigerado ChatGPT. Vamos ver se ele realmente substitui programadores durante os códigos deste video.

Capítulos

• 00:00 - Intro
• 01:42 - Cap 1 - Form de Upload com ChatGPT | Coisas que você não pensa
• 04:55 - Cap 2 - Upload Direto pra Cloud | Porque não gravar local
• 09:23 - Cap 3 - Ajustando o Front | ChatGPT é júnior?
• 11:46 - Cap 4 - Jogando o Back todo dentro do Controller | Como avaliar Back pesado
• 18:26 - Cap 5 - Promises, não: Jobs Async | Controlando seu back
• 23:52 - Cap 6 - Exemplos Reais de Jobs Async | Google, Anchor
• 26:00 - Cap 7 - Precisa de Jobs Async se Java tem Threads? | Apache Kafka
• 29:51 - Cap 8 - Qual o nível do ChatGPT | Errando com Convicção
• 33:27 - Cap 9 - Quanto custa um ChatGPT? | IA é inacessível
• 36:40 - Cap 10 - ChatGPT vai te substituir? | Talvez?
• 38:50 - Bloopers

Links

• https://docs.bullmq.io/guide/connections
• https://www.npmjs.com/package/bull-ui
• https://github.com/ShaneK/Matador
• https://www.baeldung.com/spring-kafka
• https://youtu.be/yE-XLLa2AME?t=642
• https://youtu.be/0uQqMxXoNVs?t=551
• https://jdhao.github.io/2022/08/10/http_benchmark_wrk/

SCRIPT

Olá pessoal, Fabio Akita

Todo mundo parece que gostou do episódio de técnicas de otimização web, onde explico porque o aplicativo que você acabou de conseguir terminar seguindo um tutorial ou curso online não se parece nada com um projeto profissional de verdade. Não foi surpreendente como realmente, a maioria dos iniciantes nem imaginava que aquelas técnicas existiam. E quem já tem experiência também confirmou que tudo que falei é o arroz com feijão.

Na mesma semana, em dezembro de 2022, tava todo mundo super hypado com o ChatGPT. Acho que todos assistindo pelo menos ouviram falar dessa inteligência artificial, da OpenAI do Elon Musk, que consegue fazer sua lição de casa, até escrever uma matéria jornalística ou script pra videos de YouTube sem nenhum esforço e, pra nós programadores, o relevante é ele conseguir escrever código direitinho. Muitos YouTubers até prevêem o fim dos programadores. Será? Se você pensou assim também, hoje vou explicar porque está errado!

(… )

Recapitulando, no episódio de otimização expliquei rapidamente o conceito básico de balanceador de carga, tanto no nível de requisições HTTP com um NGINX ou entre sua aplicação e o banco de dados com pool de conexões. No final falei sobre como deferimos a execução de operações demoradas pra jobs assíncronos. Alguns iniciantes corretamente se questionaram: por que usar um sistema como o Bull, no caso de Node.js, se existem Promises, Async/Await, Child Processes e Worker Threads? Por que não simplesmente colocar a operação mais demorada numa Promise? Vai rodar em paralelo e devolver o HTML pro usuário rápido. Não é a mesma coisa?

Pra responder isso, eu queria mostrar um outro exemplo. E como escrevi este script tarde da noite, realmente tava morrendo de preguiça de escrever código Javascript então resolvi pedir pro meu copiloto, o ChatGPT, pra escrever pra mim. Eu peço as coisas pra ele sempre tudo em inglês, porque o modelo em inglês é o mais completo e mais bem treinado e é quem dá as melhores respostas. E minha primeira requisição foi: “escreve um form multipart pra upload de uma imagem” (“write a multipart form to upload an image”).

Como era de se esperar, a resposta está correta, eis o código. E ele até dá uma explicação sobre o atributo enctype e tudo mais. Isso é bacana mas não exatamente impressionante. Pra uma lição de casa de curso ou faculdade é suficiente. Mas numa aplicação de verdade não fazemos mais assim.

<form action="/upload" method="post" enctype="multipart/form-data">
  <div>
    <label for="image">Select an image to upload:</label>
    <input type="file" id="image" name="image">
  </div>
  <div>
    <button type="submit">Upload Image</button>
  </div>
</form>

É o seguinte: esse HTML vai gerar um formulário onde o usuário pode escolher uma imagem no seu computador ou smartphone. Quando clicar em “enviar” o navegador vai fazer aquele caminho que já expliquei nos episódios de rede: criar o pacote de HTTP request, conectar no servidor que responde com o endpoint “/upload”. E no servidor o processo que recebe essa requisição fica bloqueado esperando receber esse arquivo.

Qual o objetivo de um endpoint de uma aplicação web? É responder de volta pro usuário o mais rápido possível, de preferência na faixa abaixo de 100 milissegundos. Lembram? Quanto mais tempo sua aplicação leva pra responder deixando o usuário pendurado, menos requisições por segundo seu servidor consegue responder, daí somos obrigados a gastar mais, colocando mais servidores pra suportar todo mundo acessando simultaneamente. Portanto, sempre precisamos pensar se o que estamos fazendo contribui pra aumentar ou diminuir esse tempo.

O problema do form desse exemplo é que ele se conecta e vai deixar sua aplicação e o usuário parados esperando o upload da imagem completar. Num pior caso, digamos que o usuário é um fotógrafo e resolveu dar upload numa foto em 8K RAW, ou seja, descomprimido, que pode ocupar entre 60 a 100 megabytes! Digamos que seja 60 megabytes, e ele está fazendo upload do celular, numa conexão 4G ruinzinha que dá upload só a 10 megabits por segundo.

Isso vai custar 480 segundos, ou aproximadamente 8 minutos. Isso é terrível. Esse 1 upload fez um processo do seu servidor ficar simplesmente parado, esperando, e sem poder fazer mais nada por 8 minutos inteiros!

O Node tem capacidade de jogar essa espera pra uma thread separada que não bloqueia a habilidade de conseguir responder outras requisições enquanto isso. Porém, imagine que sua aplicação é feita pra fotógrafos que vão ficar o dia todo subindo imagens gigantes desse tipo, o tempo todo. Tudo tem um limite, e em breve seu servidor vai ficar bem pesado, porque não dá pra ficar criando threads infinitamente. E threads não são de graça.

Muitos não entendem isso. Cada nova thread ocupa espaço em RAM e tempo de processamento pra mudar o estado de uma thread pra outra. Um paliativo é justamente usar o NGINX na frente da aplicação Node, ou Spring Boot, ou Laravel ou seja lá qual framework esteja usando, porque o NGINX foi feito pra lidar com coisas como uploads demorados de forma mais eficiente do que o Node. O usuário primeiro se pendura no NGINX, faz o upload, e só quando termina o NGINX passa o arquivo direto pra sua aplicação.

Só que NGINX, apesar de ordens de grandeza mais rápido que seu Node, também não é infinito, e uma hora vai ficar pesado. Tem diversas formas de lidar com esse problema, mas hoje em dia o melhor custo-benefício é simplesmente não lidar com ele. Especialmente porque tem outro problema ruim que não tem a ver com a espera e sim com onde fica o arquivo: o storage, ou HD local do processo que recebeu o arquivo.

Lembra que numa infraestrutura de verdade subimos vários pequenos servidores embaixo de um balanceador de carga? Significa que se a aplicação receber um arquivo e gravar localmente, só os processos no mesmo servidor vão conseguir ler, os outros não vão ter acesso. Mas aí o usuário navega na sua aplicação e vai querer ver a imagem que acabou de subir, e não vai achar, porque o NGINX elegeu outro servidor pra receber sua requisição e nesse servidor não tem a imagem. Como faz?

Podemos usar um volume compartilhado na rede via NFS, que nem quando você se conecta num servidor de arquivos da sua empresa. É uma solução válida. Mas ao mesmo tempo gostaríamos de ter um backup, caso o servidor de arquivos dê algum pau, não queremos perder arquivos dos usuários. E no fim, vamos acabar mandando esses arquivos pra algum lugar como o serviço AWS S3. Por isso falei que o menos trabalhoso é simplesmente não lidar com arquivos localmente e sim já mandar direto pro AWS S3.

Eu já sabia disso então fiz outra requisição pro ChatGPT. Pedi pra ele: “agora escreva outra versão desse formulário mas com suporte a upload direto pra um bucket com url pré-assinada do S3”. E como esperado, devolveu um exemplo correto. (“now write another version of this form but with support for amazon aws s3’s pre-signed direct upload to a bucket”)

<form action="{{ presignedUrl }}" method="post" enctype="multipart/form-data">
  <input type="hidden" name="key" value="{{ objectKey }}">
  <input type="hidden" name="acl" value="private">
  <input type="hidden" name="X-Amz-Credential" value="{{ xAmzCredential }}">
  <input type="hidden" name="X-Amz-Algorithm" value="AWS4-HMAC-SHA256">
  <input type="hidden" name="X-Amz-Date" value="{{ xAmzDate }}">
  <input type="hidden" name="Policy" value="{{ policy }}">
  <input type="hidden" name="X-Amz-Signature" value="{{ xAmzSignature }}">
  <div>
    <label for="image">Select an image to upload:</label>
    <input type="file" id="image" name="file">
  </div>
  <div>
    <button type="submit">Upload Image</button>
  </div>
</form>

Se você é iniciante e pelo menos já tentou programar um upload via web, provavelmente fez igual o ChatGPT na primeira vez: um form multipart dando POST pra um endpoint na sua aplicação. Só que nunca parou pra pensar em coisas como a demora do upload num cenário de verdade e nunca pensou que daria pra dar upload direto pro S3 sem passar pela sua aplicação. O grande truque é o atributo “action”. No exemplo anterior era um POST pra “/upload” na sua aplicação. Mas agora é pra URL que estiver nessa variável “presignedUrl”.

Em seguida tem vários campos escondidos que não chequei na documentação mais atualizada da AWS se é assim mesmo, mas se não for, é parecido. São coisas como o nome da chave onde vai ser gravado esse arquivo no bucket do S3, credenciais e outras configurações. E o resto do formulário é igual. Como falei antes, o lance é que quando o usuário clicar em “submeter”, o arquivo não passa por nenhum dos servidores da sua aplicação. Vai dar upload direto pro bucket que você configurou na sua conta antes.