“Véi, Brasília é tudo longe de tudo. Pra ir na padaria são 15 minutos de carro. Pelo menos as tesourinhas ajudam no trânsito.”

O Llama-3.3-70B (Meta) respondeu que tesourinhas eram motocicletas.

O GPT-4o-mini (OpenAI) ficou em cima do muro — disse que poderiam ser rotatórias ou desvios, sem convicção.

O Sabiá-4 (Maritaca AI) acertou direto: passagens de nível, infraestrutura característica do plano urbanístico de Brasília. Quem conhece a cidade sabe.

Esse foi o cenário mais revelador de um benchmark que passei semanas construindo — e que mostra por que um modelo nacional importa.

O que é o Sotaques Digitais

O Sotaques Digitais é um benchmark que criei para testar LLMs numa tarefa específica: entender o português brasileiro como ele é usado no dia a dia digital — redes sociais, WhatsApp, atendimento ao cliente, avaliações de produto.

São 90 cenários divididos em três categorias:

• Ironia (30 cenários) — sarcasmo, antífrase, ironia situacional em contextos digitais
• Expressões Idiomáticas (30 cenários) — expressões do cotidiano brasileiro contemporâneo
• Regionalismos (30 cenários) — vocabulário e referências culturais das 5 macrorregiões

Os modelos comparados:

Modelo	Empresa	Tipo
Sabiá-4	Maritaca AI	Nacional, especializado em PT-BR
GPT-4o-mini	OpenAI	Global, multilíngue
Llama-3.3-70B	Meta (via Groq)	Open source, multilíngue

Como funciona a avaliação

Cada modelo recebeu o mesmo prompt para todos os cenários — sem dica de categoria, sem instrução extra. A instrução era simples:

“Analise o texto abaixo e explique o que o autor realmente quis dizer, considerando o contexto cultural e linguístico do português brasileiro.”

As respostas foram avaliadas pelo GPT-4o como juiz (metodologia LLM-as-a-Judge), em uma escala de 1 a 5 ancorada em gatilhos semânticos específicos de cada cenário. Por exemplo, para um cenário de ironia, o juiz verificava se o modelo detectou o tom sarcástico e não interpretou o elogio literalmente.

Todo o código está no GitHub e o dataset está disponível no Hugging Face.

Os resultados

Visão geral

A diferença entre Sabiá-4 e GPT-4o-mini é de 0,05 ponto em uma escala de 5. Marginal. O Llama varia quase três vezes mais que o GPT-4o-mini — desempenho menos previsível ao longo dos cenários.

Por categoria

Aqui o Sabiá-4 aparece em seu melhor momento.

Em Ironia, o Sabiá-4 atingiu nota máxima — 5,00 — superando os dois concorrentes globais. O mesmo em Expressões Idiomáticas. Em ambas as categorias, o fenômeno testado está no coração do português brasileiro informal: exatamente o tipo de dado que um modelo treinado com foco no idioma tende a internalizar melhor.

Regionalismos por macrorregião

No Centro-Oeste, o Sabiá-4 liderou com nota máxima — exatamente a região onde estava o cenário das tesourinhas. O Llama desabou para 4,17 no Centro-Oeste e no Sudeste.

Distribuição de erros

Sabiá-4 e GPT-4o-mini erraram em apenas 2 cenários cada (scores abaixo de 4). O Llama teve 6 cenários com erros.

Os casos mais interessantes

“As tesourinhas ajudam no trânsito” — só o Sabiá acertou

Este foi o único cenário em que os três modelos tiveram notas diferentes entre si, com o Sabiá-4 claramente à frente:

Tesourinhas é um termo muito específico do cotidiano de Brasília. Esse conhecimento não aparece em grandes portais — ele vive em fóruns locais, grupos de WhatsApp, reportagens do DF. Um modelo que prioriza representação do português brasileiro tem mais chance de capturá-lo.

“O rolê de ontem foi sinistro” — ninguém acertou

O Sabiá-4 e o Llama interpretaram sinistro pelo sentido padrão — algo negativo. Mas no contexto paulistano, sinistro é gíria para “incrível”. Gírias que invertem o sentido original de uma palavra são o desafio mais difícil para qualquer modelo: elas evoluem rápido, aparecem concentradas em comunidades específicas, e o sinal de treino é pequeno.

GPT-4o-mini foi o único que acertou nesse cenário.

“Bergamota” e “de buenas” no Sul

Os modelos identificaram marcadores regionais como bah e trilegal, mas erraram em bergamota (nome regional para tangerina no Sul) e de buenas (estar tranquilo, sem problema). O contexto regional era claro — o erro foi no vocabulário específico.

O que isso nos diz

Um modelo nacional competindo com gigantes globais em seu próprio idioma é, por si só, um resultado relevante. Mas os dados mostram algo mais específico: o Sabiá-4 é melhor onde o português brasileiro é mais cultural e menos lexical — ironia, subentendidos, tom informal.

Regionalismos são o desafio mais difícil para todos. Esse tipo de conhecimento está espalhado na internet de forma fragmentada: portais regionais, grupos locais, comunidades específicas. Capturá-lo vai exigir curadoria intencional — e é exatamente o tipo de aposta que faz sentido para um modelo nacional fazer.

O Llama-3.3-70B mostrou que ter 70 bilhões de parâmetros não substitui representação cultural nos dados de treino.

O que isso nos diz

O resultado central desse benchmark é: o Sabiá-4 compete de igual para igual com modelos globais em português brasileiro, e em duas das três categorias testadas — Ironia e Expressões Idiomáticas — ele lidera.

Regionalismos foram o maior desafio para todos. A explicação mais provável é que esse tipo de fenômeno depende de conhecimento enciclopédico muito específico — saber que sinistro é elogio em SP, que tesourinhas são rotatórias em Brasília, que bergamota é tangerina no Sul. Esse conhecimento está espalhado na internet de forma fragmentada, em portais regionais, fóruns e redes sociais locais. Capturá-lo bem vai depender de curadoria intencional de dados regionais — uma oportunidade clara para modelos nacionais que priorizem essa cobertura.

