DEV Community: Plínio Balduino

[pt-BR] Como um programa vira um processo: entendendo processos com o meniOS

Plínio Balduino — Wed, 26 Aug 2026 15:00:00 +0000

Há alguns anos publiquei o artigo Criando um sistema operacional (quase) do zero, contando os primeiros passos do meniOS. Naquela época, fazer o kernel inicializar, configurar algumas estruturas básicas e colocar alguma coisa na tela já representava uma parte considerável da diversão.

O projeto continuou crescendo e, hoje, o meniOS consegue executar programas em user space, possui um scheduler preemptivo, memória virtual por processo, filesystem, shell, sinais, pipes e outras funcionalidades que fazem com que ele se pareça um pouco mais com aquilo que normalmente chamamos de sistema operacional e um pouco menos com um programa muito complicado que tomou conta do computador.

Dizer que um sistema operacional "executa programas", entretanto, esconde uma quantidade considerável de trabalho. Quando clicamos em um ícone ou digitamos um comando no terminal, estamos acostumados a pensar que simplesmente mandamos o computador executar aquele programa, mas entre o arquivo armazenado no disco e suas instruções sendo executadas pela CPU existe uma abstração fundamental fornecida pelo sistema operacional: o processo.

Este é o primeiro passo de uma pequena descida ao submundo do desenvolvimento de sistemas operacionais. Ainda estamos relativamente perto da superfície.

Programa e processo não são a mesma coisa

Imagine um executável chamado hello. Enquanto ele está armazenado no disco, temos basicamente um arquivo contendo código, dados e algumas informações que permitem ao sistema operacional entender como esse conteúdo deve ser carregado. No caso do meniOS, assim como no Linux e em vários outros sistemas Unix-like, os executáveis usam o formato ELF. Por enquanto, ELF pode continuar sendo apenas uma sigla misteriosa; voltaremos a ele quando estivermos alguns degraus abaixo.

O importante neste momento é perceber que o arquivo armazenado no disco é o programa, enquanto cada instância desse programa em execução é um processo. Podemos ter dez cópias de hello no disco sem que nenhuma delas esteja sendo executada e, da mesma forma, podemos ter apenas um /bin/hello e executá-lo várias vezes simultaneamente.

Essa distinção aparentemente simples muda completamente o problema que o sistema operacional precisa resolver. Um programa pode ser tratado essencialmente como informação armazenada, enquanto um processo precisa representar uma execução em andamento ou pronta para continuar quando receber tempo de CPU. Isso significa que o kernel precisa manter informações sobre sua identidade, seu estado, os recursos que pertencem a ele e o ponto em que sua execução deverá continuar.

No meniOS, boa parte dessas informações fica em uma estrutura chamada proc_info_t. A estrutura real possui muitos campos, mas podemos reduzir alguns deles para enxergar melhor a ideia:

typedef struct proc_info_t {
  proc_info_p parent;
  uint32_t pid;

  proc_state_t state;
  uint8_t priority;

  char name[32];

  cpu_state_t *cpu_state;

  phys_addr_t address_space_root;

  file_descriptor_entry_t files[PROC_MAX_FILES];

  char cwd[PROC_CWD_MAX];

  int exit_code;
} proc_info_t;

Já existe bastante coisa escondida nesse pequeno trecho. O pid identifica o processo, enquanto state registra seu estado atual e cpu_state mantém informações necessárias para continuar sua execução. Também aparecem referências ao espaço de memória do processo, aos arquivos que ele mantém abertos, ao seu diretório corrente e até ao processo que o criou.

Alguns desses conceitos merecem artigos inteiros e, por enquanto, não precisamos entender todos eles. O importante é perceber que um processo não é simplesmente "um programa carregado na memória": ele é uma estrutura mantida pelo sistema operacional para representar e controlar uma execução.

Se você já usou Linux, macOS ou outro sistema Unix-like, provavelmente já encontrou um PID ao executar comandos como ps. Poderíamos ter, por exemplo:

PID   COMMAND
1     init
7     mosh
12    hello
13    hello

Os processos 12 e 13 estão executando o mesmo programa, mas continuam sendo processos independentes. Cada um pode estar em um ponto diferente da execução, possuir dados diferentes na memória, manter arquivos diferentes abertos e terminar com resultados diferentes.

O meniOS também atribui um PID a cada novo processo. Em uma das partes da criação de um processo filho encontramos algo tão simples quanto:

child->pid = last_pid++;

Isso fornece uma identidade ao novo processo, mas ainda precisamos entender de onde ele veio e como chegou ao ponto em que pode executar um programa.

Criando um processo com `fork()`

Sistemas Unix-like tradicionalmente oferecem uma operação chamada fork(), cujo nome descreve razoavelmente bem o que acontece: a execução chega a determinado ponto e se divide em dois caminhos. Um programa pode fazer algo parecido com:

pid_t pid = fork();

if (pid == 0) {
  // processo filho
} else {
  // processo pai
}

O aspecto inicialmente estranho de fork() é que existe apenas uma chamada no código, mas, se ela for bem-sucedida, passam a existir dois processos continuando a execução a partir daquele ponto. O processo original, que chamamos de pai, recebe como resultado o PID do processo recém-criado, enquanto o filho observa fork() retornando 0. Essa diferença permite que o mesmo trecho de código descubra em qual dos dois processos está sendo executado.

Se o pai receber 42 como resultado, por exemplo, significa que o novo processo possui PID 42. Quando o processo 42 continuar sua execução, entretanto, o valor retornado por fork() será zero.

Não existe alguma característica especial da linguagem C capaz de fazer uma função retornar dois valores diferentes. Quem produz esse comportamento é o sistema operacional, criando dois contextos de execução e preparando cada um deles para observar um resultado diferente.

No meniOS, isso pode ser visto diretamente na implementação de proc_fork(). Entre outras tarefas, o kernel cria uma nova estrutura para o filho, atribui um PID, prepara uma nova pilha do kernel, replica informações herdadas do pai e cria um espaço de endereçamento para o novo processo. A memória virtual do processo pai também é clonada para que o filho possa continuar a execução com uma visão inicialmente equivalente dos dados que existiam antes do fork().

Essa última frase esconde uma quantidade razoável de complexidade. Clonar memória de processos envolve memória virtual, páginas, page tables e várias outras coisas que não precisamos trazer para a conversa agora. Para este primeiro degrau basta assumir que o meniOS consegue preparar para o filho uma cópia apropriada do ambiente de execução do pai.

Há, entretanto, um detalhe da implementação que vale observar desde já. O kernel copia para o filho o estado da CPU existente no momento da chamada:

memcpy(child->cpu_state, frame, sizeof(syscall_frame_t));

Depois modifica o registrador que será usado para devolver o resultado da operação ao processo filho:

child->cpu_state->rax = 0;

Quando o filho voltar a executar em user space, continuará praticamente do ponto em que o pai estava, mas enxergará o retorno de fork() como zero. O pai, por sua vez, receberá o PID atribuído ao filho.

Esse pequeno detalhe é uma boa demonstração de algo que aparece repetidamente quando começamos a olhar por baixo das abstrações fornecidas por um sistema operacional. Aquilo que parece um comportamento peculiar de uma API frequentemente corresponde a alguma manipulação bastante concreta do estado da máquina.

Há ainda outra consequência importante: depois de fork(), pai e filho continuam executando o mesmo programa. Se quem chamou fork() era um shell, acabamos de criar outro processo executando uma cópia daquele shell, o que ainda não resolve nosso problema inicial de executar /bin/hello.

É nesse ponto que entra exec().

Trocando o programa com `exec()`

Uma confusão bastante comum é imaginar que execve() cria outro processo, quando sua função é diferente: ela substitui o programa que está sendo executado pelo processo atual. O PID continua sendo o mesmo, mas o espaço de memória destinado ao programa é reconstruído para receber o novo executável e a execução passa a continuar a partir do ponto de entrada desse programa.

Podemos visualizar a combinação de fork() e execve() desta maneira:

                    fork()
                      |
               +------+------+
               |             |
             shell         shell
             (pai)         (filho)
                              |
                           execve()
                              |
                            hello

No meniOS, a substituição da imagem passa por proc_exec_image(). O kernel prepara um novo espaço de endereçamento, cria uma nova pilha de user space, carrega o executável e determina em qual endereço a execução deverá começar. Depois que a nova imagem está pronta, os antigos mapeamentos pertencentes ao programa anterior podem ser descartados e o contexto do processo passa a apontar para o ponto de entrada do novo executável.

O código real contém operações como:

frame->rip = entry;
frame->rsp = stack_top;
frame->rbp = stack_top;

rip é o registrador que indica à CPU qual instrução deverá ser executada. Ao configurá-lo com o entry point obtido do executável, o kernel está preparando o processo para que, quando voltar a user space, sua execução continue no novo programa.

Também estamos escondendo bastante coisa aqui. Ainda não explicamos como o meniOS interpreta um arquivo ELF, como cria o novo espaço de memória, o que exatamente significa voltar para user space ou por que existem registradores chamados rip e rsp. Esses detalhes não são irrelevantes; estamos apenas adiando a explicação até que tenhamos construído o vocabulário necessário.

Por enquanto, uma regra resume bem as duas operações: fork() cria outro processo a partir de um processo existente, enquanto exec() substitui o programa executado pelo processo atual.

Pode parecer estranho realizar duas operações quando o objetivo final era simplesmente executar outro programa. Por que não pedir diretamente ao kernel que crie um novo processo executando /bin/hello?

Existem sistemas e APIs que trabalham com modelos mais próximos dessa ideia, mas a separação entre fork() e exec() oferece uma propriedade bastante conveniente: há um intervalo entre criar o filho e substituir seu programa, e nesse intervalo o filho pode preparar o ambiente no qual o novo executável será iniciado.

Um shell pode aproveitar esse momento para modificar a entrada ou a saída do processo. É assim que uma construção como:

hello > output.txt

pode ser implementada. O shell cria um processo filho, altera sua saída padrão para apontar para output.txt e somente então executa o novo programa. hello não precisa saber que existe um arquivo envolvido; para ele, escrever na saída padrão continua sendo apenas escrever na saída padrão.

A mesma ideia pode ser estendida para pipes:

cat arquivo.txt | head

