DEV Community: Plínio Balduino

[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.