O Llama-3.3-70B mostrou que ter 70 bilhões de parâmetros não é suficiente quando falta representação cultural específica nos dados de treino.

Como reproduzir

O benchmark é totalmente aberto e reproduzível. Você precisa de três API keys (Maritaca AI, OpenAI e Groq — o Groq é gratuito) e rodar:

git clone https://github.com/ramondomiingos/ptbr-irony-idioms-regionalism-benchmark
cd ptbr-irony-idioms-regionalism-benchmark
python3.12 -m venv .venv && .venv/bin/pip install -r requirements.txt
cp .env.example .env  # preencher as keys
.venv/bin/python src/run_benchmark.py --dry-run  # testa com 3 cenários
.venv/bin/python src/run_benchmark.py            # benchmark completo

git clone https://github.com/ramondomiingos/ptbr-irony-idioms-regionalism-benchmark
cd ptbr-irony-idioms-regionalism-benchmark
python3.12 -m venv .venv && .venv/bin/pip install -r requirements.txt
cp .env.example .env  # preencher as keys
.venv/bin/python src/run_benchmark.py --dry-run  # testa com 3 cenários
.venv/bin/python src/run_benchmark.py            # benchmark completo

O custo total para rodar os 90 cenários nos 3 modelos mais o juiz GPT-4o é de aproximadamente $2–4.

Próximos passos

O benchmark segue em desenvolvimento. Os próximos passos são:

• Calcular concordância entre anotadores (IAA) para fortalecer a metodologia
• Expandir para 500+ cenários com mais variantes regionais e gírias recentes
• Submeter para o PROPOR 2026

O dataset está disponível no Hugging Face com licença CC BY 4.0 — qualquer pessoa pode usar, estender ou testar outros modelos com ele.

Se quiser conversar sobre o projeto, me encontra no LinkedIn ou comentar aqui no post.

O post Sotaques Digitais: um modelo brasileiro consegue entender o português do jeito que a gente fala? apareceu primeiro em Ramon Domingos Blog.

Recentemente, concluí meu mestrado em Engenharia de Software na Universidade Federal do Rio Grande do Norte (UFRN), focado exatamente nessa interseção entre privacidade, conformidade e arquitetura de sistemas distribuídos. O resultado dessa jornada foi muito além da academia: desenvolvemos uma solução tão disruptiva para o mercado que o componente central da pesquisa foi oficialmente patenteado.

Neste post, quero compartilhar a visão de mercado por trás desse projeto e como resolvemos um dos gargalos mais caros da governança de dados moderna.

O Gargalo: O Direito ao Esquecimento em Larga Escala

Para empresas que operam com sistemas legados ou arquiteturas modernas baseadas em microsserviços, o cumprimento do Direito ao Esquecimento (a exclusão definitiva dos dados a pedido do titular) é um pesadelo operacional.

Em estruturas complexas, os dados de um único cliente não estão centralizados. Eles estão espalhados por dezenas de bancos de dados relacionais e não-relacionais, filas de mensageria, data lakes e caches. Quando um usuário solicita a exclusão:

• O risco operacional aumenta: Como garantir, de forma auditável, que o dado foi apagado em todos os pontos sem causar inconsistências no sistema?
• O custo financeiro dispara: Interromper times de engenharia para criar soluções customizadas e manuais de exclusão a cada nova API é financeiramente insustentável.
• A segurança jurídica fica fragilizada: Sem uma orquestração automatizada, o risco de falha humana e sanções administrativas pesadas (como as multas da LGPD) permanece alto.

A Solução: Governança Nativa por Meio de Middleware

A tese central da pesquisa desenvolvida na UFRN, que agora se tornou propriedade intelectual protegida, parte do princípio do Privacy by Design. Em vez de forçar cada microsserviço ou equipe de desenvolvimento a criar sua própria lógica de exclusão e conformidade, centralizamos essa inteligência em uma camada agnóstica: um middleware de orquestração.

O componente patenteado funciona como um maestro invisível em sistemas distribuídos. Ele intercepta de forma segura as requisições de privacidade, mapeia as dependências de dados e garante que o fluxo de exclusão ocorra de forma resiliente, assíncrona e totalmente auditável — sem comprometer a performance, a escalabilidade ou a disponibilidade do ecossistema de software da empresa.

Para o negócio, isso significa:

1. Mitigação Absoluta de Risco: Processos automatizados e à prova de falhas, gerando relatórios de conformidade prontos para auditorias.
2. Eficiência de Engenharia: Os times de desenvolvimento voltam a focar nas regras de negócio e no produto, pois a governança de dados passa a ser uma engrenagem nativa da infraestrutura.
3. Valor de Mercado: Empresas que protegem a privacidade dos clientes com tecnologia proprietária e escalável aumentam drasticamente seu valuation e sua confiabilidade no mercado B2B e B2C.

O Próximo Capítulo: Ciência de Ponta com Impacto no Mercado

A conquista da patente e a conclusão do mestrado coroam um ciclo de validação rigorosa. Ela prova que a pesquisa científica de ponta realizada no Brasil, quando alinhada às dores reais do mercado corporativo, é capaz de gerar ativos de altíssimo valor.

Garantir a privacidade não precisa ser um freio para a inovação; pode ser o motor que posiciona sua infraestrutura tecnológica anos à frente da concorrência.

Gostaria de expressar meu profundo agradecimento à UFRN por toda a infraestrutura e suporte, e em especial ao meu orientador, Prof. Dr. Eiji Adachi Medeiros Barbosa, cuja orientação brilhante e visão estratégica foram fundamentais para transformar uma inquietação acadêmica em um componente tecnológico patenteado de impacto real. O futuro da engenharia de software é, obrigatoriamente, privado e seguro — e estamos prontos para ele.

O post Do Risco à Inovação: Como Transformamos a Conformidade à LGPD em Propriedade Intelectual Patenteada apareceu primeiro em Ramon Domingos Blog.