O shell cria os processos necessários, conecta a saída de um deles à entrada do outro e depois substitui cada processo filho pelo executável correspondente. O mosh, shell do meniOS, utiliza exatamente esse tipo de mecanismo, mas acompanhar o caminho completo de um comando dentro do shell será assunto para o próximo artigo.

Do `fork()` ao `waitpid()`

Agora conseguimos criar um processo e substituir o programa que ele executa, mas ainda falta uma parte importante do seu ciclo de vida. Em algum momento, o programa terminará, seja porque chegou normalmente ao final de sua execução, porque chamou exit() explicitamente ou porque alguma outra condição provocou seu encerramento. Quando isso acontece, o kernel ainda precisa preservar informações suficientes para que o processo pai descubra o que aconteceu com seu filho.

É aí que aparece waitpid():

waitpid(pid, &status, 0);

Essa chamada permite que um processo espere pela mudança de estado de um filho e obtenha informações sobre seu término. Para um shell, esse comportamento é particularmente importante porque, quando executamos um programa em primeiro plano, normalmente esperamos que o prompt somente volte depois que aquele programa terminar.

Podemos finalmente montar uma versão simplificada do ciclo completo:

shell
  |
  +-- fork()
  |      |
  |      +-- filho
  |            |
  |          execve()
  |            |
  |          hello
  |            |
  |           exit()
  |
  +-- waitpid()
          |
          +-- filho terminou
          |
       novo prompt

A realidade é um pouco mais sofisticada porque o pai nem sempre precisa ficar bloqueado esperando, processos podem ser interrompidos ou continuar em background, sinais podem alterar seu comportamento e o kernel precisa lidar com estados intermediários. O próprio meniOS possui estados como NEW, READY, RUNNING, WAITING, SLEEPING, ZOMBIE, STOPPED e TERMINATED.

Um desses nomes costuma chamar atenção: ZOMBIE. Apesar do nome dramático, um processo zumbi não está andando pelo sistema operacional em busca de outros processos para devorar. Ele simplesmente terminou sua execução, mas algumas informações sobre seu término ainda precisam ser mantidas porque o processo pai não as coletou. Quando o pai executa wait() ou waitpid(), pode obter o status do filho e permitir que o kernel finalmente conclua a limpeza das estruturas restantes.

Com isso, aquilo que inicialmente parecia ser apenas "executar um programa" já pode ser descrito com um pouco mais de precisão. Existe um processo executando o shell, esse processo cria um filho com fork(), o filho herda parte do contexto do pai e pode preparar seu ambiente antes de usar exec() para substituir sua imagem pelo programa desejado. O novo programa executa mantendo a identidade daquele processo e, quando termina, o kernel registra seu estado para que o pai possa observá-lo através de wait() ou waitpid().

O que ainda estamos escondendo

Chegamos até aqui simplificando deliberadamente várias etapas. Quando dissemos que um processo possui memória própria, não explicamos como dois processos podem usar os mesmos endereços virtuais sem necessariamente acessar a mesma memória física. Quando copiamos cpu_state, também não vimos quais registradores fazem parte desse estado nem como o kernel consegue interromper um processo e continuar sua execução posteriormente.

Também passamos rapidamente por uma questão ainda mais fundamental: quando um programa chama fork(), execve() ou waitpid(), como uma aplicação executando fora do kernel consegue pedir que o kernel faça alguma coisa? A resposta envolve as chamadas de sistema, ou syscalls, e a fronteira entre user space e kernel space, outro ponto em que a escada começa a descer de maneira mais perceptível.

O executável também permaneceu quase inteiramente como uma caixa-preta. Sabemos que o meniOS trabalha com ELF e que existe um entry point, mas ainda não discutimos como o kernel encontra código e dados dentro do arquivo e os coloca nos locais adequados da memória. Da mesma maneira, dissemos algumas vezes que um processo "recebe tempo de CPU" sem explicar quem toma essa decisão ou como vários processos conseguem compartilhar um único processador sem cooperar voluntariamente entre si.

Cada uma dessas simplificações esconde outra parte do sistema operacional e, consequentemente, outro possível degrau da nossa descida. Neste primeiro, entretanto, já temos um modelo suficientemente bom para responder à pergunta que abriu o artigo: um programa é código e dados armazenados, enquanto um processo é a representação, mantida pelo sistema operacional, de uma execução desse programa.

No modelo adotado pelo meniOS, fork() cria um novo processo a partir de um existente, exec() substitui o programa executado por esse processo e waitpid() permite que o pai acompanhe o que aconteceu com seu filho. Essas três operações, combinadas, estão por trás de algo tão cotidiano quanto digitar o nome de um programa no terminal e pressionar Enter.

No próximo degrau podemos fazer justamente isso: acompanhar um comando desde o momento em que é digitado no mosh até a criação e execução do processo correspondente. A partir daí, começaremos a encontrar algumas das abstrações que convenientemente deixamos escondidas neste artigo.

[pt-BR] Clean Code passado a limpo - Parte 1

Plínio Balduino — Sun, 23 Aug 2026 15:00:00 +0000

Uma leitura crítica, sem dogmas e sem espantalhos

Muito se fala sobre Clean Code, publicado no Brasil como Código Limpo. Entre iniciantes e desenvolvedores de nível pleno, é comum encontrar quem adote suas recomendações de maneira dogmática, como se o livro fosse um tratado de verdades absolutas. No outro extremo, profissionais mais experientes frequentemente o descartam por completo e parecem dispostos a queimá-lo na fogueira erguida do outro lado dessas mesmas verdades absolutas. Em ambos os casos, a leitura crítica acaba substituída por uma conclusão tomada de antemão.

Para esta série, usarei a edição original em inglês. Tenho uma longa e desastrosa experiência com traduções da Alta Books e minha recomendação continua sendo direta: aprendam inglês e leiam o original. Já escrevi sobre isso e não pretendo retomar essa discussão aqui. Para quem trabalha com desenvolvimento de software, a capacidade de ler textos técnicos em inglês é fundamental.

Robert “Uncle Bob” Martin sustenta publicamente posições que considero indefensáveis e que atraem um público politicamente conservador, para dizer o mínimo. A discussão em torno desses posicionamentos é legítima, mas não será o objeto desta série. Vou me limitar à análise da obra, mantendo uma distância saudável de seu autor.

O livro, a escola e o mito

Poucos livros sobre desenvolvimento de software alcançaram uma presença cultural comparável à de Clean Code. Suas recomendações aparecem em entrevistas de emprego, revisões de código, guias internos, cursos, vídeos e discussões sobre senioridade. Termos como funções pequenas, nomes significativos, responsabilidade única e ausência de duplicação passaram a circular de forma relativamente independente do livro, muitas vezes reduzidos a regras que cabem em uma publicação curta ou em um comentário de pull request.

Essa popularidade produziu uma versão simplificada da obra. Nela, Robert Martin aparece como o autor de um conjunto fechado de mandamentos sobre como todo código deveria ser escrito. Algumas pessoas adotam esses mandamentos como critérios objetivos de qualidade; outras os rejeitam como dogmas ultrapassados, geralmente sem dedicar muita atenção ao argumento original, ao contexto dos exemplos ou às ressalvas feitas pelo próprio livro.

A leitura de Clean Code revela uma obra mais complexa. Seu tom é frequentemente categórico e algumas conclusões ultrapassam aquilo que seus exemplos conseguem demonstrar, mas o livro também reconhece que representa uma escola específica de desenvolvimento de software. A tensão entre essas duas posturas, a declaração de que não existe uma verdade absoluta e a apresentação de determinadas opiniões como absolutos, atravessa toda a obra e ajuda a explicar tanto sua influência quanto boa parte das críticas que recebeu.

Antes do livro, a Object Mentor

A Object Mentor foi uma empresa de consultoria e treinamento em desenvolvimento de software fundada em 1991 por Robert C. Martin. Em sua biografia atual, Martin também identifica Jim Newkirk como cofundador. Ao longo de sua existência, a empresa ofereceu treinamento em C++, Java, orientação a objetos e princípios de design e, posteriormente, passou a atuar fortemente com Extreme Programming e metodologias ágeis. Seus serviços incluíam consultoria, treinamento, mentoria e desenvolvimento de software. A Object Mentor encerrou suas atividades em 2008, no mesmo ano em que a primeira edição de Clean Code foi publicada.

Esse contexto ajuda a compreender o significado da expressão “Object Mentor School of Clean Code” (“Escola de Código Limpo da Object Mentor”, em tradução livre), usada no primeiro capítulo. A escola mencionada por Martin correspondia às práticas que ele e seus colegas aplicavam, ensinavam e comercializavam por meio de uma consultoria. A própria folha de rosto apresenta os colaboradores do livro como “The Object Mentors” (“Os mentores da Object Mentor”, em tradução livre), reforçando que a obra registra uma visão desenvolvida coletivamente dentro daquela empresa.

Isso também explica o caráter pragmático do livro. Clean Code não se apresenta como uma pesquisa acadêmica nem procura construir suas recomendações a partir de estudos controlados sobre legibilidade, manutenção ou produtividade. Sua matéria-prima é a experiência acumulada pelos autores em projetos, treinamentos e consultorias. O conhecimento oferecido nasce da prática profissional, da observação e da repetição de soluções que, segundo eles, produziram bons resultados.

Experiência é uma fonte legítima de conhecimento técnico, especialmente em uma atividade na qual contexto, equipe e domínio exercem influência considerável. Ainda assim, uma prática que funcionou repetidamente dentro de uma consultoria continua precisando ser examinada antes de se transformar em uma regra geral. Parte do trabalho desta série será identificar quando o livro apresenta uma experiência como experiência e quando a transforma em uma conclusão universal.

Um livro que exige trabalho

A introdução de Clean Code também contradiz a maneira superficial como a obra costuma ser consumida. Martin descreve o aprendizado da escrita de código como uma combinação de conhecimento e prática. Princípios, padrões e heurísticas teriam pouco valor quando separados do exercício de ler, modificar e compreender código real.

O livro foi dividido em três partes com essa finalidade. A primeira apresenta princípios, práticas e padrões. A segunda reúne estudos de caso nos quais códigos existentes são sucessivamente alterados. A terceira organiza os smells e as heurísticas identificadas durante essas refatorações. Martin afirma que o valor dessas heurísticas depende da relação entre cada uma delas e as decisões tomadas nos estudos de caso. O leitor que ignora os exemplos e consome apenas as regras perde, segundo a própria introdução, a parte mais importante da obra.

