Do Bug do Encoding ao Docker: Como domei o Git e o Django num dia de internet ruim

Imagine a cena: você está em um lugar remoto, a internet parece movida a lenha, o download do Kafka está fora de cogitação, o Windows resolve brigar com o driver do PostgreSQL por causa de um bendito caractere especial, e o Git quer que você comite tudo como se fosse um misto-quente de código. Para muitos, o dia de trabalho teria acabado ali, com um café frio e um leve desespero. Mas para quem tem mentalidade sênior, esse é o cenário perfeito para uma boa história de superação técnica.

Se você já passou por isso ou quer saber como transformamos o caos em uma API, puxe uma cadeira. Vamos falar sobre como a paciência, a estratégia e uma boa dose de humor salvaram o dia.

O Inimigo número 1: O fantasma do UnicodeDecodeError

Tudo começou muito bem. Django instalado, Docker de pé com PostgreSQL, e aquela sensação de que em 5 minutos aplicaríamos as migrations. Até que o terminal do Windows disparou: UnicodeDecodeError: utf-8 codec can't decode byte 0xe7...

O Windows, com toda a sua simpatia, tentou ler variáveis de ambiente locais contendo caracteres especiais e simplesmente se recusou a conversar com o driver antigo do PostgreSQL (psycopg2). A solução? Em vez de brigar com o sistema operacional, mudamos de estratégia. Atualizamos o projeto para o driver Psycopg 3, o queridinho do Django moderno. Ele já vem com suporte nativo a encoding no Windows. O erro de UTF-8 sumiu instantaneamente. Um ponto para nós, zero para o Windows.

O mistério da porta 5432: Ué, mas a senha está certa

Com o problema de encoding resolvido, batemos em outro muro: erro de autenticação. Como assim a senha do usuário vert_user falhou? Ela foi definida no Docker agorinha! Aí entra o faro investigativo de quem já viu de tudo: havia um outro serviço de PostgreSQL rodando silenciosamente na minha própria máquina Windows, escutando a porta padrão 5432. Quando o Django tenta conectar no Docker, ele na verdade batia no banco local antigo e quebrava a cara.

O drible da vaca: fomos no docker-compose.yml, mudamos a porta externa do container para 5433 e ajustamos o settings.py. O Django finalmente conseguiu falar com o banco de dados certo. As migrations passaram voando.

Este projeto é uma API REST desenvolvida em Django e Django REST Framework para o ecossistema de Mercado de Capitais da VERT. O objetivo principal é servir como a camada de persistência e gerenciamento de Operações Financeiras (como CRIs e CRAs) que serão validadas por Agentes de IA.

 A arte de comitar arquivo por arquivo sem o git add .

Com tudo funcionando, veio a tentação. O famoso e perigoso git add . que joga tudo no mesmo balaio. Mas como o objetivo é construir um histórico digno de orgulho (e de aprovação em code reviews), fomos cirúrgicos. Nada de commits genéricos como ajustes. Fizemos commits atômicos, arquivo por arquivo: um para a infraestrutura do Docker, um para a migração inicial do banco, um para o serializer, um para a viewset e um último para as rotas. No final, o histórico do Git não ficou parecendo uma bagunça, mas sim uma linha do tempo perfeitamente narrada.

O que aprendemos com isso

Quando as condições não são ideais, como a falta de internet rápida para baixar novas ferramentas pesadas, a melhor coisa que um desenvolvedor pode fazer é lapidar com excelência o que já está na mão.

1. Documentação é rei: se não dá para avançar no código por limitações técnicas, escreva um README impecável. Ele é o cartão de visitas do seu projeto.
2. Domine o Git: commits organizados mostram maturidade e facilitam a vida de todo o time.
3. Mantenha a calma: erros de porta e encoding são apenas quebra-cabeças esperando a peça certa.

Agora, o projeto Vert Agentic Validator está com a base sólida, o Docker isolado e a API REST pronta para receber a inteligência dos Agentes de IA.

E você? Qual foi a última vez que um pequeno bug de ambiente testou a sua paciência e te transformou em um desenvolvedor melhor? Deixe nos comentários.

https://github.com/viniciushoffmanndev/vert-agentic-validator