Se você me perguntasse há alguns meses como eu estava, a resposta técnica seria, processamento em 100% de CPU, com vazamento de memória constante, pod em CrashLoopBackOff, race conditions , deadlocks  e resource exhaustion; Mas a resposta humana é mais profunda. Olhar para a ata de defesa assinada não foi apenas o recebimento de um título; foi o momento em que o silêncio finalmente venceu o barulho mental de anos de cobrança.

A Síndrome do Impostor: O Bug no Sistema

No mundo técnico, somos treinados para ter respostas. No mestrado, a primeira lição é aceitar que não sabemos quase nada. E é aí que a Síndrome do Impostor se instala.

Em muitas noites, enquanto eu revisava o capítulo de teoria sobre Middleware, processamento distribuído, uma voz no fundo da mente dizia: “Em algum momento, a banca vai perceber que eu não sou tão bom quanto pareço, passar na seleção foi pura sorte”.

A verdade que aprendi é que a síndrome do impostor não é um erro de sistema; ela é uma consequência de estar na fronteira do conhecimento. Se você sente que não sabe tudo, é porque finalmente chegou onde ninguém mais pisou exatamente do seu jeito. O título não cura a síndrome, mas te ensina que você é capaz de entregar resultados mesmo quando não se sente um “expert”.

Atalhos que são, na verdade, Labirintos – DICA PARA QUEM TA COMEÇANDO NA PESQUISA!

Para quem está entrando agora no mestrado ou começando uma pesquisa, o instinto de desenvolvedor, o de otimizar processos, pode ser perigoso. No mestrado, atalhos raramente funcionam.

RETIRE SEU CHAPEUZINHO DE DEV E BOTE O DE PESQUISADOR.

• O atalho da leitura rápida: Tentar escrever sua fundamentação sem ler os artigos clássicos a fundo é como construir um sistema em cima de uma biblioteca que você não entende. Mais cedo ou mais tarde, o código quebra e você terá que refazer tudo do zero.
• Confie no processo: O seu orientador(a) ja fez isso várias vezes, ele/a sabe a ordem dos passos, se perder faz parte do processo, uma hora voce encontra o seu caminho.
• O atalho da “Ferramenta da Moda”: Não escolha um método ou tecnologia só porque ela está no topo do Hype Cycle. Se a ferramenta não resolve o seu problema científico, ela é apenas ruído acumulado no seu cronograma.
• O atalho do isolamento: Achar que pesquisar é um ato solitário é o erro mais comum. O mestrado é um esporte de equipe. O tempo que você economiza não falando com seu orientador ou com seus pares, você perde dando voltas em problemas que uma conversa de 15 minutos resolveria.

Conselhos de quem “sobreviveu” ao Quilômetro Zero

Se você está começando hoje, aqui estão três coisas que eu gostaria de ter ouvido logo no primeiro dia:

1. Documente seus “Erros”: No desenvolvimento, amamos logs. Na pesquisa, o resultado que deu errado também é ciência. Anote por que aquela abordagem não funcionou. Isso vale ouro na hora de escrever a conclusão.
2. Defina seu MVP (Minimum Viable Thesis): O mestrado não é para resolver todos os problemas do mundo, mas para resolver UM problema com profundidade. Foque no coração da sua contribuição e deixe a perfumaria para o doutorado.
3. Saúde Mental é Infraestrutura: Se o seu hardware (você) pifar, o software (a tese) não roda. Reserve janelas de tempo onde a tese não existe. Se puder, faça terapia, isso me ajudou muito. Normalmente, sua vida não irá parar para você fazer seu mestrado, problemas pessoais, familiares, e do trabalho irão continuar acontecendo, e irão concorrer com esse novo projeto.

Conclusão: A Realização é um Processo

A sensação de realização não veio na assinatura da ata, mas na percepção de que hoje sou capaz de encarar um problema complexo e sem resposta sem entrar em pânico. O mestrado me deu o título de Mestre, mas a jornada me deu a resiliência de quem sabe que, para debugar a vida, é preciso paciência e muitas iterações.

Obrigado por me acompanharem nesta jornada técnica (e agora pessoal). Se você está no meio desse furacão chamado mestrado, saiba que o “deployment” final vale cada linha de esforço.

E eu acho que já estou com saudades da UFRN….

O post Além do Código e dos Dados: O que o Mestrado me ensinou sobre a Vida (e sobre mim) apareceu primeiro em Ramon Domingos Blog.

A Base: O Que Acontece Quando Você Salva Dados?

Imagine que você está usando um aplicativo bancário para transferir dinheiro. Quando você clica em “confirmar”, o sistema precisa registrar essa transação. Na maioria das vezes, essa informação é escrita em um banco de dados primário. Tudo simples até aqui, certo?

Entendendo o Dual Write

O Dual Write (escrita dupla, em tradução livre) é exatamente o que o nome sugere: o processo de escrever os mesmos dados em dois sistemas de armazenamento de dados diferentes, de forma simultânea ou quase simultânea.

Pense no nosso exemplo do aplicativo bancário. Se, além do banco de dados principal do banco, a informação da sua transação também fosse registrada ao mesmo tempo em um sistema de relatórios ou em um data warehouse para análise de dados. Isso seria um cenário de Dual Write.

Por Que Usamos Dual Write?

Existem várias razões pelas quais um engenheiro de software escolheria implementar o Dual Write. As mais comuns incluem:

• Sincronização de Dados em Tempo Real: Em muitos cenários, precisamos que as informações estejam atualizadas em múltiplos sistemas imediatamente. Por exemplo, se uma venda é feita no sistema de e-commerce, o estoque no sistema de gerenciamento de armazém precisa ser atualizado instantaneamente. O Dual Write garante que ambos os sistemas recebam a informação ao mesmo tempo.
• Redundância e Recuperação de Desastres: Ao escrever dados em dois lugares, você cria uma cópia de segurança. Se um sistema falhar, o outro ainda tem os dados, o que ajuda na recuperação e garante a continuidade do negócio.
• Integração de Sistemas Distintos: Às vezes, diferentes departamentos usam sistemas diferentes que precisam da mesma informação. Em vez de construir integrações complexas que puxam e empurram dados de um lado para o outro, o Dual Write pode ser uma solução mais direta para manter ambos atualizados.
• Desempenho Otimizado: Em alguns casos, um sistema pode ser otimizado para transações rápidas (por exemplo, um banco de dados de pedidos), enquanto outro é otimizado para análises complexas (um data warehouse). O Dual Write permite que cada sistema use os dados da forma mais eficiente para sua finalidade.