Esse detalhe é especialmente relevante porque a versão popular de Clean Code costuma fazer exatamente aquilo que o livro desaconselha. As heurísticas são retiradas dos exemplos, resumidas em frases curtas e aplicadas em contextos nos quais o raciocínio que as produziu já não está presente. Uma função deve ser pequena, uma classe deve ter uma única responsabilidade e um comentário deve ser evitado, mas raramente se discute como reconhecer os limites dessas recomendações, quais custos surgem de sua aplicação ou que características do código original levaram os autores àquela decisão.

Uma análise justa da obra precisa observar os estudos de caso e verificar se as transformações propostas realmente produzem os benefícios prometidos. Os capítulos “Successive Refinement” (“Refinamento sucessivo”, em tradução livre), “JUnit Internals” (“Aspectos internos do JUnit”, em tradução livre) e “Refactoring SerialDate” (“Refatorando SerialDate”, em tradução livre) serão particularmente importantes porque apresentam o refinamento sucessivo de código, a análise interna do JUnit e a refatoração da classe SerialDate. Quando chegarmos a eles, poderemos avaliar Clean Code por meio do código que o próprio livro oferece como demonstração de suas ideias.

A escola que admite ser escola

Na seção “Schools of Thought” (“Escolas de pensamento”, em tradução livre), no capítulo “Clean Code” (“Código limpo”, em tradução livre), Martin apresenta uma das passagens mais importantes do livro. Ele compara escolas de desenvolvimento de software a escolas de artes marciais. Cada uma possui suas técnicas, seus mestres e sua maneira de praticar, sem que isso conceda a qualquer uma delas o monopólio da verdade.

Martin pede que o leitor considere o livro uma descrição da escola de código limpo da Object Mentor. Ele admite que muitas recomendações são controversas, prevê que o leitor poderá discordar vigorosamente de algumas delas e reconhece que outras escolas possuem a mesma legitimidade profissional. Também afirma que os autores não podem reivindicar autoridade final sobre o assunto.

Essa passagem precisa fazer parte de qualquer crítica honesta a Clean Code. A obra não esconde sua origem nem afirma que a Object Mentor tenha descoberto a única maneira profissional de escrever software. O livro recomenda, inclusive, que o leitor conheça outros mestres e amplie sua prática para além daquela escola.

O problema surge dentro da própria formulação dessa ressalva. Martin declara que as opiniões do livro serão apresentadas como absolutos e que ele não pretende se desculpar pela estridência. Para os autores, naquele momento de suas carreiras, aquelas recomendações eram absolutas dentro da escola que haviam construído. Em poucos parágrafos, o texto pede que o leitor reconheça a legitimidade de outras abordagens e, ao mesmo tempo, prepara o terreno para defender suas próprias escolhas com uma linguagem deliberadamente categórica.

Essa tensão tem uma consequência prática importante. Uma pessoa em início de carreira, e muitas vezes até em um estágio intermediário, ainda está formando o repertório e o discernimento necessários para consumir essas recomendações com um grão de sal. Sem experiência suficiente para reconhecer os contextos, as exceções e os custos envolvidos, torna-se difícil separar um princípio amplamente aplicável de uma heurística circunstancial, uma preferência estilística ou uma opinião particular dos autores e de sua escola de pensamento. Quando essas distinções são apresentadas por profissionais reconhecidos, em um livro que associa suas práticas à qualidade e ao profissionalismo, a tendência é incorporá-las como regras antes de desenvolver os instrumentos necessários para questioná-las. É nesse ponto que começa o problema.

A comparação com artes marciais ajuda a compreender a proposta, mas também estabelece uma relação peculiar entre mestre e aprendiz. O estudante deve se dedicar às técnicas de uma escola, praticá-las até incorporá-las e, somente depois, procurar outros mestres. Essa estrutura favorece um período inicial de aceitação no qual as regras são tratadas como corretas dentro do sistema que lhes dá origem. Para uma atividade técnica, entretanto, a coerência interna de uma escola não encerra a discussão sobre os efeitos de suas recomendações.

A ressalva de “Schools of Thought” protege o livro de uma leitura excessivamente literal, mas não transforma todas as afirmações posteriores em simples preferências pessoais. Sempre que Martin associar uma prática à única maneira de trabalhar com rapidez, à definição de código limpo ou à própria condição de profissional, haverá uma afirmação que pode e deve ser examinada tecnicamente.

O custo de uma bagunça

O capítulo começa com uma premissa difícil de contestar: código ruim possui um custo. Na seção “The Total Cost of Owning a Mess” (“O custo total de manter uma bagunça”, em tradução livre), Martin descreve sistemas nos quais cada alteração quebra outras partes e equipes cuja produtividade diminui à medida que a base de código se torna mais difícil de compreender. Qualquer pessoa que tenha trabalhado por tempo suficiente em sistemas legados provavelmente reconhecerá alguma parte dessa descrição.

Na subseção “The Grand Redesign in the Sky” (“A grande reescrita dos sonhos”, em tradução livre), uma equipe tenta substituir integralmente um sistema cuja manutenção se tornou inviável. O título sugere uma solução idealizada, atraente em princípio, mas irrealista ou dificilmente alcançável. Enquanto o novo sistema procura reproduzir as funcionalidades existentes, o antigo continua recebendo alterações, fazendo com que a substituição persiga um alvo em movimento. Martin afirma já ter visto esse processo durar dez anos e terminar com a nova equipe pedindo a reescrita do sistema que deveria substituir o anterior.

Eu vi uma versão surpreendentemente literal dessa história. Trabalhei em uma empresa que mantinha uma das maiores bases de código Erlang do mundo. Em determinado momento, foi descoberto um bug que comprometia diretamente o uso do produto e a empresa ainda não havia encontrado, dentro ou fora da equipe, alguém que conseguisse corrigi-lo. Diante disso, decidiu iniciar uma grande reescrita em Java.

A decisão criou duas facções antagônicas dentro da empresa. Uma continuava responsável pelo sistema original em Erlang, enquanto a outra trabalhava em seu futuro substituto. Como o produto não podia deixar de evoluir durante a reescrita, os dois sistemas passaram a receber novas funcionalidades, cada um com sua própria equipe e seu próprio backlog. O sistema em Java tentava alcançar uma base em Erlang que continuava se movendo, exatamente como na situação descrita por Martin.

A reescrita nunca terminou. Em algum momento, a empresa contratou alguém maluco e habilidoso o suficiente para encontrar e corrigir o bug no sistema original. A justificativa técnica que havia iniciado o projeto desapareceu, mas já era tarde demais para voltar atrás. A reescrita havia acumulado investimento, equipes, compromissos e dependências suficientes para adquirir vida própria.

Como os dois sistemas continuaram existindo, um terceiro projeto precisou ser criado para servir como camada de abstração entre eles e o restante da empresa. A arquitetura final passou a incluir o sistema original, seu substituto incompleto e uma nova camada destinada a esconder a coexistência dos dois. A iniciativa que deveria substituir uma base considerada impossível de manter terminou ampliando a quantidade de sistemas, equipes e interfaces que precisavam ser mantidos.

Minha experiência torna a narrativa de Martin imediatamente reconhecível, mas continua sendo um caso particular. Ela demonstra que uma grande reescrita pode assumir essa dinâmica, sem estabelecer que toda reescrita seguirá o mesmo caminho. Também não permite concluir que a dificuldade para corrigir o bug tenha sido causada exclusivamente pela qualidade do código em Erlang. Escassez de conhecimento, decisões arquiteturais, perda de contexto histórico e características do próprio domínio podem ter contribuído para o problema. A correspondência mais clara com o relato de Clean Code está na tentativa de substituir integralmente um sistema que continuava evoluindo e no custo organizacional acumulado enquanto o novo sistema perseguia esse alvo móvel.

A situação descrita é plausível e bastante conhecida na indústria. O problema está na maneira como parte do argumento é construída. O livro também apresenta a história de uma empresa que teria sido levada ao fracasso pela deterioração de seu código, sem identificá-la ou oferecer elementos que permitam verificar a relação de causalidade. O gráfico que representa a queda de produtividade funciona como ilustração, sem dados ou método que o transformem em evidência. A familiaridade da narrativa ajuda o leitor a reconhecer o problema, mas não demonstra que código ruim tenha sido a causa determinante da falência daquela empresa ou que toda base de código desorganizada seguirá a mesma trajetória.

A moralização da qualidade do código

A discussão se torna ainda mais categórica na seção “Attitude” (“Atitude”, em tradução livre). Martin atribui aos programadores uma parcela considerável da responsabilidade pela degradação do código e rejeita explicações baseadas em prazos, mudanças de requisitos, decisões gerenciais ou pressões comerciais. Sua intenção parece ser combater a postura passiva de quem culpa a organização enquanto continua produzindo código difícil de manter. Essa cobrança por responsabilidade profissional possui valor, principalmente em ambientes nos quais desenvolvedores evitam comunicar riscos ou aceitam decisões técnicas que sabem ser prejudiciais.

A analogia usada para sustentar o argumento compara o programador a um médico que se recusaria a realizar uma cirurgia sem lavar as mãos, mesmo que o paciente exigisse rapidez. A comparação concede força moral à posição do desenvolvedor, mas aproxima duas situações com riscos, responsabilidades e níveis de autoridade bastante diferentes. Uma decisão sobre higiene cirúrgica possui evidências médicas, protocolos estabelecidos e consequências diretas para a vida do paciente. Uma discussão sobre duplicação, tamanho de funções ou prazo de entrega costuma envolver incerteza, compromissos comerciais e alternativas tecnicamente defensáveis.

Ao afirmar que ceder à vontade de gestores que não compreendem os riscos é uma atitude não profissional, o livro desloca parte da discussão técnica para o terreno moral e cria um problema potencialmente perigoso. O desenvolvedor não é dono do sistema, do orçamento ou da empresa e raramente possui autoridade para decidir sozinho quanto risco o negócio deve aceitar. Sua responsabilidade profissional inclui identificar as consequências técnicas, comunicá-las de forma compreensível, propor alternativas e participar da decisão, mas isso não lhe concede controle absoluto sobre prioridades, prazos e investimentos.

