Luciano Costa

Projeto super legal o Git City, ele utiliza informações públicas do GitHub para trazer os dados abaixo e montar um modelo em 3D: https://lnkd.in/dx9FCjiA Aproveitando, seguem alguns projetos que compartilhei na plataforma nos últimos anos e acho legal compartilhar aqui o/ 𝟭. 𝗧𝘄𝗶𝘁𝘁𝗲𝗿 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀: Uma implementação da arquitetura do Twitter usando microserviços com Spring Boot, Spring Cloud, Redis e Kafka. Focado em ver na prática como criar sistemas distribuídos. https://lnkd.in/drYRqDjR 𝟮. 𝗦𝗢𝗟𝗜𝗗 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀: Repositório com os exemplos que utilizei na palestra no TDC. Focado em como escrever código limpo, sustentável e fácil de manter em Java e Pokemon! https://lnkd.in/e8Btpmrj 𝟯. 𝗠𝗲𝗱𝗶𝘂𝗺 𝗞𝗶𝗻𝗱𝗹𝗲 𝗦𝗲𝗻𝗱𝗲𝗿: Uma ferramenta que automatiza a conversão de artigos do Medium para ePub e envia direto para o Kindle. Unindo Node.js, Express e automação de e-mail. https://lnkd.in/dddyHbwY 𝟰. 𝗣𝘆𝗺𝗮𝗻𝗴𝗮𝗝: Uma biblioteca Python disponível no PyPI para buscar e baixar capítulos de mangá de diversas fontes na internet. https://lnkd.in/d8X9GjnX 𝟱. 𝗔𝗹𝗲𝘅𝗮 𝗡𝗲𝘄𝘀𝗹𝗲𝘁𝘁𝗲𝗿 𝗗𝗲𝘀𝗰𝗵𝗮𝗺𝗽𝘀: Meu projeto com mais estrelas! Uma integração que permite ouvir a newsletter do Filipe Deschamps diretamente pela Alexa, usando AWS S3 e Google Sheets como backend. https://lnkd.in/dZizpcvg Caso queira deixar uma estrela ⭐ ou contribuir com esses projetos só acessar os links o/

19

2 comentários

Quarta-feira de cinzas, dia de voltar ao trabalho pós carnaval 🪅 Aproveitei esses dias em casa para escrever sobre um tema super importante pra nós SREs, e que ainda vejo pouco conteúdo por aqui. Com o EOL do Nginx Ingress Controller, e com as inúmeras CVE's abertas nos últimos tempos, muitas equipes de SREs/Plataforma estão de frente com uma decisão importante, como manter nosso tráfego de entrada em nosso cluster Kubernetes "up-to-date" com o mercado, utilizando as melhores tecnologias? Pensando nisso, iniciamos aqui na Dito CRM um processo de migração do nosso cluster (GKE) de produção, já utilizando o Gateway API como "Ingress" para nossas aplicações, e posso afirmar, foi a melhor decisão que tomamos. Nesse artigo conto um pouco dos motivadores e os ganhos que tivemos com essa decisão, além de exemplos que podem ser utilizados por times de SRE em suas validações/discovery. https://lnkd.in/dPhte8HG

39

1 comentário

D075/365 - OmniScript: como o Data JSON cresce sem você perceber No Step 1, seu Data JSON é enxuto, lindo e fácil de ler. Quando chega no Step 4, ele virou um monstro de linhas intermináveis que faz a aba de rede do navegador pedir socorro. O JSON de um OmniScript é um mapa vivo. E ele cresce silenciosamente. >>> O multiplicador invisível Todo Input, Action, Set Values ou Step que você coloca na tela escreve um nó novo na estrutura. Mas o grande vilão do peso costuma ser o Repeat Block, ou aqueles dados que você recebeu de alguma Action e que nunca vai usar. No caso de repeat block, é um bloco inofensivo com cinco campos de endereço parece leve. Se o usuário adicionar dez endereços, você acabou de injetar cinquenta novas entradas na raiz do seu payload. Sem contar os nós adicionais criados pela própria estrutura de controle do bloco. >>> O custo deste crescimento de dados O Data JSON não é só memória RAM do navegador. Ele transita pela rede. Quando você chama uma Integration Procedure, se você não usar as propriedades de Send JSON Path para fatiar o payload, o OmniScript envia esse monstro inteiro pro backend do Salesforce mastigar. Aí o fluxo fica lento, a requisição bate no limite de CPU e você não sabe o porquê. Desenvolver OmniScript não é só empilhar blocos na tela. É gerenciar o peso do estado do início ao fim. Link de todos os posts: https://lnkd.in/d3tTaAAj #OmniStudio #SalesforceIndustries #SalesforceDeveloper #Vlocity