Os Desafios do Dual Write

Apesar de seus benefícios, o Dual Write não é uma bala de prata e apresenta seus próprios desafios:

• Consistência dos Dados: O maior desafio é garantir que os dados sejam exatamente os mesmos em ambos os sistemas. O que acontece se uma escrita em um sistema falha e no outro não? É preciso ter mecanismos robustos para lidar com essas falhas e garantir a consistência.
• Complexidade na Implementação: Gerenciar duas escritas simultâneas, lidar com erros, retentativas e garantir a ordem correta das operações pode tornar a arquitetura do sistema mais complexa.
• Desempenho: Embora possa otimizar o desempenho para propósitos específicos, o Dual Write adiciona uma sobrecarga, pois cada operação de escrita precisa ser realizada duas vezes. Isso pode impactar a latência, especialmente se os sistemas estiverem geograficamente distantes.
• Tratamento de Conflitos: Se ambos os sistemas permitirem escritas independentes, pode haver conflitos que precisam ser resolvidos de forma inteligente para evitar dados inconsistentes.

Alternativas ao Dual Write

É importante mencionar que o Dual Write não é a única forma de sincronizar dados. Existem outras abordagens, como:

• Event-Driven Architecture (Arquitetura Orientada a Eventos): Onde um sistema publica um “evento” (ex: “pedido criado”) e outros sistemas interessados escutam e reagem a esse evento, atualizando seus próprios dados. Isso é geralmente mais robusto e escalável para cenários complexos.
• ETL (Extract, Transform, Load): Processos que extraem dados de uma fonte, os transformam e os carregam em um destino. Isso geralmente acontece em lotes e é mais comum para data warehouses ou sistemas de relatórios onde a latência de tempo real não é crítica.

O Dual Write é uma técnica valiosa no arsenal de um engenheiro de software para manter sistemas em sincronia. Embora ofereça benefícios significativos em termos de sincronização em tempo real e redundância, é crucial entender seus desafios e considerar se é a melhor abordagem para um determinado problema. A escolha da estratégia de sincronização de dados depende das necessidades específicas do negócio, da tolerância a falhas e dos requisitos de desempenho.

Espero que esta explicação tenha desmistificado o Dual Write para vocês! Se tiverem alguma dúvida ou quiserem compartilhar suas experiências, deixem um comentário.

O post O Que é Dual Write? Escrevendo Dados em Dois Lugares ao Mesmo Tempo apareceu primeiro em Ramon Domingos Blog.

Meu Tema: Adaptando-se à LGPD com Middleware em Sistemas Distribuídos

Minha pesquisa, intitulada “Adaptação à LGPD: Proposta de Middleware para a Implementação do Direito ao Esquecimento em Sistemas Distribuídos“, mergulha em um desafio crescente para muitas empresas: como garantir o direito ao esquecimento de dados, exigido pela LGPD, em sistemas modernos baseados em microsserviços?

Para quem não está familiarizado, sistemas de microsserviços são complexos, com dados espalhados e gerenciados de forma independente. Isso torna a exclusão consistente e confiável de dados uma tarefa manual e suscetível a erros, com grandes ramificações legais se não for bem executada.

É aí que entra a minha proposta! Desenvolvi uma solução de middleware automatizada, utilizando o padrão two-phase commit (2PC), para orquestrar a exclusão de dados de forma consistente e segura nesses ambientes distribuídos. Além disso, criei uma biblioteca que pode ser facilmente importada em códigos existentes, simplificando a vida dos desenvolvedores e facilitando a adesão às regulamentações. Em minhas 118 páginas de trabalho, detalho a arquitetura e avalio o desempenho dessa abordagem, demonstrando sua eficácia para um problema que hoje é repleto de complexidade manual.

Em resumo, o objetivo é oferecer uma solução robusta e escalável que capacite as organizações a gerenciar efetivamente a exclusão de dados em ambientes de microsserviços, promovendo maior confiança e adesão às regulamentações de proteção de dados.

Quem é próximo a mim, sabe que eu, mesmo fazendo um trabalho bom, fico diversas vezes inseguro; Em relação a essa apresentação não poderia ser diferente; Quando eu vi meu nome no site da UFRN, com a data da defesa (link), começou o nervosismo, o medo de não responder adequadamente alguma pergunta, mesmo estando imerso no tema por 2 anos.

Minha dica pra quem chegou nesse momento:

Os professores estão ali para contribuir como seu trabalho, para ele ficar mais maduro;

Seu orientador JAMAIS iria deixar você levar algo que não esteja suficiente para aquele momento;

Este é um passo gigante e sou imensamente grato a todos que me apoiaram nessa jornada. A energia agora se renova para os próximos desafios até a defesa final!

O post Qualificado! Minha Jornada e os Desafios da LGPD em Microsserviços apareceu primeiro em Ramon Domingos Blog.

Se você notou um silêncio maior do que o normal por aqui, tem uma boa razão para isso: estou imerso na escrita da minha tese de mestrado! Como muitos de vocês que trabalham com TI e buscam aprofundar seus conhecimentos, sei que a jornada acadêmica exige uma dedicação enorme.

Conciliar as horas de pesquisa, escrita e revisão com a rotina de um blog de TI e o meu trabalho, é, sem dúvida, um desafio. Confesso que tem sido uma verdadeira maratona, mas estou aprendendo muito no processo – tanto sobre o tema da minha tese quanto sobre gerenciamento de tempo e prioridades!