Maturidade profissional, nesse contexto, não consiste em defender uma concepção particular de código limpo a ferro e fogo. Ela aparece na capacidade de negociar uma solução que considere as necessidades técnicas e comerciais, talvez reduzindo o escopo, registrando uma dívida técnica, delimitando a vida útil de uma solução provisória ou combinando condições para uma correção posterior. Uma postura inflexível pode colocar o emprego do desenvolvedor em risco, prejudicar o projeto e reduzir sua influência sobre decisões futuras, sem necessariamente produzir um sistema melhor.

Há situações em que a recusa é uma obrigação, especialmente diante de riscos à segurança, violações legais, fraude ou consequências graves para outras pessoas. A maioria das divergências sobre qualidade interna de código, entretanto, não possui a mesma natureza da higiene necessária antes de uma cirurgia. Ao usar essa analogia, Martin transforma uma negociação sujeita a contexto e compromisso em um teste moral de profissionalismo.

Na seção “The Primal Conundrum” (“O dilema fundamental”, em tradução livre), Martin declara que a única maneira de cumprir um prazo e trabalhar rapidamente consiste em manter o código tão limpo quanto possível durante todo o tempo. A expressão “única maneira” transforma uma recomendação razoável sobre manutenção em uma afirmação universal que o capítulo não demonstra. Ela também ignora que decisões profissionais são tomadas dentro de organizações, sob restrições técnicas, financeiras e humanas que não desaparecem apenas porque o desenvolvedor está convencido de que sua solução é a mais correta.

Uma solução provisória, conscientemente limitada e acompanhada de riscos conhecidos, pode ser a decisão profissional mais adequada. Protótipos descartáveis, respostas emergenciais, experimentos, migrações transitórias e sistemas com vida útil curta não recebem necessariamente o mesmo investimento destinado a uma plataforma que deverá ser mantida por décadas. A dificuldade está em evitar que o provisório se torne permanente sem que ninguém perceba, mas essa possibilidade não elimina a necessidade de avaliar custos, prazo e expectativa de vida do software.

O nascimento do mito

Clean Code oferece uma combinação poderosa para a formação de um cânone. O livro apresenta problemas que quase todos os desenvolvedores reconhecem, associa suas soluções à experiência de profissionais respeitados e emprega uma linguagem moral ligada a cuidado, disciplina e profissionalismo. Ao mesmo tempo, fornece regras fáceis de memorizar e exemplos que parecem confirmar uma visão coerente sobre como o código deveria ser escrito.

A ressalva de que existem outras escolas exige uma leitura mais cuidadosa do que afirmações sobre a única maneira de trabalhar rapidamente ou sobre a relação entre testes e limpeza. Quando as ideias circulam fora do livro, as formulações categóricas sobrevivem com mais facilidade do que as limitações apresentadas no primeiro capítulo. O resultado é uma versão de Clean Code formada por mandamentos, frequentemente aplicada sem os estudos de caso, sem a reflexão proposta na introdução e sem o reconhecimento de que a própria obra se apresenta como produto de uma escola específica.

Essa transformação não pode ser atribuída exclusivamente aos leitores. Martin reconhece a pluralidade de abordagens, mas escolhe defender suas opiniões como absolutos dentro de sua escola. O mito de Clean Code como fonte definitiva nasce do encontro entre uma comunidade interessada em respostas claras e um livro disposto a oferecê-las com grande confiança.

A leitura adotada nesta série aceitará a advertência feita pelo próprio autor. A Object Mentor não possuía autoridade final sobre desenvolvimento de software, suas práticas foram construídas dentro de um contexto histórico e profissional específico e suas recomendações podem conviver com outras escolas. Essa abertura não impedirá uma análise crítica das passagens em que preferências são apresentadas como necessidades, experiências são usadas como prova e escolhas técnicas recebem um peso moral maior do que seus argumentos conseguem sustentar.

A melhor defesa e a crítica mais consistente de Clean Code começam no mesmo lugar: a leitura daquilo que o livro realmente diz.

[pt-BR] AWS Landing Zones na prática - Parte 1

Plínio Balduino — Wed, 19 Aug 2026 15:00:00 +0000

Quando uma organização começa a utilizar AWS, é relativamente comum que tudo nasça dentro de uma única conta.

No começo, isso parece razoável. Uma conta contém algumas VPCs, aplicações, bancos de dados, buckets e usuários. Com o crescimento do ambiente, porém, começam a surgir perguntas mais difíceis:

Produção e desenvolvimento deveriam estar na mesma conta?, Onde devem ficar os logs de auditoria?, Como impedir que uma equipe desative controles de segurança?, Como conceder acesso a dezenas ou centenas de contas?, Como garantir que novas contas sejam criadas seguindo os mesmos padrões?, Como aplicar políticas corporativas sem configurar cada conta individualmente? e Como separar workloads, segurança, infraestrutura compartilhada e billing?.

É nesse contexto que surge o conceito de Landing Zone.

O que é uma Landing Zone?

A AWS define uma Landing Zone como um framework de orquestração para o ambiente AWS fundamental da organização.

Ela estabelece uma baseline para aspectos como:

arquitetura multi-account, Identity and Access Management, governança, segurança de dados, arquitetura de rede, logging, estrutura de contas, billing e mecanismos de customização..

Portanto, uma Landing Zone não é simplesmente uma VPC preparada para receber aplicações.

Também não é apenas uma estrutura de AWS Organizations.

E não é sinônimo de AWS Control Tower.

Uma maneira útil de pensar no conceito é:

A Landing Zone é a fundação sobre a qual os workloads da organização serão construídos.

Antes de migrarmos ou criarmos aplicações, estabelecemos as regras do terreno.

Uma arquitetura multi-account

Um dos princípios centrais de uma Landing Zone é utilizar AWS Accounts como fronteiras de isolamento.

Em vez de construir algo como:

AWS Account
├── VPC Development
├── VPC Staging
├── VPC Production
├── Security
├── Logs
└── Shared Services

podemos estabelecer uma estrutura semelhante a:

AWS Organization
│
├── Security OU
│   ├── Log Archive Account
│   └── Audit Account
│
├── Infrastructure OU
│   ├── Network Account
│   └── Shared Services Account
│
├── Workloads OU
│   ├── Development Account
│   ├── Staging Account
│   └── Production Account
│
└── Sandbox OU
    ├── Developer A
    └── Developer B

Essa separação cria fronteiras mais fortes entre workloads e responsabilidades.

Uma falha de configuração em uma conta de desenvolvimento, por exemplo, não precisa conceder acesso aos recursos da conta de produção.

A AWS recomenda que workloads de produção não sejam executados na management account de uma organização gerenciada pelo Control Tower.

O que uma Landing Zone deve resolver?

Segundo a AWS Prescriptive Guidance, a configuração inicial deve tratar pelo menos de estrutura de contas, identidade, governança, segurança, rede, logging, billing e mecanismos de customização.

Estrutura de contas

É necessário definir como as AWS Accounts serão organizadas e quais Organizational Units (OUs) serão utilizadas.

Por exemplo:

Root
├── Security
├── Infrastructure
├── Workloads
└── Sandbox

Estrutura de rede

A Landing Zone deve estabelecer padrões de conectividade e governança para componentes como:

VPCs, subnets, DNS, Transit Gateway, conectividade híbrida, Direct Connect, VPN, firewalls e IP Address Management..

Ela não precisa necessariamente criar toda a infraestrutura de rede de cada workload, mas deve definir como essa infraestrutura será organizada e governada.

Identity

Também é necessário definir como pessoas e sistemas acessam as contas.

Isso normalmente envolve:

IAM, IAM Identity Center, roles, permission sets e federação com provedores de identidade corporativos..

Logging e auditoria

Logs de auditoria não deveriam existir apenas dentro da própria conta que está sendo auditada.

Uma arquitetura comum centraliza esses registros em uma conta dedicada:

Application Accounts
        │
        ├── CloudTrail
        ├── AWS Config
        └── Security Logs
                │
                ▼
        Log Archive Account

Isso reduz a possibilidade de um comprometimento da conta de workload resultar também na destruição das evidências necessárias para auditoria ou investigação.

Governance

A organização precisa determinar quais ações são permitidas ou proibidas.

AWS Organizations permite, por exemplo, utilizar Service Control Policies (SCPs) para estabelecer limites máximos de permissões.

Em vez de depender de cada equipe para configurar individualmente todos os controles, podemos estabelecer políticas organizacionais como:

Workloads não podem desabilitar determinados mecanismos de segurança.

Landing Zone não é Control Tower

Essa distinção é importante.

A documentação da AWS diferencia duas abordagens principais:

uma service-based landing zone, utilizando AWS Control Tower;
uma customized landing zone, construída pela própria organização.

O AWS Control Tower é, portanto, uma implementação gerenciada do conceito de Landing Zone — não o conceito em si.

Landing Zone com AWS Control Tower

O AWS Control Tower automatiza boa parte da criação e governança de um ambiente multi-account.

Ele orquestra diferentes serviços AWS envolvidos nessa fundação, incluindo AWS Organizations, IAM Identity Center, AWS Service Catalog, AWS CloudTrail e AWS Config.

Uma estrutura inicial típica inclui:

Management Account
│
└── AWS Organization
    │
    ├── Security OU
    │   ├── Log Archive
    │   └── Audit
    │
    └── Workload OUs

O Log Archive Account funciona como repositório central para logs, enquanto o Audit Account fornece capacidades destinadas às equipes de segurança e compliance.

Controls

Outro componente importante são os Controls, anteriormente conhecidos principalmente como guardrails.

Eles representam mecanismos de governança aplicados ao ambiente. O Control Tower trabalha com controles de diferentes comportamentos, incluindo:

preventive, detective e proactive..

Um control pode impedir determinadas operações, enquanto outro pode detectar recursos que deixaram de atender a uma regra.

Isso muda a natureza da governança:

Provisionar → Configurar → Torcer para ninguém alterar

passa a ser:

Provisionar
     ↓
Aplicar baseline
     ↓
Monitorar continuamente
     ↓
Detectar ou impedir desvios

Account Factory

Outro recurso importante é o Account Factory, usado para padronizar o provisionamento de novas contas.