16

🚀 Agent Teams: Quando Subagents Não São Suficientes — A Colaboração Multi-Agente Nativa do Claude Code 🤝 Se você acompanhou minha série sobre Skills, Subagents, Context Window e CLAUDE.md, já sabe escalar a capacidade individual do Claude Code. Mas e quando o problema exige que os agentes conversem entre si? Subagents resolvem paralelismo. Cada worker executa sua tarefa e reporta ao orquestrador. Mas têm um gargalo fundamental: não se comunicam entre si. Se o agente de API descobre que um contrato mudou, o agente de testes não fica sabendo até o resultado voltar ao orquestrador. Agent Teams remove esse gargalo. Lançado como feature experimental com o Opus 4.6, Agent Teams é um sistema nativo do Claude Code onde múltiplas instâncias colaboram de verdade: 🔹 Lead: Coordena o time, distribui tarefas e sintetiza resultados. Você interage com ele. 🔹 Teammates: Workers independentes com contexto próprio. Executam, descobrem e compartilham. 🔹 Shared Task List: Lista de tarefas compartilhada. Cada teammate pega, atualiza e conclui itens. 🔹 Mensagens diretas: Teammates enviam mensagens uns aos outros sem passar pelo Lead. A diferença fundamental: Subagents são contractors que você manda em missões separadas. Agent Teams são colegas de equipe que colaboram em tempo real. 📐 Quando usar Agent Teams (e quando NÃO usar): ✅ Use para: → Refactor cross-layer (API + banco + testes tocados ao mesmo tempo) → Debugging com hipóteses paralelas que convergem → Code review com contexto fresco (um escreve, outro revisa) → Módulos novos que precisam coordenar contratos de interface ❌ NÃO use para: → Tarefas simples que cabem em uma sessão → Trabalho sequencial sem necessidade de troca → Quando o overhead de tokens não se justifica ⚙️ Como ativar (2 passos): 1. export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 2. Descreva o time em linguagem natural: "Crie um agent team para refatorar o módulo de pagamentos. Spawne três teammates: um para API, um para migrations, um para testes." O Claude cria o Lead, spawna os teammates e coordena pela shared task list. Você navega entre eles com Shift+Down no terminal. Regra prática: se os workers precisam trocar informações, use Agent Teams. Se não, Subagents bastam. Preparei um carrossel visual (PDF abaixo) com o comparativo Subagents vs Agent Teams, a anatomia de um time, casos de uso, como ativar e boas práticas. Que tarefa complexa no seu projeto você dividiria em um time de agentes? 👇 #InteligenciaArtificial #ClaudeCode #AgentTeams #MultiAgent #SoftwareArchitecture #EngenhariaDeSoftware #Anthropic #Produtividade #DicasTech

12

O meu projeto local com Airflow + Docker + PostgreSQL, uma coisa ficou muito clara: 👉 Rodar a DAG é só parte do trabalho. O verdadeiro ganho está em validar rápido o que aconteceu depois da execução. Sim, dá para consultar tudo pelo terminal com WSL + psql. Mas quando comecei a usar o DBeaver no fluxo de validação, a produtividade melhorou bastante. Com ele, ficou muito mais simples: • conferir se a tabela foi criada • validar se os dados foram carregados • inspecionar registros visualmente • testar queries sem perder tempo • identificar erros de carga com mais clareza No fim, o terminal continua essencial para troubleshooting e administração. Mas, para desenvolvimento e análise do pipeline, uma ferramenta visual faz muita diferença. 💡 Lição prática: Em Engenharia de Dados, não basta automatizar. É preciso também ter visibilidade sobre o resultado. E isso vale muito em projetos locais, MVPs e portfólio técnico. #DataEngineering #ApacheAirflow #Docker #PostgreSQL #DBeaver #ETL #ELT #DataPipeline #Python #AnalyticsEngineering

76

6 comentários