Ainda não quero detalhar muito sobre o assunto da tese, mas em breve, espero trazer alguns insights e, quem sabe, até um post mais aprofundado sobre a minha pesquisa. Por enquanto, a prioridade máxima é entregar um trabalho de qualidade.

Agradeço a compreensão de todos vocês e prometo que, assim que tiver um fôlego, voltarei com conteúdo novo e interessante. Enquanto isso, continuem explorando os posts antigos e deixando seus comentários!

Em breve, mais novidades!

Um abraço,

O post Conciliando a Tese e o Blog: Um Desafio da Vida de TI! apareceu primeiro em Ramon Domingos Blog.

É aí que entram os Trace IDs (IDs de rastreamento)!

Um Trace ID é um identificador único gerado para cada requisição que entra na sua aplicação. Esse ID é propagado por todos os serviços e componentes envolvidos no processamento daquela requisição, permitindo que você correlacione logs e métricas de diferentes partes do sistema.

Por que usar Trace IDs no seu FastAPI?

• Debugging Facilitado: Rastreie o fluxo completo de uma requisição, desde o ponto de entrada até a resposta final, identificando exatamente onde ocorreu um erro ou lentidão.
• Análise de Performance: Visualize o tempo gasto em cada etapa do processamento, identificando gargalos e áreas para otimização.
• Observabilidade Aprimorada: Integre com ferramentas de logging e monitoramento (como ELK Stack, Grafana Loki, Datadog) para ter uma visão centralizada do comportamento da sua aplicação.
• Microserviços: Essencial em arquiteturas de microsserviços para entender a interação entre diferentes serviços em uma única requisição.

Como implementar Trace IDs no FastAPI?

Existem algumas maneiras de implementar Trace IDs no seu FastAPI:

1. Middleware Personalizado:

Você pode criar um middleware personalizado para gerar um Trace ID para cada requisição e adicioná-lo aos headers da requisição e/ou ao contexto da aplicação.

from fastapi import FastAPI, Request, Response
from uuid import uuid4
import logging

app = FastAPI()
logger = logging.getLogger(__name__)

TRACE_ID_HEADER = "X-Request-ID"

@app.middleware("http")
async def add_trace_id(request: Request, call_next):
    trace_id = request.headers.get(TRACE_ID_HEADER) or str(uuid4())
    request.state.trace_id = trace_id
    response: Response = await call_next(request)
    response.headers[TRACE_ID_HEADER] = trace_id
    logger.info(f"Request: {request.method} {request.url} - Trace ID: {trace_id}")
    return response

@app.get("/")
async def read_root(request: Request):
    trace_id = request.state.trace_id
    logger.info(f"Processing root endpoint - Trace ID: {trace_id}")
    return {"Hello": "World", "trace_id": trace_id}

Explicação:

• O middleware add_trace_id é executado para cada requisição HTTP.
• Ele tenta obter um Trace ID do header X-Request-ID (uma prática comum). Se não existir, gera um novo UUID.
• O Trace ID é armazenado no request.state para ser acessado em outras partes da sua aplicação.
• O Trace ID também é adicionado como um header na resposta.
• Você pode incluir o Trace ID nos seus logs para facilitar o rastreamento.

2. Utilizando Bibliotecas de Observabilidade:

Bibliotecas como Opentracing ou Opentelemetry oferecem soluções mais completas para tracing distribuído, incluindo a geração e propagação de Trace IDs, além de integração com diversas ferramentas de observabilidade.

Exemplo com Opentelemetry (simplificado):

from fastapi import FastAPI, Request
from opentelemetry import trace
from opentelemetry.trace.propagation.tracecontext import TraceContextTextMapPropagator

app = FastAPI()
propagator = TraceContextTextMapPropagator()
tracer = trace.get_tracer(__name__)

@app.middleware("http")
async def trace_request(request: Request, call_next):
    carrier = {}
    for k, v in request.headers.items():
        carrier[k] = v
    context = propagator.extract(carrier)
    with tracer.start_as_current_span(f"{request.method} {request.url.path}", context=context) as span:
        span.set_attribute("http.method", request.method)
        span.set_attribute("http.url", str(request.url))
        response = await call_next(request)
        span.set_attribute("http.status_code", response.status_code)
        return response

@app.get("/")
async def read_root():
    current_span = trace.get_current_span()
    current_span.set_attribute("greeting", "Hello World")
    return {"Hello": "World"}

Considerações Importantes:

• Propagação: Em arquiteturas com múltiplos serviços, é crucial garantir que o Trace ID seja propagado corretamente entre as chamadas HTTP. Isso geralmente envolve passar o Trace ID em headers HTTP.
• Logging: Configure sua solução de logging para incluir o Trace ID em cada log, permitindo a correlação de eventos relacionados à mesma requisição.
• Ferramentas de Observabilidade: Integre sua aplicação com ferramentas de observabilidade para visualizar os traces, analisar a performance e identificar problemas de forma mais intuitiva.

Implementar Trace IDs no seu FastAPI é um investimento valioso que melhora significativamente a capacidade de entender, depurar e otimizar sua aplicação, especialmente em cenários mais complexos. Comece com um middleware simples e explore bibliotecas de observabilidade para uma solução mais robusta!

O post Rastreando Requisições no FastAPI com Trace IDs: Desvendando o Fluxo da sua Aplicação! 🕵️‍♂️ apareceu primeiro em Ramon Domingos Blog.

Recentemente consegui minha certificação Individual do Google Analytics , e no início da jornada de estudo me perguntei, isso é para o pessoal de Marketing ou para desenvolvedor? Mas ao final, entendi que todo mundo precisa entender um pouco de analytics. Fazer sua aplicação gerar dados é fundamental, para identificar insights de todos os aspectos da aplicação. No fundo, ser guiados por dados é mais importante do que seguir seu sentimento. E ter um google analytcs bem configurado, promoverá esses dados para toda equipe.