Em vez de:

Ticket → Cloud Team → configuração manual → nova conta

podemos caminhar para:

Solicitação
     ↓
Account Factory
     ↓
AWS Account
     ↓
Baseline
     ↓
OU
     ↓
Controls

Isso se torna especialmente relevante em organizações que administram dezenas ou centenas de AWS Accounts.

Landing Zone customizada

Também é possível construir uma Landing Zone sem utilizar Control Tower.

Nesse cenário, podemos combinar diretamente serviços como:

AWS Organizations
+
Organizational Units
+
SCPs
+
IAM Identity Center
+
CloudTrail
+
AWS Config
+
Security Hub
+
GuardDuty
+
VPC / Transit Gateway
+
Infrastructure as Code

Terraform, CloudFormation ou outras ferramentas podem então automatizar essa arquitetura.

Por exemplo:

Terraform
   │
   ├── AWS Organizations
   ├── Organizational Units
   ├── Accounts
   ├── SCPs
   ├── IAM
   ├── Logging
   └── Networking
   │
   ▼
Custom Landing Zone

Nesse modelo, a organização possui maior liberdade sobre a implementação.

O preço dessa liberdade é assumir também a responsabilidade pela evolução, manutenção, testes, upgrades e tratamento de drift da plataforma.

Control Tower versus Landing Zone customizada

Aspecto	Control Tower	Customizada
Provisionamento inicial	Mais simples	Mais complexo
AWS best practices	Incorporadas ao modelo	Precisam ser implementadas
Flexibilidade	Alta, dentro do modelo do serviço	Muito alta
Governança	Controls integrados	Implementação própria
Account provisioning	Account Factory	Pipeline próprio
Manutenção	Parcialmente gerenciada pela AWS	Responsabilidade da equipe
Curva de aprendizado	Menor	Maior
Customização extrema	Pode exigir adaptações	Natural
Drift management	Integrado ao modelo do Control Tower	Precisa ser projetado
Integração com legado	Pode exigir adaptação	Maior liberdade

Essa comparação não significa que Control Tower seja uma solução para iniciantes e uma Landing Zone customizada seja uma solução para arquitetos experientes.

A decisão é arquitetural.

Uma organização grande pode preferir Control Tower justamente para reduzir a quantidade de plataforma que precisa manter internamente.

Outra organização pode possuir requisitos de rede, compliance, identidade ou provisionamento tão específicos que uma implementação customizada faça mais sentido.

Vantagens

Isolamento

AWS Accounts tornam-se fronteiras de segurança.

Um comprometimento em uma conta de desenvolvimento não implica automaticamente comprometimento da conta de produção.

Governança centralizada

Políticas podem ser aplicadas no nível da organização ou de uma OU:

Organization
     │
     ├── SCPs
     ├── Controls
     ├── Identity
     └── Logging

Isso reduz configurações divergentes entre contas.

Escalabilidade organizacional

Criar a décima conta manualmente talvez seja aceitável.

Criar a conta número 500 dessa maneira provavelmente não será.

Uma Landing Zone transforma a criação e configuração de contas em uma capacidade da plataforma.

Segurança

A separação entre workloads, security, audit, logging e infrastructure reduz o blast radius e melhora a segregação de responsabilidades.

Migrações

Landing Zones são particularmente importantes em programas de cloud migration.

Antes de migrar centenas de workloads, cria-se uma fundação comum para recebê-los.

A AWS Prescriptive Guidance trata a Landing Zone como uma base segura para suportar migração e posterior customização do ambiente.

Desvantagens

Landing Zones também possuem custos arquiteturais.

Complexidade

Uma arquitetura multi-account introduz conceitos adicionais:

cross-account IAM, SCPs, Organizations, resource sharing, centralized networking, centralized logging e account lifecycle..

Para uma aplicação pequena, isso pode representar complexidade desnecessária.

Custo operacional

Mais contas normalmente significam mais infraestrutura compartilhada e serviços de governança.

Logs, AWS Config, NAT Gateways, Transit Gateway, serviços de segurança e observabilidade podem gerar custos relevantes.

Troubleshooting

Em uma arquitetura simples:

Application → Database

o troubleshooting tende a permanecer dentro de uma conta.

Em uma arquitetura corporativa:

Application Account
        ↓
Transit Gateway
        ↓
Network Account
        ↓
Firewall
        ↓
Shared Services

o problema pode atravessar várias fronteiras administrativas.

Restrições de governança

Governança forte também pode reduzir autonomia.

Um desenvolvedor pode possuir AdministratorAccess dentro de uma conta e ainda assim não conseguir executar determinada operação porque uma SCP estabelece um limite organizacional.

Isso é proposital, mas pode gerar atrito se a Landing Zone for mal projetada.

Quando usar?

Landing Zones fazem bastante sentido quando existe:

estratégia multi-account, múltiplos ambientes, vários times, workloads críticos, requisitos de compliance, necessidade de auditoria, migração de múltiplos sistemas, necessidade de padronização e crescimento significativo esperado..

Para um cenário como:

uma aplicação
+
uma equipe pequena
+
uma conta AWS
+
baixo requisito regulatório

uma Landing Zone completa pode ser excessiva.

Para um cenário como:

50 aplicações
+
20 equipes
+
produção
+
requisitos regulatórios
+
múltiplas regiões
+
centenas de AWS Accounts

a ausência de uma estratégia de Landing Zone tende a se tornar um problema arquitetural.

Control Tower ou customizada?

Uma pergunta inicial razoável é:

Existe alguma exigência concreta que impeça ou torne inadequado o uso do Control Tower?

Se a resposta for não, Control Tower normalmente merece ser considerado primeiro.

A AWS gerencia parte importante da orquestração e fornece controles, Account Factory e uma baseline baseada nas práticas recomendadas da plataforma.

Uma Landing Zone customizada passa a ser particularmente interessante quando requisitos organizacionais não se encaixam adequadamente nesse modelo.

Existe ainda uma terceira possibilidade bastante importante: Control Tower + customizações.

Não precisamos escolher exclusivamente entre:

Control Tower

Tudo construído manualmente

Podemos ter:

AWS Control Tower
       │
       ├── baseline
       ├── governance
       ├── account lifecycle
       │
       ▼
Customizações
       │
       ├── Terraform
       ├── CloudFormation
       ├── networking
       ├── security tooling
       └── corporate standards

Para muitas organizações, esse é um ponto de equilíbrio interessante entre padronização e flexibilidade.

Nas próximas partes

Agora temos uma distinção fundamental:

Landing Zone ≠ AWS Control Tower

Control Tower é uma das formas de implementar e operar uma Landing Zone.

Na Parte 2, construiremos uma Landing Zone programaticamente utilizando AWS CLI, explorando AWS Organizations, AWS Control Tower, o Landing Zone Manifest e o acompanhamento das operações assíncronas.

Na Parte 3, abordaremos a implementação utilizando Terraform, transformando a fundação da organização em Infrastructure as Code e discutindo uma questão importante: quem deve ser responsável pelo lifecycle da Landing Zone — Terraform ou Control Tower?

Também veremos como o recurso aws_controltower_landing_zone do AWS Provider for Terraform permite administrar uma Landing Zone do Control Tower por Infrastructure as Code.

Referências

AWS Prescriptive Guidance — Set up a secure AWS landing zone

AWS Control Tower User Guide

AWS Control Tower — How AWS Control Tower works

AWS CLI — controltower create-landing-zone

Terraform AWS Provider — aws_controltower_landing_zone.

[pt-BR] Depurando um crash de use-after-free no meniOS

Plínio Balduino — Tue, 14 Oct 2025 22:32:52 +0000

Há uns dois anos, escrevi aqui que estava escrevendo um sistema operacional chamado meniOS, quase do zero. (Leia aqui).

Novamente fiquei um bom tempo parado, com a vida e a correria engolindo nossos momentos de lazer, mas voltei a brincar com ele.

A coisa avançou bastante nos últimos tempos, e atualmente é possível executar pequenos binários fora do kernel, na área chamada user space, onde rodam quase todos os softwares que usamos no dia a dia.

Conforme o sistema vai crescendo, cada vez mais partes vão trabalhando juntas e dependendo umas das outras, e vai ficando cada vez mais difícil entender porque um erro acontece.

Para ajudar a navegar entre vários e vários logs cheios de números hexadecimais que eu mesmo mandei imprimir mas não entendia muito bem o que significavam, criei esse pequeno guia, que mostra, passo a passo, como diagnosticar um crash provocado por acesso a memória já liberada (use-after-free). O objetivo é destacar o processo e as ferramentas que uso no meniOS, como nm, objdump e um script em Python com pyelftools, para transformar um endereço de falha em uma linha de código. Ao final, teremos um roteiro reaproveitável para incidentes parecidos.

1. Prepare o cenário

O binário de exemplo é intencionalmente falho: ele libera um ponteiro e logo em seguida tenta escrever naquele endereço. Não por coincidência, essa é uma das principais causas de tela azul no Windows, ou seja lá que cor estejam usando hoje em dia.

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    char *ptr = malloc(128);
    if (ptr == NULL) {
        perror("malloc");
        return EXIT_FAILURE;
    }

    free(ptr);
    printf("Dereferencing freed pointer...\n");

    *ptr = 'A';  // Use-after-free: provoca crash
    printf("Value: %c\n", *ptr);

    return EXIT_SUCCESS;
}

Compilar com símbolos de depuração deixa o código-fonte acessível na desmontagem e nas tabelas DWARF; esse formato armazena metadados de depuração no ELF, incluindo o mapeamento entre endereços de instruções, arquivos e números de linha, o que é essencial para relacionar endereços a trechos de código.

gcc -g -O0 -Wall -Wextra use_after_free.c -o use_after_free

O meniOS executa binários no formato ELF, sigla para Executable and Linkable Format. Esse contêiner descreve cabeçalhos, seções e tabelas necessárias para carregar o programa na memória, incluindo as tabelas de símbolos que nm lê e as seções de código que objdump desmonta. Como o ELF também embute as extensões de depuração DWARF geradas pelo compilador, conseguimos cruzar endereços de instruções com arquivos de origem e, a partir disso, chegar rapidamente à linha com defeito.