🚀 GitLab: por que às vezes o menu Settings aparece… e às vezes não? (e o que isso tem a ver com deploy) Muita gente que está começando com CI/CD no GitLab acha que algo está “quebrado” quando não encontra o menu Settings dentro do projeto. Na verdade, isso é só controle de permissões — e entender isso é um passo importante no seu nível de maturidade em deploy. 🔐 Papéis no GitLab (simplificado): Guest → acesso mínimo Reporter → leitura Developer → consegue fazer commit e rodar pipeline ✅ Maintainer → consegue configurar CI/CD e Settings 🔧 Owner → controle total 👉 Ou seja: você pode estar fazendo deploy normalmente sem ver o menu Settings. 💡 O que muda na prática? Se você é Developer: ✅ Pode rodar pipelines ✅ Pode criar .gitlab-ci.yml ✅ Pode fazer build e deploy (se já existir runner) ❌ Não pode configurar runners ❌ Não pode criar variáveis secretas ❌ Não vê Settings Se você é Maintainer: ✅ Pode configurar runners ✅ Pode adicionar variáveis CI/CD ✅ Pode gerenciar ambientes ✅ Vê Settings 🔥 Nível de maturidade em CI/CD 🟢 Nível 1 — Rodar pipeline existente 🟡 Nível 2 — Criar .gitlab-ci.yml 🟠 Nível 3 — Usar variáveis e múltiplos stages 🔴 Nível 4 — Configurar runner próprio 🟣 Nível 5 — Infra de deploy completa (mobile, cloud, etc.) O menu Settings começar a aparecer é literalmente um sinal de que você subiu de nível na responsabilidade dentro do projeto. 🎯 Conclusão Se o Settings não aparece: 👉 Não é erro 👉 Não é bug 👉 Não significa que você não pode fazer deploy Significa apenas que você ainda não tem permissão administrativa naquele projeto. E isso é completamente normal em ambientes profissionais. #GitLab #CI_CD #DevOps #MobileDev #Flutter #Fastlane #SoftwareEngineering

1

Nem só de Grafana vive o analista, conheça a alternativa XO é a abreviação de xobserve. É uma plataforma de observabilidade programável projetada especificamente para desenvolvedores. Também serve como uma plataforma alternativa de visualização de dados ao Grafana. XO permite que os usuários criem rapidamente cenários de observabilidade online, como monitoramento, registro e rastreamento. Se o XO não atender às suas necessidades específicas, você sempre pode abrir uma reclamação, e pedidos razoáveis serão prontamente atendidos.

83

1 comentário

🚫 Node.js e Python no Kubernetes: um erro comum de escalabilidade Um erro que vejo com muita frequência quando aplicações Node.js ou Python vão para Kubernetes é carregar padrões de deploy que faziam sentido em VMs, mas que não se encaixam bem no modelo de containers. Em ambientes mais tradicionais, é muito comum tentar extrair o máximo de uma única máquina. No Node.js, muita gente usa o módulo cluster para criar múltiplos workers e aproveitar todos os cores disponíveis. No Python, é comum subir a aplicação com Gunicorn usando vários workers. Não existe nada de errado com isso, em um servidor único, esse padrão funciona bem. O problema aparece quando levamos exatamente essa mesma lógica para dentro do Kubernetes. O Kubernetes foi pensado para escalar horizontalmente, não para concentrar vários processos dentro de um único container. A unidade de escala da plataforma é o pod. Quando colocamos vários workers dentro de um mesmo pod, acabamos indo contra essa lógica. Isso traz alguns efeitos colaterais que muitas vezes passam batidos. O primeiro é previsibilidade de recursos. O scheduler do Kubernetes trabalha com requests e limits de CPU e memória por container. Quando você coloca vários workers competindo dentro do mesmo container, fica muito mais difícil entender de fato como aquele pod consome recursos. Outro ponto é o autoscaling. Ferramentas como o Horizontal Pod Autoscaler tomam decisões baseadas em métricas agregadas do pod. Se você tem vários workers dentro dele, um deles pode estar saturado enquanto o consumo geral da CPU ainda parece aceitável. O resultado é que o autoscaling reage mais tarde do que deveria. Também existe uma questão de resiliência. Se um pod concentra vários workers e ele morre, você perde todos de uma vez. Quando cada pod roda um único processo, o impacto de uma falha tende a ser menor e a app se recupera de forma mais suave. Por isso, em muitos cenários de microserviços, uma abordagem mais alinhada com Kubernetes é ter um processo por container e escalar através de mais pods. No caso de Node.js, muitas vezes significa simplesmente rodar a aplicação sem cluster e deixar o HPA controlar o número de réplicas. Para aplicações Python usando Gunicorn, também é comum rodar com apenas um worker por container (ou poucos, dependendo do caso) e permitir que o cluster faça o trabalho de distribuir carga. Claro que existem exceções. Pods grandes, workloads muito CPU-bound ou ambientes sem autoscaling podem justificar múltiplos workers. Mas na maior parte das arquiteturas modernas, escalar pods costuma ser mais previsível, mais resiliente e mais alinhado com a forma como Kubernetes foi projetado para operar. É um detalhe pequeno, mas que faz bastante diferença quando a aplicação começa a crescer. #nodejs #python #developer #kubernetes #sre #dev #k8s #backend #software