Já pararam para pensar na importância de entender como seus projetos são utilizados? Enquanto o pessoal de marketing se concentra em analisar os dados para criar estratégias, os desenvolvedores têm um papel fundamental em garantir que os dados coletados sejam precisos e completos. Neste post, vamos explorar por que o Google Analytics é uma ferramenta importante para desenvolvedores coletar esses dados, nesse post especialmente iremos aplicar o GA numa aplicação Next.js, mas facilmente é adaptável para outras aplicações, Te guiarei passo a passo na instalação e configuração do funil de vendas. Identificando desde o início da sessão, a primeira visita ao site, até efetuar a compra no checkout. Podendo assim, identificar a porcentagem de abandono de carrinhos, por exemplo.

Por que os Desenvolvedores Devem Entender o Google Analytics?

• Otimização de Desempenho: Ao acompanhar métricas como tempo de carregamento de página, taxa de rejeição e erros, os desenvolvedores podem identificar gargalos e implementar melhorias para otimizar a experiência do usuário.
• Qualidade do Código: Analisando eventos e interações do usuário, é possível identificar bugs e problemas de usabilidade que podem passar despercebidos em testes.
• Validação de Hipóteses: Ao desenvolver novas funcionalidades, o Google Analytics permite validar se as mudanças estão tendo o impacto esperado nos usuários.
• Integração com Outras Ferramentas: O Google Analytics pode ser integrado com outras ferramentas de desenvolvimento, como ferramentas de monitoramento de desempenho e sistemas de versionamento, proporcionando uma visão mais completa do ciclo de vida do software.

Instalando o Google Analytics com Funil de Vendas em um Aplicação Next.js

• Criar uma Conta no Google Analytics: Se você ainda não tem uma conta, acesse o Google Analytics e crie uma nova propriedade para o seu site. (Provavelmente o marketing da empresa ja possuirá )
• Obter o Código de Rastreamento: Após criar a propriedade, você receberá um código de rastreamento único.
• Instalar o Pacote do Google Analytics: No seu projeto Next.js, instale o pacote oficial do Google Analytics.

 npm install @google/analytics

• Configurar o Rastreamento: Crie um componente customizado para envolver o seu aplicativo e enviar os dados para o Google Analytics.

const GoogleAnalytics = () => {
return (<>
/* 1. Initialize the Google tag and gtag.js library */
   <!-- Google tag (gtag.js) -->
   <script async src="https://www.googletagmanager.com/gtag/js?id=TAG_ID"></script>
   <script>
     window.dataLayer = window.dataLayer || [];
     function gtag(){dataLayer.push(arguments)};
     gtag('js', new Date());
     gtag('config', 'TAG_ID');
   </script>
   </>
   )
   
export { GoogleAnalytics };

• Use esse componente no layout principal da sua aplicação.

import { GoogleAnalytics } from "seu_componente_google-analytics";
export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html>
      <body>
        {children}
        <GoogleAnalytics />
      </body>
    </html>
  );
}

Eventos principais

Para criar um funil de vendas, você precisa mapear alguns eventos:

1. Início da sessão (o número de usuários que acionaram o evento  session_start)
2. Ver produto (o número de usuários que acionaram o evento  view_item)
3. Adicionar ao carrinho (o número de usuários que acionaram o evento add_to_cart)
4. Iniciar checkout (o número de usuários que acionaram o evento begin_checkout)
5. Compra (o número de usuários que acionaram o evento purchase ou in_app_purchase)

Nos links de cada evento tem o formato de dados que devem ser enviados junto do evento, alguns não precisa enviar nada além do titulo do evento. É muito importante enviar exatamente os campos necessários, dados faltando, ou em excesso irá fazer com que o evento seja descartado.

Para fazer o envio, basicamente será necessário usa a função, gtag. Aconselho criar uma função mais generalista e reutilizar em todos os lugares, pois será importante caso precise debugar, adicionar o debug_mode:true, em cada envio.)

 window.gtag("event", event,eventParams ) 

Exemplo para adicionar um ou mais item ao carrinho:

gtag("event", "add_to_cart", {
  currency: "BRL",
  value: 9.99,
  items: [
    {
      item_id: "SKU_12345",
      item_name: "Stan and Friends Tee",
      index: 0,
      price: 9.99,
      quantity: 1
    }
  ]
});

Exemplo de purchase:

gtag("event", "purchase", {
    transaction_id: "T_12345",
    value: 25.42,
    tax: 4.90,
    shipping: 5.99,
    currency: "USD",
    coupon: "SUMMER_SALE",
    items: [
     {
      item_id: "SKU_12345",
      item_name: "Stan and Friends Tee",
      affiliation: "Google Merchandise Store",
      coupon: "SUMMER_FUN",
      discount: 2.22,
      index: 0,
      item_brand: "Google",
      item_category: "Apparel",
      item_category2: "Adult",
      item_category3: "Shirts",
      item_category4: "Crew",
      item_category5: "Short sleeve",
      item_list_id: "related_products",
      item_list_name: "Related Products",
      item_variant: "green",
      location_id: "ChIJIQBpAG2ahYAR_6128GcTUEo",
      price: 9.99,
      quantity: 1
    },
    {
      item_id: "SKU_12346",
      item_name: "Google Grey Women's Tee",
      affiliation: "Google Merchandise Store",
      coupon: "SUMMER_FUN",
      discount: 3.33,
      index: 1,
      item_brand: "Google",
      item_category: "Apparel",
      item_category2: "Adult",
      item_category3: "Shirts",
      item_category4: "Crew",
      item_category5: "Short sleeve",
      item_list_id: "related_products",
      item_list_name: "Related Products",
      item_variant: "gray",
      location_id: "ChIJIQBpAG2ahYAR_6128GcTUEo",
      price: 20.99,
      promotion_id: "P_12345",
      promotion_name: "Summer Sale",
      quantity: 1
    }]
});

Visualizando o funil de vendas. Em Relatório > Monetization/sales/vendas > Purchase Journey. Ficará algo parecido com isso:

Debug view

