Sebastian

Rules and Flux based Context awareness arch with @reactjs for an isomorphic #JavaScript @nodejs #CMS framework

@thekitze people used for http fetching stuff which is a mistake, but for local domain state using libs from the ecosystem it was pretty robust and not much code. migrating and refactoring apps with redux was so easy, all the app logic separated from components by design

i've never heard an audience clap this hard!! 👏 great conference btw

I'm starting to think that DDD might be the answer to all of my problems - Model not doing what you want? Shared language - Can't navigate a massive codebase? Bounded contexts with global mapping - Don't know why a decision was made? ADR's It's just so freaking elegant

@mattpocockuk Good to see an influencer like you saying this, DDD is an has being a solid strategic design principle, and now with AI it makes more sense than ever. New or hyped devs are going to listen to you more than reading books like from Eric Evans or Vaughn Vernon…

@heygurisingh How is different from github.com/giancarloerra/… ?

🚨Breaking: Someone open sourced a knowledge graph engine for your codebase and it's terrifying how good it is. It's called GitNexus. And it's not a documentation tool. It's a full code intelligence layer that maps every dependency, call chain, and execution flow in your repo -- then plugs directly into Claude Code, Cursor, and Windsurf via MCP. Here's what this thing does autonomously: → Indexes your entire codebase into a graph with Tree-sitter AST parsing → Maps every function call, import, class inheritance, and interface → Groups related code into functional clusters with cohesion scores → Traces execution flows from entry points through full call chains → Runs blast radius analysis before you change a single line → Detects which processes break when you touch a specific function → Renames symbols across 5+ files in one coordinated operation → Generates a full codebase wiki from the knowledge graph automatically Here's the wildest part: Your AI agent edits UserService.validate(). It doesn't know 47 functions depend on its return type. Breaking changes ship. GitNexus pre-computes the entire dependency structure at index time -- so when Claude Code asks "what depends on this?", it gets a complete answer in 1 query instead of 10. Smaller models get full architectural clarity. Even GPT-4o-mini stops breaking call chains. One command to set it up: `npx gitnexus analyze` That's it. MCP registers automatically. Claude Code hooks install themselves. Your AI agent has been coding blind. This fixes that. 9.4K GitHub stars. 1.2K forks. Already trending. 100% Open Source. (Link in the comments)

pessoas inteligentes são outro nível

Why aren’t people having children? “Animals don't breed in captivity.”

Code review made sense when humans wrote code at human speed. Now I'm on a beach with a genie, generating faster than anyone could review. The old model broke. What replaces it? open.substack.com/pub/tidyfirst/… New post, sponsored by @coderabbitai

Inscrições abertas 🚀 FOIII

@sseraphini @zanfranceschi Gostei! E tem que se atentar que sem transparência referencial em linguagens tipo JS o que entra e sai da função pode sim ser mutável

O @zanfranceschi simplificou a explicação de funcional vs OOP O modelo mental do funcional torna tudo mais simples e explícito OOP tem estado implícito e mutável

@sseraphini Para obter um entendimento compartilhado válido do problema e desenvolver uma solução mais assertiva. Ler requisitos é comunicação empurrada com foco em reduzir backlog mais do que gerar uma mudança de comportamento do usuário ou sistema que deriva em negócio. Outcomes > Outputs

Por que o Dev acha que precisa falar com alguém de Negócios?

@sseraphini boa ai botei fé

Não temos Sprint na Woovi Sprint não é agile

@gustavo_pch @sseraphini Tecnologia não fiu, modelo de negócio e distribuição de lucros, presta atenção

Impressionante como essa galera é contra qualquer tipo de tecnologia. Não pode Airbnb, não pode Uber, não pode iFood, não pode IA, não pode energia nuclear, não pode exploração espacial, etc.

@LucasMasotti ansioso pela tua participação Lucas!

@sebas5384 Estarei lá! 😄