34

A qualidade de um sistema RAG costuma ser decidida antes do retrieval -- na etapa de ingestão. A maioria dos tutoriais trabalha com texto limpo. Um .txt, um JSON formatado, talvez um CSV. O chunking funciona, os embeddings ficam razoáveis, o retrieval retorna algo útil. Mas documentos corporativos reais são outra história: PDFs com tabelas e notas de rodapé, apresentações com dados distribuídos entre slides, documentos Word com formatação complexa. Extrair texto de um PDF parece simples. Na prática, tabelas viram texto corrido, headers e footers contaminam o conteúdo, imagens com texto são ignoradas e a estrutura hierárquica se perde. Se a extração não preserva a estrutura do documento original, o chunking opera sobre dados de baixa qualidade. E chunking de tamanho fixo agrava o problema. Cortar a cada 500 tokens mistura assuntos diferentes no mesmo chunk e quebra frases no meio. O resultado são embeddings que representam fragmentos incoerentes -- e o retrieval sofre. O caminho que tende a funcionar melhor combina duas coisas: -- Extração estruturada: ferramentas como Docling processam PDFs, Word, PowerPoint e EPUB preservando metadados (página, seção, tipo de conteúdo) em vez de devolver texto corrido -- Semantic chunking: em vez de dividir por tamanho, agrupar trechos semanticamente relacionados via clustering (HDBSCAN, por exemplo), onde cada cluster vira um chunk coeso Quando a qualidade do chunking melhora, o efeito cascata é visível: embeddings mais coesos, busca mais relevante, respostas de maior qualidade. O pipeline de ingestão tende a ser a parte menos visível de um sistema RAG, mas é onde a maioria dos problemas de qualidade se origina. Na Especialização em Engenharia de IA da Dev + Eficiente, implementamos esse pipeline completo -- de Docling a semantic chunking com HDBSCAN -- no contexto de um projeto de análise financeira real. Daniel Romero conduz a implementação passo a passo. https://lnkd.in/d5dr-xQn P.S. Este post foi gerado pelo Agente Marketing Dev + Eficiente e revisado por mim.

6

1 comentário

🌐 AutoMQ: uma nova forma de pensar Kafka na nuvem Recentemente fui convidado para apoiar o projeto, AutoMQ, que é um projeto Kafka-compatible, mas desenhado desde o início para ser cloud-native. Principais ideias: - Separação real de compute e storage - Uso de object storage - Escala elástica sem o peso do rebalancing tradicional - Redução de complexidade operacional e custos Para quem já operou Kafka em produção, dá pra ver claramente o foco em resolver dores reais de escala, operação e FinOps. Repo: https://lnkd.in/e9Bc8qCf Vale muito entrar no radar de quem trabalha com event streaming e data platforms. #Kafka #CloudNative #EventStreaming #DevOps #DataEngineering #FinOps #OpenSource

11

Se alguém tiver interesse em desenvolver competências de Apache Kafka, aqui vai uma dica, com base na minha experiência. 💬 Implementação de Arquitetura Orientada a Eventos com Apache Kafka para Sincronização de Biometrias Atuei na definição e implementação de uma arquitetura de mensageria para resolver um problema de consistência distribuída: a necessidade de replicar biometrias cadastradas em um equipamento para outros dispositivos nos quais o mesmo usuário possuía autorização de acesso. Após análise de viabilidade técnica, estudo aprofundado e validação arquitetural com base na documentação oficial do Apache Kafka (incluindo conceitos de tópicos, particionamento, retenção e modelo publish/subscribe), defini a adoção de um modelo orientado a eventos para desacoplamento entre origem e destino da informação. A solução implementada contemplou: Captura do evento de cadastro de biometria no equipamento de origem; Publicação da mensagem em tópico específico no broker Kafka; Implementação de consumer dedicado para processamento assíncrono; Validação de regras de permissão por equipamento; Replicação idempotente da biometria nos dispositivos autorizados; Garantia de consistência eventual entre os nós do ecossistema. Resultados técnicos alcançados: Desacoplamento entre módulos de captura e distribuição; Escalabilidade horizontal do mecanismo de replicação; Redução de inconsistências operacionais; Melhoria na rastreabilidade de eventos; Arquitetura preparada para expansão futura (novos consumidores e integrações). A iniciativa exigiu domínio de mensageria distribuída, controle de concorrência, tratamento de falhas, consistência eventual e desenho arquitetural orientado a eventos.

4

1 comentário