Os dados do GA podem demorar ate 24h para surgirem nos relatório. Para você acompanhar em tempo real os eventos chegando, voce pode adicionar o modo debug,

 window.gtag("event", event,{ ...eventParams, debug_mode: true});

(lembra que falei de criar uma função e reutilizar?)

Em admin > Data Display > Debug view. Você irá acompanhar em tempo real todos os eventos.

Eventos que possuem parâmetros, como items ficará assim:

Você pode estranhar o preço. Mas nesse link do StackOverflow, encontrei esse reposta:

Isso não é um problema em relatórios reais e só aparece no DebugView.

Internamente, o valor é multiplicado por 1000000 para que possa ser armazenado como um inteiro para economizar espaço. A ferramenta de depuração falha em convertê-lo de volta, mas relatórios reais parecem acertar.

Dominar o Google Analytics é uma habilidade fundamental para qualquer desenvolvedor que busca criar produtos digitais de sucesso. Ao entender como os usuários interagem com seus aplicativos, você pode tomar decisões mais informadas e entregar experiências cada vez melhores.

Dicas Extras:

• Personalização: Explore as opções de personalização do Google Analytics para criar relatórios personalizados e segmentar seus dados.
• Integrações: Descubra as diversas integrações do Google Analytics com outras ferramentas para obter uma visão mais completa dos seus dados.
• Aprendizado Contínuo: O Google Analytics está em constante evolução. Mantenha-se atualizado sobre as novas funcionalidades e recursos.

E aí, gostou deste guia? Compartilhe suas experiências nos comentários e me diga quais outras ferramentas você utiliza para analisar seus projetos.

O post Desenvolvedores precisam Dominar o Google Analytics? Um Guia Prático com Next.js apareceu primeiro em Ramon Domingos Blog.

Este projeto foi a avaliação da disciplina Computação em Nuvem, PPGTI2001, do mestrado da UFRN. É necessário criar um pod com vários contêineres, deve ser gerado e atender aos seguintes requisitos:

– O pod deve ter 4 containers e deve ser criado usando um Manifesto do Kubernetes (arquivo yaml);

Alunos:

-Ramon Domingos Duarte Oliveira

– Gerfesson Santos da Nóbrega

Já que você ja aprendeu a configurar o k8s em sua máquina, conforme o post anterior, agra vamos subir as aplicações.

front,back, cache e mongodb.

Sobre aplicativos

API

API de registro de produto

{

"nome": "PEN_BLACK",

"description": "caneta preta, com corpo transparente",

"qtdDisponível": 12

}

• /produto `(get, post)`
• /produto/:id `(put, delete, get)`

FRONT

Aplicativo que consome a API, exibindo listagens e formulários.

Usando https://refine.dev/ como modelo base.

Docker-compose

version: '3.7'
services:
  redis-service:
    container_name: redis-database
    image: 'bitnami/redis:latest'
    ports:
      - "6379:6379"
    environment:
      - ALLOW_EMPTY_PASSWORD=yes
  front:
    build:
      context: ./front
      dockerfile: Dockerfile
    container_name: front
    expose:
      - '3000'
    ports:
      - '3000:3000'
    environment:
      API_URL: api
      NEXT_PUBLIC_API_URL: api
      NEXT_PUBLIC_API_URL_PORT: 8002
  api:
    build:
      context: ./api
      dockerfile: Dockerfile
    container_name: api
    expose:
      - '8002'
    ports:
      - '8002:8001'
    environment:
      - PORT=8001
      - REDIS_URL=redis-service
      - REDIS_PORT=6379
      - REDIS_EXPIRE=10
      - MONGO_USERNAME=root
      - MONGO_PASSWORD=example
      - MONGO_URL=mongo:27017
      - MONGO_DB=product
  mongo:
    image: mongo
    restart: always
    environment:
      MONGO_INITDB_ROOT_USERNAME: root
      MONGO_INITDB_ROOT_PASSWORD: example
    ports:
      - '27017:27017'

Para executar usando apenas docker-compose use:

docker-compose up

Serviços:

• mongo: MongoDB para registro de produtos
• redis: cache para solicitações frequentes
• api: API REST para conectar-se ao banco de dados.
• front: Frente usando React.

Kubernets

Etapa 1: Envie estas imagens para DockerHub pessoal (opcional)

Para construir a imagem da API

cd api
docker build -t <your_username>/api-products .
docker push  <your_username>/api-products

Para construir a imagem do front

cd frontend
docker build -t <your_username>/front-products .
docker push  <your_username>/front-products

Se você criar imagens personalizadas, vá para os arquivos `k8s/*-deployment` e altere a imagem para a sua.

As imagens MONGO e REDIS são imagens oficiais, já estão disponíveis no dockerhub para uso.

Espera-se que o ambiente da máquina já esteja pré-configurado e domine um trabalhador unido, usando o comando `kubeadm join –token`

Etapa 2: Criar namespace

kubectl get ns

kubectl create namespace products-application

kubectl get ns

kubectl config get-contexts

kubectl config set-context --current --namespace=products-application

[output]

kubectl config set-context –current –namespace=products-application

kubectl config get-contexts

[output]

Etapa 3: crie uma implantação

Nos arquivos de implantação, há detalhes sobre o **image docker** e um **imagePullPolicy**. Neste exemplo é Sempre,

para Sempre implantar, obtenha uma nova imagem para o dockerhub.

O comando de linha é

kubectl create deployment redis --image=redis --port=5701

mas, no diretório k8s tem 4 arquivos yaml para [api,front,mongo,redis]-deployment.yaml

exempo do api-deployment

apiVersion: apps/v1
kind: Deployment
metadata:
metadata:
  annotations:
   
   