"bora fazer uma call de alinhamento?" ..... se essa pergunta te deixa tenso, acredito que posso ajudar mas faltam só 5 dias para a 2a edição do curso onde mostro como melhorar a comunicação usando ferramentas tipo #EventStorming e outras práticas do #DDD softwarezen.com.br/produtos/model…

Floripa receberá mais um meetup da Codecon! Será no dia 17/07 na Neoway. Teremos palestra da @masisiliani e do @sebas5384! E será incrível! As incrições são gratuitas, corre lá. eventos.codecon.dev/meetup-codecon…

AI turns wi-fi routers into "cameras" that see people through walls twitter.com/i/status/18047…

Durante o trabalho na Lambda3, sempre que precisava conhecer um executivo de TI, ou um arquiteto chefe, esse tipo de conversa acontecia: “você não é o Netflix, não precisa de microsserviços, precisa ser interativo e incremental, nenhum projeto rolo compressor da certo no longo prazo, etc”. E ele nunca funcionou. Decisões de arquitetura quase nunca são tomadas tecnicamente. Explico: No mundo corporativo, é muito comum executivos quererem um case de tecnologia complexo, de implantação longa, vendido como se fosse a coisa mais fácil do mundo de entregar. Esse tipo de case ajuda na promoção ou no novo trabalho que eventualmente eles vão buscar. Aqueles que não saem da empresa em 2 anos, se agarram em cases para que possam garantir um budget eterno de melhorias, que normalmente vai ser utilizado para ampliar a influência na organização: negociar features e time com áreas de negócio é o mínimo. Não é só dev que permanece pouco na empresa, gestores também. Como você vai buscar uma nova posição de liderança se não tem experiência com grandes projetos de implantação de microsserviços? A regra é cair pra cima, pegar a primeira empresa que ainda não apanhou com um projeto rolo compressor, e assegurar um cargo bom. Decisões de arquitetura não são tomadas por tecnologia, julgo dizer, a grande maioria das vezes. A solução mais simples para a área de negócio não garante uma equipe de TI inflada, um fluxo contínuo de budget e influência política real. Quanto mais pessoas em baixo de você, mais poder você tem. Além disso, a maior parte dos fornecedores de tecnologia querem empurrar um arquitetura complexa porque isso garante lock-in e bate meta de venda. Numa discussão contratual, isso sempre será oportunidade de negociação: todo desconto do mundo na nuvem, mas apenas se utilizar os serviços nativos. No fim, você tem uma briga política por poder: Conway’s law já explicava isso há algum tempo, uma fila de fornecedores querendo garantir sua dependência infinita, a busca por um case moderno de ti e nenhum compromisso de seguir tocando o projeto uma vez que tudo isso vier a baixo - tempestade perfeita.

@marcelojscosta @psanrosa13 @vepo @rponte @coproduto @programador_who @RealGalego Tenho produzido vários materiais nestes últimos anos sobre EventStorming! Deixo uma listinha aqui: - youtu.be/aAuU0PwzGeI?si… - youtube.com/live/CseMVZXW1… - blog.taller.net.br/eventstorming-…

@marcelgsantos @marcelojscosta @rponte @psanrosa13 @vepo @coproduto @programador_who @RealGalego @codecondev Obrigado pela indicação @marcelgsantos 🤘 Na @tallerteam temos treinamento e consultoria de EventStorming 😉 e este ano fizemos um mini workshop no TDC Floripa e farei outro na Codecon Select

@marcelojscosta @rponte @psanrosa13 @vepo @coproduto @programador_who @RealGalego O @sebas5384 é um ótimo nome. Fiz um workshop de Event Storming com ele na @codecondev Feature no ano passado e foi excelente. Eu ouvi tambem ele falar sobre o assunto no podcast da Taller e no Tech Leadership Rocks.

@sseraphini Http

Tópicos que os Devs acham que sabe, mas não sabem? idempotencia multitenant o que mais ?