Enquanto não há suporte a bibliotecas compartilhadas (.so), cada aplicativo do meniOS é entregue como um executável ELF independente. Compilo esses binários na máquina host e copio o resultado para a mesma imagem de disco utilizada no boot do sistema, mantendo o fluxo de build simples e previsível.

2. Reproduza o crash e capture o endereço

Executando o programa no meniOS, ou no ambiente host caso esteja testando localmente, o kernel interrompe o processo assim que detecta o acesso inválido:

Dereferencing freed pointer...
  User page fault at 0x0000555555555000 (present=yes write=yes), terminating pid=17
proc_exit: Process init/use_after_free exited with status 11

Quando o crash é coletado via console serial do meniOS, o log inclui ainda o contexto de sistema de chamadas. Logo antes da falha, a saída típica de write(1, …) registra o ponto para o qual a execução retornaria:

syscall_dispatch: pid=17 number=1 rip=40112f cs=3b rsp=bfdfd0
syscall_dispatch: post-handler rip=401168 cs=3b rsp=bfdf10 rax=32
mosh: process terminated by signal 11

Anote dois dados essenciais: rip=0x401168, que aponta para a instrução que falhou, e o nome do binário (use_after_free), porque é nele que vou procurar a origem.

3. Descubra o símbolo com `nm`

Comece localizando qual função cobre o endereço problemático. O nm lista a tabela de símbolos do executável, indicando o intervalo de cada função.

nm -an use_after_free | grep -i main

Saída típica:

00000000004010f0 t _start
0000000000401120 T main

main começa em 0x401120. Como 0x401168 ainda está próximo, é razoável assumir que a falha ocorreu dentro dessa função, mas é prudente confirmar.

4. Navegue no assembly com `objdump`

O objdump permite correlacionar instruções com o código-fonte. Use as opções --source e --line-numbers para misturar C e assembly; limite a saída a um trecho curto com sed.

objdump -d --no-show-raw-insn --source --line-numbers use_after_free \
  | sed -n '35,60p'

Trecho relevante:

use_after_free.c:16
    *ptr = 'A';  // Use-after-free: provoca crash
  401164:  mov    -0x8(%rbp),%rax
  401168:  movb   $0x41,(%rax)          ; 0x41 == 'A'

use_after_free.c:17
    printf("Value: %c\n", *ptr);

Isso confirma visualmente: a instrução em 0x401168 é exatamente a escrita com 'A'. Se o log apontar um endereço alguns bytes adiante, use o mesmo procedimento para encontrar a linha correspondente.

5. Resolver linha e arquivo com Python + `pyelftools`

As tabelas DWARF do executável guardam, para cada unidade de compilação, a sequência de endereços e as respectivas linhas do código-fonte. Para automatizar o mapeamento de endereços, um script curto em Python consulta esse material. Esse procedimento economiza tempo quando coleto crashes em lote ou quando quero integrar a análise em pipelines de CI.

#!/usr/bin/env python3

import os
import sys
from elftools.elf.elffile import ELFFile

def lookup(addr, path):
    with open(path, "rb") as f:
        elf = ELFFile(f)
        dwarf = elf.get_dwarf_info()
        for cu in dwarf.iter_CUs():
            lineprog = dwarf.line_program_for_CU(cu)
            prev = None
            for entry in lineprog.get_entries():
                if entry.state is None:
                    continue
                state = entry.state
                if state.end_sequence:
                    prev = None
                    continue
                if prev and prev.address <= addr < state.address:
                    file_entry = lineprog["file_entry"][prev.file - 1]
                    comp_dir_attr = cu.get_top_DIE().attributes.get("DW_AT_comp_dir")
                    comp_dir = ""
                    if comp_dir_attr:
                        comp_dir = comp_dir_attr.value.decode()
                    directory = comp_dir
                    if file_entry.dir_index not in (0, None):
                        include_dirs = lineprog["include_directory"]
                        directory = os.path.join(
                            comp_dir,
                            include_dirs[file_entry.dir_index - 1].decode(),
                        )
                    filename = file_entry.name.decode()
                    full_path = os.path.join(directory, filename) if directory else filename
                    return full_path, prev.line
                prev = state
            if prev and prev.address <= addr:
                file_entry = lineprog["file_entry"][prev.file - 1]
                comp_dir_attr = cu.get_top_DIE().attributes.get("DW_AT_comp_dir")
                comp_dir = comp_dir_attr.value.decode() if comp_dir_attr else ""
                directory = comp_dir
                if file_entry.dir_index not in (0, None):
                    include_dirs = lineprog["include_directory"]
                    directory = os.path.join(
                        comp_dir,
                        include_dirs[file_entry.dir_index - 1].decode(),
                    )
                filename = file_entry.name.decode()
                full_path = os.path.join(directory, filename) if directory else filename
                return full_path, prev.line
    return None, None

if __name__ == "__main__":
    if len(sys.argv) != 3:
        print(f"Uso: {sys.argv[0]} <ELF> <endereco_hex>", file=sys.stderr)
        sys.exit(1)
    binary, raw_addr = sys.argv[1], sys.argv[2]
    address = int(raw_addr, 16)
    src, line = lookup(address, binary)
    if src is None:
        print("Endereço não encontrado.")
        sys.exit(2)
    print(f"{src}:{line}")

Execute assim:

./resolve_addr.py use_after_free 0x401168

Saída:

/path/para/use_after_free.c:16

Integre o script ao seu fluxo de crash dumps no meniOS: basta salvar o endereço de rip e, depois, usar a ferramenta para apontar diretamente para a linha culpada.

6. Confirme a correção

Depois de identificar a origem, ajuste o código para evitar o uso após free. Um fix simples é atrasar a chamada de free ou zerar o ponteiro antes de qualquer acesso:

printf("Dereferencing freed pointer...\n");
ptr[0] = 'A';
printf("Value: %c\n", ptr[0]);
free(ptr);

Recompile, execute e confirme que o crash desapareceu. Aproveite para rodar o binário antigo novamente e validar que seu processo de depuração continua funcionando.

Dicas extras

Garanta que o console serial do meniOS esteja ligado durante os testes. Como o sistema roda hoje em emuladores QEMU ou Bochs, redireciono a porta serial primária para com1.log (ou com1bochs.log, no caso do Bochs); esse console funciona como uma janela de logs do kernel, exibindo tudo o que o sistema imprime por kprintf, incluindo o endereço de instrução, o PID e a syscall ativa no momento do crash; como cada serviço roda em um executável ELF independente, repita o procedimento com o binário correspondente na imagem do meniOS; se quiser detectar problemas dessa classe automaticamente em paralelo no host, compile versões instrumentadas com AddressSanitizer e execute-as no Linux ou no macOS, onde o runtime já está disponível.

Seguindo esses passos você transforma um crash misterioso em uma linha específica do código-fonte.

Achei importante documentar isso aqui para, caso eu pare novamente de brincar com isso, ao voltar eu consiga me virar com certa rapidez. E também para que você, leitor(a) se sinta convidado(a) a participar desse desenvolvimento.

[pt-BR] Criando um sistema operacional (quase) do zero

Plínio Balduino — Wed, 20 Sep 2023 17:16:53 +0000

Introdução

Há uns três anos, sem nenhum bom motivo, eu resolvi que iria escrever um sistema operacional do zero. Comecei com o bootloader, depois parti para o kernel e fiquei empacado. Bateu o desânimo, a falta de tempo, e o projeto ficou lá, abandonado.

Recentemente, novamente sem qualquer bom motivo, resolvi resgatar esse projeto e usar as lições aprendidas no processo e nesses anos afastado.

Meu plano ao escrever aqui é compartilhar os aprendizados, em Português, e explicar passo a passo o que é cada uma das partes envolvidas que fazem o seu computador funcionar e permitem que você esteja lendo este texto agora.

Não garanto que eu vá chegar ao final, já que desenvolver um sistema operacional é um trabalho gigantesco, mas já será uma grande vitória se isso aqui servir de material de pesquisa para os(as) próximos desenvolvedores(as) que se aventurarem nessa tarefa.

Espero também cobrir uma lacuna nos materiais online, que geralmente estão obsoletos ou incorretos ou mal explicados ou geralmente as três situações ao mesmo tempo.

A ideia também é ir adicionando aqui os links para os próximos passos, então salve este post aqui nos seus favoritos para facilitar a leitura.

[pt-BR] Usando o shell além do básico

Plínio Balduino — Wed, 01 Jun 2022 01:10:37 +0000

Imagem: Hackerman, de shiiftyshift.

Tudo bem, talvez não sejam realmente indispensáveis, mas aprendê-las vai fazer com que você se sinta a própria Hackerperson.

Quando você lida com um sistema operacional compatível com POSIX (alguma variação de UNIX, BSD, Linux, MacOS X, etc), internamente existem dois canais principais para entrada e saída de dados: o stdin e o stdout. Existem mais, mas vamos focar nesses dois.

Um executável pode ler dados de stdin e gravar dados em stdout. Um exemplo disso acontecendo é quando o programa lê dados do teclado e grava, ou exibe, na tela.

O pulo do gato acontece quando você conecta o stdout de um programa com o stdin de outro usando um recurso chamado pipe (cano ou encanamento). O que um programa exibiria na tela passa a ser enviado para o stdin do programa seguinte, que processa aquelas entradas e devolve para o stdout. Você pode conectar inúmeros programas uns nos outros através do pipe, fazendo com que cada pecinha resolva uma parte do problema, transformado o dado e passando para o próximo.

Para nosso exemplo, vamos baixar um arquivo com praticamente todas as palavras da Língua Portuguesa aqui.

Executando cat palavras.txt serão exibidas na tela as mais de trezentas e vinte mil palavras do arquivo. cat lê o arquivo e joga seu conteúdo para stdout, que neste caso é a própria tela.

Vamos usar o pipe para exibir o arquivo em ordem alfabética invertida usando sort:

$ cat palavras.txt | sort -r

Agora, com o caracter de pipe, o |, direcionamos o conteúdo da saída padrão de cat para a entrada padrão de sort, exibindo assim o arquivo em ordem alfabética invertida.

Pode pode paginar a visualização do arquivo usando less e outro pipe:

$ cat palavras.txt | sort -r | less

Pressione espaço para ir para a próxima página, ou Q para sair.