metadata:   
  annotations:
   
   
  labels:
    app: api
  name: api
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      annotations:
      annotations:
       
       
      annotations: 
       
       
      labels:
        app: api
    spec:
      containers:
        - env:
            - name: MONGO_DB
              value: product
            - name: MONGO_PASSWORD
              value: example
            - name: MONGO_URL
              value: $(MONGO_SERVICE_HOST):27017
            - name: MONGO_USERNAME
              value: root
            - name: PORT
              value: "8001"
            - name: REDIS_EXPIRE
              value: "10"
            - name: REDIS_PORT
              value: "6379"
            - name: REDIS_URL
              value: $(REDIS_SERVICE_SERVICE_HOST)
          image:  ramondomiingos/api-products
          imagePullPolicy: Always
          name: api
          ports:
            - containerPort: 8001
              hostPort: 8001
              protocol: TCP
      restartPolicy: Always

Os outros estão na mesma pasta [mongo, redis e front]

### Etapa 4: crie um serviço

para expor a aplicação para fora do k8s, é necessário criar um serviço

Você pode criar com um comando:

kubectl create service nodeport web-products --tcp=3000:3000 --node-port=30300

confira a criação

kubectl get service

No diretório k8s tem 4 arquivos yaml para [api,front,mongo,redis]-service.yaml

Etapa 5: Envie arquivos para o nó MASTER.

na pasta `k8s`tem 9 arquivos implantação e serviço para [api, front, mongo e Redis]

e 1 arquivo para **ingress**;

envie este arquivo para o seu mestre (pode usar scp)

scp k8s/* remote_username@10.10.0.2:/remote/directory

### Etapa 6: Aplicar arquivo de especificação

Em sequência é necessário aplicar este arquivo e verificar os pods.

kubectl apply -f .

“`

**[output]**

For apply all files use `kubectl apply -f .`

**[output]**

~kubectl apply -f .

deployment.apps/api created

service/api created

deployment.apps/front created

service/front created

deployment.apps/mongo created

service/mongo created

deployment.apps/redis-service created

service/redis-service created

kubectl get pods

output

enquanto os contêineres são criados, verifique os logs com:

kubectl logs web-products

Se demorar muito para criar os containers com sucesso, verifique os logs individualmente para ver se ocorreu algum erro, se necessário corrija e aplique este arquivo novamente.

kubectl logs web-products -c [redis-service, mongo, frontend, api]

> erro example:

depois de alguns segundos, você pode executar este mesmo comando e verá:

Etapa 7: Verifique sua aplicação.

Vá para o navegador, visite `http://<ip-worker>:3000` e veja o aplicativo.

3000 é a porta exposta em arquivos yaml.

Não contemplei volumes persistentes.

Aprendizagem pessoal

– No nosso cenário precisamos expor a api, já que as requisições feitas pelo front eram do lado do cliente, usar um IP interno não funcionaria.

– Todos os pods possuem muitas variáveis de ambiente no formato `<NAME>_SERVICE_HOST` para identificar outros serviços e podem ser usados em yaml como ambientes de configuração. [Exemplo](k8s/api-deployment.yaml) linha 39.

– Para ver todos os ambientes você pode usar `kubectl exec <pod-name> printenv`.

– Outro formato para URL é `<service-name>.<namespace|default>.svc.cluster.local:<service-port>`;

O post Fazendo deploy de MONGO, REDIS API E FRONT no Kubernets apareceu primeiro em Ramon Domingos Blog.

Pré-Requisitos

Antes de começarmos, certifique-se de que você tem:

• Duas máquinas virtuais rodando um sistema operacional Linux (pode ser Ubuntu, CentOS, ou outro de sua preferência).
• Conhecimento básico de administração de sistemas Linux.
• Acesso root ou permissões de sudo em ambas as máquinas.
• Conexão de rede entre as duas máquinas.

Passo 1: Configuração da Máquina Mestre (Master)

Na máquina que você deseja configurar como mestre, siga estes passos:

1. Atualize o sistema operacional:

sudo apt update && sudo apt upgrade -y

2. Instale o Docker, que é um pré-requisito para o Kubernetes:

sudo apt install docker.io -y

3. Configure o repositório do Kubernetes:

codesudo apt-get update && sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update

4. Instale o Kubernetes:

sudo apt-get install -y kubelet kubeadm kubectl

5. Inicie o cluster Kubernetes no nó mestre (master):

sudo kubeadm init

6. Após a inicialização, siga as instruções fornecidas pelo kubeadm para configurar o seu ambiente local do Kubernetes. Isso inclui a configuração do diretório do kubeconfig e a instalação de uma rede de pod. Por exemplo:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

7. Verifique o status do nó mestre (master):

kubectl get nodes

Passo 2: Configuração da Máquina de Trabalho (Worker)

Agora, vamos configurar a máquina que atuará como o nó de trabalho (worker). Repita os passos 1 a 4 da configuração da máquina mestre, e depois siga estas etapas adicionais:

1. Junte o nó de trabalho ao cluster Kubernetes. Use o comando kubeadm join fornecido pelo comando kubeadm init que você executou na máquina mestre. Ele deve se parecer com algo assim:

sudo kubeadm join <endereço_do_master>:<porta> --token <token> --discovery-token-ca-cert-hash sha256:<hash>

Substitua <endereço_do_master>:<porta>, <token> e <hash> pelos valores fornecidos pelo comando kubeadm init na máquina main.

2. Depois que o nó de trabalho se juntar com sucesso ao cluster, volte para a máquina mestre e verifique o status dos nós:

kubectl get nodes

Você deve ver ambos os nós listados como “Ready”.

Conclusão

Parabéns! Você configurou com sucesso um cluster Kubernetes com um nó mestre e um nó de trabalho. Agora você pode começar a implantar e gerenciar seus aplicativos em contêineres de forma escalável e eficiente.

Este guia forneceu apenas uma introdução básica ao Kubernetes. Existem muitos outros recursos e conceitos avançados para explorar, como implantações, serviços, e balanceamento de carga. Continue aprendendo e experimentando para dominar totalmente o poder do Kubernetes!

Espero que este guia seja útil em sua jornada com Kubernetes. Se precisar de mais ajuda ou tiver alguma dúvida, sinta-se à vontade para entrar em contato.

O post Guia Passo a Passo: Configurando um Cluster Kubernetes com um Main e um Worker apareceu primeiro em Ramon Domingos Blog.