Vamos exibir apenas as palavras do dicionário que contenham o texto pli. Para isso usamos grep, que retorna apenas as entradas que contenham o texto informado:

$ cat palavras.txt | grep pli

Sim, você pode usar grep palavras.txt pli também, mas a ideia aqui é encadear vários pipes para fins didáticos.

E vamos usar sed para deixar a primeira letra de cada palavra em maiúscula. sed aplica uma expressão regular na entrada e retorna o resultado:

$ cat palavras.txt | grep pli | sed 's/[a-z]/\U&/'

Para sabermos quantas palavras existem em nossa seleção, usamos wc:

$ cat palavras.txt | grep pli | wc -l
> 382

Agora, em outro exemplo, vamos listar os arquivos em um diretório qualquer:

$ ls -l

Perceba que os dados vieram exibidos em colunas. Para pegar o conteúdo de apenas uma das colunas, usamos awk, que usa uma linguagem própria com o mesmo nome. Os nomes dos arquivos estão na nona coluna. Então, para selecioná-la, passamos essa informação para o awk:

$ ls -l | awk '{print $9}'

Sim, você poderia ter usado file para isso, mas estou claramente inventando situações para poder demonstrar as ferramentas.

Por fim, vamos usar xargs, que pega os valores que chegam pelo stdin e passam como parâmetros para o comando seguinte. Por exemplo, vamos listar os arquivos e os conteúdos dos diretórios usando ls:

ls -l | awk '{print $9}' | xargs ls

[pt-BR] Como aprendi (e continuo aprendendo) Inglês

Plínio Balduino — Wed, 18 May 2022 16:35:26 +0000

Este texto foi publicado originalmente em 2017 no meu antigo site no Medium. Tenho uma vaga lembrança dele ter sido publicado em outro lugar antes disso, mas o importante aqui é de que se trata de um texto antigo e a evolução não parou de lá para cá.

Antes de mais nada, é válido deixar claro que estou compartilhando aqui minha experiência pessoal. O que funcionou comigo pode não funcionar com você, assim como minha realidade e minhas experiências podem parecer totalmente estranhas para você. Filtre o que você achar importante e relevante, ignore o resto e segue a vida.

Assim como emagrecer, acordar cedo ou começar a fazer exercícios, aprender Inglês é algo que, para a maioria das pessoas, acaba sempre ficando em segundo ou terceiro plano.

No meu caso não foi nada diferente. Desde muito novo eu tive contato com materiais em Inglês, mas sempre tive para mim que eu sabia a linguagem. Eu estava no numeroso grupo que coloca “Inglês Intermediário” no currículo.

Aos vinte eu comecei um curso numa escola que prometia ‘Inglês em 100 horas’. O método deles, ao menos para mim, funcionou muito bem.

Era uma escola onde os professores não conversavam em Português com os alunos. Mesmo com todo o cuidado e toda a didática, era uma situação que te forçava a participar, entender e falar em Inglês. Infelizmente, se você é do tipo tímido ou introvertido, são grandes as chances de evitar interagir num curso desses. Nesse caso eu recomendo outra metodologia ou tentar lutar contra o próprio bloqueio. Não tenho a resposta.

No meu caso, que era tímido e introvertido, ajudou demais ter feito o curso com um amigo que não parava de falar. Eu me sentia à vontade para conversar com ele em Inglês e a coisa fluiu bem.

Por trabalhar com TI, as principais fontes de informação sempre estiveram em Inglês, o que me deixou habituado a ler, mas não a escrever ou conversar. Livros técnicos traduzidos costumam ser péssimos. Os melhores conseguem ser apenas horríveis.

O fato foi que, ao menos por um tempo, esse curso conseguiu melhorar muito a minha conversação e minha compreensão de texto, mas eu ainda não era fluente no idioma.

Eis que, após três meses de curso, sofri um acidente voltando para casa e deixei os estudos de lado por anos.

Como eu disse no começo do texto, aprender um idioma é como emagrecer ou começar fazer exercícios. Para a maioria das pessoas esse hábito só vem depois que algo ruim acontece. Um infarto ou, no meu caso, uma vaga para ganhar quatro vezes mais.

Eu trabalhava numa empresa pequena, realmente pequena, onde havia mais um programador além de mim. O faturamento era pouco, o salário era baixo e minha ambição era nula.

Então me aparece essa oportunidade para trabalhar em uma multinacional suíça e ganhar quatro vezes mais do que eu ganhava:

"Você sabe X?"
- Sei
"E Y?"
- Sei
"E o Inglês?"
- Precisa ser fluente?
"Não existe outro. Ou você sabe, ou não sabe."

E a pré-entrevista acabou ali mesmo.

Fiquei olhando para o telefone. Minha incipiente carreira tinha acabado de sofrer um infarto.

Eu tinha duas opções: reclamar de como a vida era injusta e de como empresas pediam Inglês avançado ou fluente sem a menor necessidade, ou eu poderia aproveitar o tranco para me mexer e sair do marasmo. Como já me disseram, "até um pé na bunda te empurra para frente".

Pensando bem, essa oportunidade já tinha sido perdida mesmo. Uma próxima eu não deixaria escapar. Se for para cair, que seja para cima.

Saí em busca de uma escola de idiomas para voltar a estudar. As melhores estavam bem além do meu orçamento. Sobravam poucas opções. Todas elas franquias de bairro com reputação bem ruim.

Fiz uma entrevista com a coordenadora do curso. Eram sete módulos de seis meses cada, se não me falha a memória, e entrei no quarto. Bom, pelo menos eu estaria convivendo com pessoas que já estavam estudando continuamente há um ano e meio.

No primeiro dia de aula chamei a professora de canto e expliquei o que tinha acontecido. Pedi a ela que, se possível, falasse comigo apenas em Inglês e eu que me virasse para entender e responder. Ela ficou surpresa e feliz com o pedido e já me respondeu em Inglês mesmo, concordando.

Para minha surpresa, os demais alunos pareciam estar ali apenas para cumprir horário. Conversavam entre si em Português e tinham dificuldades de leitura. Me perguntei até que ponto o curso era realmente ruim ou se eram os alunos que nem ao menos se esforçavam.

Um amigo me indicou podcasts para ouvir no ônibus, em Inglês. English as a Second Language, por exemplo, começava com um texto sendo lido bem devagar, em seguida havia uma explicação sobre as palavras chaves ou termos novos e então, o texto ou o diálogo ocorria em velocidade normal.

Ao mesmo tempo, no curso, a professora só conversava comigo em Inglês e, logo, alguns alunos resolveram entrar na brincadeira.

Nesse meio tempo, algo estranho começou a acontecer: eu saia do curso pensando em Inglês e ia assim até chegar em casa. Para mim era algo totalmente estranho pensar em Inglês, sem precisar antes formular a ideia em Português e, só então, traduzir. Era como se tivesse descoberto uma chavinha no cérebro que trocava o idioma. Uma tecla SAP.

Esse amigo que recomendou os podcasts, que inclusive foi o mesmo que me barrou logo na pré-entrevista, comentou que uma forma de falar melhor era ficar bêbado.

“Comigo funcionou”, ele disse.

Eu mal conseguia falar corretamente quando estava sóbrio e também não bebia. Não fazia o menor sentido.

Meses após ter perdido aquela oportunidade, surgiu outra na mesma empresa. O salário seria menor, mas ainda assim era muito mais do que eu recebia na época. Eu era Roberto Baggio novamente na marca do pênalti.

“Você sabe X?”
- Sei
“E Y?”
- Sei
“E o Inglês?”
- Fluente
“Tem certeza? Encara uma entrevista toda em Inglês?”
- Opa. Vamos lá.

Vamos ser honestos: eu não era fluente. Acho bem pouco provável que alguém passe do ponto do "Inglês Intermediário", do "sei mais ou menos" para a fluência em pouco mais de seis meses. Mas o raio não cairia três vezes no mesmo lugar e eu estava me preparando justamente para uma situação assim. Tinha que dar certo. Se eu não acreditasse em mim, ninguém mais acreditaria.

Entenda que o objetivo desse texto não é ser motivacional nem vender uma solução milagrosa para pessoas desesperadas. Estou narrando de forma desnecessariamente honesta e sincera o que eu passei e como eu reagi para que você perceba que tudo é uma questão de tirar a bunda da cadeira e de mudar de postura. Seja por um infarto, seja por um tombo na carreira.

Fiz um pequeno teste prático, recebi algum feedback do avaliador e fui chamado para a entrevista.

Eis que eu estava na recepção da empresa, tremendo, pálido, mal conseguindo falar Português. Havia uma cultura de sigilo na empresa em que mesmo o principal negócio dela não tinha ficado claro para mim até então.

Simplesmente não dava para ficar tranquilo. Tinha tudo para dar errado. O estádio em silêncio, a bola na marca do pênalti, o goleiro olhando para mim como se soubesse que eu ia errar.

Entro na sala de reunião. Um gerente suíço que não falava Português e um engenheiro que falava Inglês tão depressa quanto um americano que tomou muito café.

Começam a me contar sobre a empresa, sobre o projeto e sobre o que era esperado que eu fizesse lá. Em Inglês. Minha cabeça funcionando a cento e dez por cento com medo de perder uma só palavra e botar tudo a perder.

Então preciso contar de forma resumida o que eu tinha feito até então, em que projetos já tinha trabalhado e qual era a minha experiência.

Não teve nada de mágico: gaguejei, tropecei, troquei palavras. Minha pronúncia foi horrível e, em vários momentos, eu precisei repetir a frase de uma forma diferente para que todos entendessem.

O gerente então fez uma pergunta sobre part numbers que fugiu totalmente do escopo da conversa. Olhei em volta, perdido. Vi um quadro branco.

"Can I use the whiteboard?"
- Sure, please._

Para minha sorte, eu já havia trabalhado com um sistema que controlava listas de partes de produtos industrializados. É, como o nome diz, uma lista contendo todas as peças, quantidades e códigos (os tais part numbers) que formam um produto pronto.

Então eu fui ao quadro branco, fiz diagramas, setas e rabiscos explicando, em Inglês, minha ideia sobre o que ele havia perguntado. Levantei cenários alternativos e situações que poderiam ter uma abordagem diferente. De repente, explicando algo que eu conhecia bem, eu não estava mais nervoso. O Inglês, mesmo tosco e manco, era apenas um detalhe. Uma ferramenta.

O gerente gostou. O engenheiro balançou a cabeça aprovando.

Passei.

Gol.

No primeiro mês de empresa fui enviado para um treinamento de um mês na Suíça.

Me enrolei para falar com os comissários de bordo. Me enrolei na imigração. Me enrolei para comprar pão. Me enrolei para entender que diabos o engenheiro que estava dando o treinamento estava falando. Eu esqueci inclusive as palavras para comprar um barbeador e um sabonete.

Na primeira semana lá fui chamado pelos outros colegas para conhecer uma casa noturna da cidade. "Tem música lá, é legal". Fomos.

"E aí, você bebe o que?"

Não bebo "Nada?"
Nada alcoolico. "Certo."

E pediu vodka com Virgin Cola para o bartender. Tomei meio a contragosto, mas pensei comigo que já estava ali, que tinha conseguido. Por que não relaxar e comemorar um pouco?

Não sei quantas eu tomei, lembro que conversamos a noite toda sobre a vida na Suíça, na França, no Brasil, sobre música e, em algum momento eu estava de volta ao hotel. Falando Inglês, pensando Inglês, alcoolizado demais para conseguir desligar a chavinha e voltar a pensar e falar em Português. A recepcionista me perguntou algo, eu respondi em Francês. Tosco, quebrado e errado, mas era Francês.

Descobri. O que me fez falar mais e melhor não foi o álcool, mas a completa perda de inibição. Exatamente como quando fiz o curso de com um amigo na sala. Dane-se que estou falando errado. As pessoas estão entendendo. O errado eu corrijo com o tempo e com a prática.

Aquele camarada sabia das coisas.

De volta ao Brasil, alguém no escritório encontrou um professor particular nativo que aceitou dar aula para três alunos por um preço pagável.

Vale lembrar que, também nessa época, descobri o Duolingo. Apesar das frases estranhas sobre tartarugas que falam e vacas, é gratuito e ajuda muito a melhorar o vocabulário.

Para mim esta foi a forma mais efetiva de aprender Inglês sem precisar sair do país. Se você tiver dinheiro para investir, recomendo de verdade. Quatro aulas por mês custavam uma vez e meia a mensalidade de um curso franqueado de bairro.

Dois anos atrás apareceu uma oportunidade de trabalhar fora. As coisas nessa empresa já não estavam boas, as chances de haver uma demissão em massa eram reais e eu já não estava mais fazendo as aulas particulares. Fiz o processo remotamente e a entrevista por Skype.

Reprovado.

"Gostei da conversa, você tem experiência, conhece as ferramentas, mas não senti firmeza no seu Inglês. Estude mais, pratique mais e, se você ainda tiver interesse, voltaremos a nos novamente falar em um ano".

Mais um chute na bunda. Hora de me mexer.

Voltamos a nos falar um ano depois. Dessa vez fui reprovado sem ao menos ir para a entrevista por Skype. Não tem problema, eu estava fazendo duas entrevistas por semana, toda semana, em Inglês, por Skype e telefone. Estava treinando durante o jogo. Era o que dava pra fazer.

Atualmente eu consigo conversar tranquilamente em Inglês, viajei para o exterior algumas vezes e consegui me virar bem conversando. Sites como o Linguee me ajudam demais a escrever, podcasts e vídeos em Inglês me ajudam a manter o cérebro acostumado com o idioma. O Duolingo ainda me acompanha, mas tem servido bem para aprender Holandês, Alemão ou Sueco.

Uma vez que você consegue fluência em um idioma, o esforço para conseguir fluência em outro é relativamente menor. Seu cérebro já passou por aquilo antes e consegue repetir o processo com menor esforço.

Meus próximos passo são conseguir um trabalho no exterior, conseguir uma boa pontuação no IELTS e, quem sabe, estudar lá fora. Por isso eu treino, treino, estudo e estudo. Sem um objetivo, um foco, uma necessidade real, dificilmente eu teria conseguido me mexer e me esforçar.

Assim como emagrecer, acordar cedo ou começar a fazer exercícios, a maioria das pessoas, incluindo eu, só se mexe quando a água bate forte na bunda.

Update em 18/05/2022: Depois desse texto eu passei num processo seletivo para uma empresa sueca, e morei em Estocolmo por dois anos, me virando na maior parte do tempo em Inglês. Nesse meio tempo fui aprovado também para uma vaga de Líder Técnico no Booking, em Amsterdam, com um processo também totalmente em Inglês, mas acabei recusando.

[pt-BR] Consumindo conteúdo HTTP no Terraform

Plínio Balduino — Mon, 16 May 2022 16:27:09 +0000

Parte de uma série de posts curtos com conhecimentos que podem ser úteis no dia a dia e quero compartilhar. Muitas vezes eles exigem um conhecimento prévio da ferramenta ou da linguagem.

Esses textos curtos são publicados sob a tag #quick.

Existem situações em que você precisa armazenar o conteúdo de um endpoint ou de um arquivo que está online, e esse conteúdo não será modificado dentro daquele contexto.

Por exemplo, trabalhei num projeto em que a geração de tokens JWT era feita pelo AWS Cognito. Para validar o token recebido pelo client e garantir que ele era legítimo, permitindo a liberação do acesso à API, é necessário verificar se o token foi gerado com a mesma chave do Cognito.

Para isso, todo User Pool do Cognito gera um documento público que pode ser consumido pelo seu código. Esse documento fica em https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/jwks.json

Como o conteúdo desse documento nunca será alterado, é um desperdício fazer uma requisição HTTP para esse endereço toda vez que precisarmos validar um token. Como a validação precisa ser rápida e, no contexto de um recurso serverless, somos cobrados pelos tempo de uso, esse acesso extra causa um aumento desnecessário de custos.

Para resolver isso, a requisição HTTP é feita uma única vez, durante o build da aplicação, e esse valor é passado para o código como uma variável de ambiente.

Usando Terraform, bastou fazer assim:


# Aqui criamos o User Pool onde serão armazenadas 
# as credenciais dos usuários
resource "aws_cognito_user_pool" "exemplo" {
  name = "exemplo"

  # um monte de configurações
}

# Aqui armazenamos os dados da região AWS atual
data "aws_region" "current" {}

# E aqui fazemos a requisição HTTP, que terá os 
# parâmetros automaticamente atualizados se você
# mudar de região ou recriar seu User Pool
data "http" "cognito_jwks" {
  url = "https://cognito-idp.${data.aws_region.current.name}.amazonaws.com/${aws_cognito_user_pool.exemplo.id}/.well-known/jwks.json"

  request_headers = {
    Accept = "application/json"
  }
}

# Finalmente, exportamos o conteúdo da requisição 
# para que seja usada em outros módulos do seu projeto
output "cognito_jwks" {
  value = tostring(data.http.cognito_jwks.body)
}

E, no módulo onde você definiu a Lambda, você faz assim:

# essa variável terá um valor atribuído
variable "cognito_jwks" {
  type = string
}

resource "aws_lambda_function" "exemplo" {
  environment {
    variables = {
      COGNITO_JWKS = var.cognito_jwks
    }
  }

Isso funciona com qualquer outro recurso que você criar, não precisa ser necessariamente uma Lambda. COGNITO_JWKS contém um texto e você pode usá-lo da maneira que for melhor para o seu caso.

Ao gerar a Lambda, o conteúdo do arquivo estará disponível como uma variável de ambiente, podendo ser acessado no código com process.env.COGNITO_JWKS, caso você esteja usando JavaScript.

[pt-BR] Convertendo callbacks em promises em JavaScript

Plínio Balduino — Mon, 16 May 2022 15:39:33 +0000

Primeiro de uma série de posts curtos com conhecimentos que podem ser úteis no dia a dia e quero compartilhar. Muitas vezes eles exigem um conhecimento prévio da ferramenta ou da linguagem.

Esses textos curtos serão publicados sob a tag #quick.

Existem situações em que você precisa fazer com que um código que foi pensado para ser executado assincronamente seja executado de forma síncrona. Ao usar promises, você faz isso com o uso da palavra chave await:

await algoAssincrono
  .then(succeeded => console.log("Uhu!"))
  .catch(failed => console.error("Deu ruim"));

A execução do código vai aguardar até que a promise seja finalizada para só então prosseguir.

Quando você está escrevendo um código que exige um comportamento síncrono, como uma AWS Lambda ou o equivalente de qualquer outro fornecedor de Cloud, você precisa garantir que todos os processos terminaram de ser executados antes do retorno da função:

exports.handler = async (event) => {

  return await processoAssincrono(event)
    .then(response => {
      return {
        statusCode: 200,
        body: JSON.stringify(message: response)
      };
    })
    .catch(failure => {
      return {
        statusCode: 400,
        body: JSON.stringify(reason: failure)
      }
    })
}

A função processoAssincrono trata o evento recebido pela Lambda e, caso esteja tudo certo, retorna um status HTTP 200 e um conteúdo que será consumido pelo client, ou um status HTTP 400 caso não esteja tudo certo, com o motivo pelo qual a requisição falhou.

O nosso exemplo processoAssincrono foi pensado para ser assíncrono. Talvez ele consulte um banco de dados, uma API, ou qualquer recurso que poderia causar o bloqueio do event loop, então essa decisão faz todo o sentido, mas dentro de uma Lambda nós precisamos que o processo seja finalizado para só então retornarmos um valor. Com o uso de await, só retornamos um valor depois que a promise terminar sua execução, garantindo que a execução seja síncrona.

Quando você usa um código feito com callbacks, não existe essa possibilidade:

assincronoComCallbacks(
  function(succeeded) { 
    console.log("Funcionou");
  }, 
  function(failed) {
    console.error("Deu erro");
  }
);

Para resolver isso, podemos criar uma promise que só segue em frente quando os callbacks forem executados:

await new Promise((fulfill, reject) => {
  assincronoComCallbacks(
    succeeded => fulfill(succeeded),
    failed => reject(failed)
  });
})
.then(succeeded => console.log("Uhu!"))
.catch(failed => console.error("Deu ruim"));

A função com callbacks continua sendo assíncrona, mas estará encapsulada numa promise, permitindo assim o uso de await, tornando o processo seja executado como se fosse síncrono.