#engenharia-de-software
74 posts
2026 - julho
1 post2026 - junho
2 posts2026 - maio
2 posts2026 - abril
1 post2026 - março
2 posts2026 - fevereiro
1 post2026 - janeiro
1 post2025 - maio
1 post2023 - agosto
1 post2022 - outubro
1 post2022 - maio
1 post2021 - outubro
1 post2021 - setembro
1 post2020 - dezembro
1 post2020 - maio
1 post2019 - outubro
1 post2019 - julho
2 posts2019 - junho
1 post2018 - novembro
1 post2017 - agosto
1 post2017 - junho
2 posts2017 - maio
1 post2015 - dezembro
2 posts2015 - novembro
1 post2014 - setembro
1 post2014 - agosto
1 post2014 - março
1 post2014 - janeiro
1 post2013 - novembro
1 post2013 - outubro
1 post2013 - agosto
1 post2013 - junho
1 post2013 - maio
3 posts2013 - abril
1 post2013 - março
1 post2012 - agosto
1 post2012 - julho
1 post2011 - abril
2 posts2010 - julho
1 post2010 - abril
1 post2010 - janeiro
2 posts2009 - novembro
1 post2009 - setembro
1 post2009 - julho
3 posts2009 - junho
1 post2009 - maio
1 post2009 - março
1 post2009 - fevereiro
1 post2008 - dezembro
2 posts2008 - outubro
1 post2008 - julho
2 posts2008 - junho
1 post2008 - fevereiro
1 post2007 - dezembro
1 post2007 - setembro
1 post2007 - julho
1 post2006 - novembro
1 post2006 - outubro
1 post2006 - setembro
1 post2006 - abril
1 post2026 - julho
1 postFiz o Fable 5 analisar código do TikTok, Clash of Kings e Gov.br - Entendendo Fingerprint
Uma análise estática, feita com o Fable 5, compara o fingerprint opaco do TikTok, o UUID persistente do Clash of Kings e os cuidados de privacidade do gov.br, com ressalvas sobre o método.
2026 - junho
2 postsPor que LLMs vão falhar na Sua Empresa?
A tese, assumidamente especulativa, é que LLMs amplificam processos onde pessoas terceirizam decisões. A alternativa proposta são ciclos diários de decisão, implementação, teste e revisão próximos do resultado.
Controvérsia de IA em contribuições de projetos de código aberto - minha opinião
IA em contribuições open source veio para ficar, mesmo trazendo AI slop, regressões e falsos bugs. A saída prática é automatizar triagem e auditoria, sem tirar do humano a decisão final.
2026 - maio
2 postsBoas práticas de projetos de código aberto com LLM - O Mínimo
Projetos open source feitos com LLM só ficam prontos com instalação simples, testes e CI confiáveis e documentação focada no problema. Padronizar releases e deploys torna a automação previsível.
Terminando Minha Maratona de IA: Sucesso ou Fracasso?
Após mais de 500 horas em 24 repositórios, Akita ranqueia seus experimentos e conclui que Codex e Claude Code sustentam programação diária, mas sem revisão e XP a produtividade vira slop.
2026 - abril
1 postClean Code pra Agentes de IA
Clean Code muda de peso quando o leitor primário é um agente: código pequeno, nomes greppáveis, contexto de proveniência, testes headless e regras explícitas reduzem navegação, custo e erros.
2026 - março
2 postsO código fonte do Claude Code vazou. O que achamos dentro.
Analisei o source map que vazou do Claude Code e encontrei features escondidas, memória em camadas, multiagentes e um DRM baseado em xxHash64. O código também expôs um produto difícil de manter.
Software Nunca Está 'Pronto' — 4 Projetos, a Vida Pós-Deploy, e Por Que One-Shot Prompt É Mito
Depois de 125 commits pós-publicação em quatro projetos, bugs reais, novas features, releases e contribuições externas reforçaram minha conclusão: one-shot serve para demo. Produção exige iteração, testes, CI e decisões humanas.
2026 - fevereiro
1 postTestes de Integração em MonoRepo | Bastidores do The M.Akita Chronicles
Testes unitários não bastavam para três apps que compartilham Markdown. Um ambiente de integração com cache, dados reais via rsync, pipeline paralelo e preflight encontrou bugs que mocks escondiam.
2026 - janeiro
1 postVibe Code: Eu fiz um appzinho 100% com GLM 4.7 (TV Clipboard)
Usei o GLM 4.7 para criar o TV Clipboard, um app Go com WebSockets, QR Code e clipboard remoto. Após mais de 10 horas e 250 prompts, ainda precisei revisar segurança, testes e manutenção.
2025 - maio
1 postRANT - LLMs são LOOT BOXES!
Depois de gastar quase USD 150 em testes, concluí que LLMs ajudam em tarefas pequenas, mas programação real continua parecendo uma loot box cara: mais tokens e agentes não garantem código correto.
2023 - agosto
1 post[Akitando] #144 - Modelagem de Software é Difícil? | "Ver" vs "Enxergar"
Modelagem e arquitetura não seguem uma receita pronta: nascem da experiência com problemas e código real. Livros, open source e mentoria ajudam a desenvolver o olhar para tomar decisões melhores.
2022 - outubro
1 post[Akitando] #130 - Rant: Projetos, TESTES e Estimativa??? | Rated-R
Akita defende provas de conceito, testes, pull requests e integração contínua para errar cedo e evitar regressões. Estimativas servem como ordem de grandeza, não como previsões exatas.
2022 - maio
1 post[Akitando] #119 - Rant: Aprendizado na Beira do Caos | Rated R
Cruzo caos, qualidade, Lean, Six Sigma e Agile para explicar por que não existe fórmula de sucesso. O caminho é assumir riscos controlados, testar cedo, errar barato e ajustar continuamente.
2021 - outubro
1 post[Akitando] #106 - Recomendação de Livros - Introdução à Design Emergente
Akita recomenda livros de algoritmos, compiladores, código limpo, agilidade, padrões e DDD, defendendo que eles oferecem fundamentos e vocabulário, mas que o design emerge do código em uso.
2021 - setembro
1 post[Akitando] #104 - RANT: Empreendendo com Software do JEITO ERRADO!
Akita critica empreendedores que tentam especificar tudo, terceirizam o core e economizam na equipe. Sua proposta combina um sócio técnico, um MVP, equipe interna e evolução contínua.
2020 - dezembro
1 post[Akitando] #88 - RANT: Selo de Segurança é Marketing | Entendendo o Fator Humano
Casos de vazamento, phishing e engenharia social mostram que pessoas continuam sendo o elo mais explorado. Processos, auditorias e frameworks ajudam a reduzir riscos, mas não criam segurança absoluta.
2020 - maio
1 postO Resultado do Modelo do Imperial College sobre a COVID-19 pode estar ERRADO
Akita examina a implementação C++ do modelo de COVID-19 do Imperial College, aponta testes insuficientes e resultados divergentes com os mesmos seeds. Sem código histórico e inputs completos, as projeções não podem ser verificadas.
2019 - outubro
1 post[Akitando] #64 - Começando na Carreira de TI | Faculdade? Níveis de Experiência?
Akita compara cursos de Computação, Engenharia de Software e Sistemas de Informação e explica que a senioridade depende de experiência, decisões confiáveis, orientação e revisão de código.
2019 - julho
2 posts[Akitando] #57 - O Guia DEFINITIVO de Organizações | Desconstruindo o Modelo Spotify [RATED R]
Fabio desmonta a ideia de um “Modelo Spotify” copiável e argumenta que squads, tribes e chapters não resolvem organizações desalinhadas. O caminho passa por direção clara, bons profissionais e melhoria contínua.
[Akitando] #55 - Refletindo sobre RESOLUÇÃO de Problemas | O bug do Premiere
Depois de travar o Premiere durante uma edição pesada, Fabio investiga o problema e encontra uma saída sem trocar de hardware, sistema ou ferramenta. A lição é testar hipóteses e reconhecer o que ainda não se sabe.
2019 - junho
1 post[Akitando] #51 - Esqueça Metodologias "Ágeis" | [Rated R]
Fabio critica o Ágil vendido como processo, métrica ou cerimônia e recupera a ideia central: profissionais responsáveis devem usar práticas como XP para entregar valor e tomar decisões reais.
2018 - novembro
1 post[Akitando] #23 - The MM-M: O Melhor Livro de Software?
Akita revisita The Mythical Man-Month, de 1975, para mostrar que comunicação, equipes pequenas, integridade conceitual, testes e construção incremental continuam resolvendo problemas atuais.
2017 - agosto
1 postPor que Falar Mal do Ruby on Rails é Simplesmente Preguiça
Ruby on Rails não morreu nem lidera mais o mercado. Seu legado ajudou a definir o status quo da web, de Git e testes contínuos à nuvem, deploy contínuo e métricas.
2017 - junho
2 postsEstimativas São Promessas - Uma Metáfora Melhor
Estimativas podem virar promessas quando há gestão de risco: trave tempo e custo, priorize os primeiros 20% do escopo e use entregas em staging e velocidade como termômetros para ajustar o rumo.
A Economia do Desenvolvimento de Software
Para pequenas equipes, a economia do software começa pelo menor produto que funciona, levando o tempo em conta e evitando dívida técnica, microsserviços prematuros e otimizações de performance sem necessidade.
2017 - maio
1 postGuilda de Programadores - Religião e Esportes
Akita compares technology communities to religions and sports teams, showing how identity and confirmation bias distort technical choices. Professionals accept trade-offs and own their decisions.
2015 - dezembro
2 postsEx Manga Downloadr - Parte 5: Deixando mais robusto!
Timeouts do MangaFox expose a flaw in Ex Manga Downloadr’s Workflow. O autor usa Task.Supervisor e retries limitados para capturar erros do HTTPotion, deixando a refatoração com GenServer como dívida técnica.
Ex Manga Downloadr - Parte 4: Aprendendo Através do Refactoring
O refactoring do Ex Manga Downloadr troca seis blocos repetidos por macros, melhora o uso do Floki e usa testes online para validar parsers. O projeto chega à versão 1.0.0 com dois arquivos a menos.
2015 - novembro
1 postObservando Processos em Elixir - The Little Elixir & OTP Guidebook
Com GenServer, Supervisor e Observer, mostro um worker sendo reiniciado, um pool de 5 processos sendo reposto e o runtime permanecendo ativo, embora o estado do worker seja perdido.
2014 - setembro
1 post[Off-Topic] Agile: a Verdade por trás do Método
Defendo que Scrum, XP e outras práticas Ágeis não salvam equipes ruins: elas expõem riscos e problemas rapidamente. Agilidade depende de pessoas comprometidas, prática contínua e mudanças concretas de comportamento.
2014 - agosto
1 post[Small Bite] Um pouco tarde: O Grande Debate Sobre TDD
Depois de assistir ao keynote de DHH e ao debate com Martin Fowler e Kent Beck, o autor considera a disputa secundária: seja Test-First ou Test-After, o essencial é escrever testes.
2014 - março
1 post[Off-Topic] Lean está Morto, longa vida à Eficiência
Agile e Lean viraram uma indústria de cursos, certificações e ferramentas que obscurece seus princípios. O texto defende voltar ao básico: entregar valor, evitar desperdício, aprender e questionar.
2014 - janeiro
1 postCodeClimate, Qualidade de Código e os Rubistas Sádicos
Code Climate transforma métricas de complexidade, duplicação, segurança e testes em uma nota contínua para projetos Ruby. Ela ajuda a localizar code smells, mas não substitui a avaliação humana do código.
2013 - novembro
1 post[Off-Topic] Agile feito Errado
O texto argumenta que Agile não salva equipes sem capacidade técnica e comprometimento. Planning, pair programming, qualidade e responsabilidade viram encenação, e maus profissionais precisam ser substituídos.
2013 - outubro
1 post[Off-Topic] Desmontando o #noEstimates
O autor separa projetos de operações contínuas para defender estimativas, objetivos e restrições em projetos. Para ele, restrições impulsionam inovação, mas execução competente pesa mais que qualquer metodologia.
2013 - agosto
1 post[Off-Topic] Estimativas são Promessas. Promessas devem ser cumpridas.
O autor argumenta que estimativas de software são promessas, não previsões, e que cumpri-las exige responsabilidade por comunicação, negociação, tempo e obstáculos, além de código.
2013 - junho
1 postIntrodução à Agilidade
Robert Martin recounts how XP, Scrum, and Crystal converged in the 2001 Agile Manifesto. The author warns against dogmatic processes and consultancies that put methods ahead of people and customer value.
2013 - maio
3 postsDesmistificando o método Kanban
Kanban é uma técnica do Sistema Toyota de Produção, não seu sinônimo. O texto mostra por que copiar cartões no software não basta sem racionalização, Kaizen e melhoria contínua.
Processos e Metodologias não vão te Ajudar
Processos e metodologias não criam bons desenvolvedores. O texto defende prática contínua e profissionais competentes primeiro, para só então usar técnicas e processos capazes de ampliar seu trabalho.
[Tradução] Padrões: excelência vs. mediocridade
Ao relatar um exercício na Toyota, Jason Yip mostra que o padrão era o tempo do campeão, quatro segundos. O texto contrapõe padrões que limitam a padrões que impulsionam a excelência.
2013 - abril
1 post[Tradução] Estimativa - O Melhor que Podemos Fazer
Ron Jeffries defende estimativas como intervalos de custo e velocidade, usados para testar riscos, decidir a cada duas semanas e orientar o produto sem virar promessa ou negociação.
2013 - março
1 postQuais são algumas das piores práticas para aplicações Ruby on Rails?
Ao revisar projetos Rails problemáticos, o autor aponta falta de testes, SQL manual, N+1, NoSQL sem justificativa e código sem documentação, mostrando como o ActiveRecord reduz 11 queries a 2.
2012 - agosto
1 post[Off-Topic] O Mito do "Legado"
O autor critica a reescrita automática de sistemas legados e conta como consertou, em duas semanas, um ASP com DCOM, preservando o código e conquistando um novo projeto do cliente.
2012 - julho
1 post[Off-Topic] Steve Jobs, The Lost Inverview
Ao comentar a entrevista perdida de Steve Jobs, o autor reforça que uma ideia só ganha valor com execução, refinamento e equipes talentosas, capazes de discutir, errar e melhorar o trabalho.
2011 - abril
2 posts[Off-Topic] Adendo à controvérsia HAML, SASS, Coffeescript: Tamanho do Documento
Akita argumenta que escolher HAML, SASS ou CoffeeScript exige mais que gosto pessoal: manutenção, contrato, fornecedores e contexto do cliente também definem se a troca vale a pena.
A Controvérsia CoffeeScript
Akita explica como SASS, HAML e CoffeeScript transformam código antes da execução e distingue ganhos reais de manutenção no SASS de escolhas estéticas, com custo extra para quem dará suporte.
2010 - julho
1 post[Screencast] Entenda Software da Maneira Correta
Nesta palestra na USP, o autor usa Open Source, Darwin, Galvão Bueno e Dwayne Johnson para questionar por que processos não garantem software de qualidade.
2010 - abril
1 post[Off-Topic] O Programador Humilde, por Edsger W. Dijkstra
Dijkstra defende humildade diante da dificuldade de programar: é melhor evitar bugs desde o início, usar abstrações e linguagens modestas, pois nenhuma ferramenta elimina a complexidade.
2010 - janeiro
2 posts[Off-Topic] Lendo os Princípios Ágeis
Os 12 princípios ágeis precisam ser lidos em conjunto: entregar valor rapidamente não dispensa qualidade, simplicidade, colaboração e melhoria contínua. Manifesto não é receita pronta.
[Off Topic] Dunbar e Cross Functional Teams
Nos experimentos de Dunbar, um laboratório multidisciplinar resolveu em 10 minutos um problema que especialistas em E. coli levaram semanas para vencer. Debate e metáforas fazem novas ideias emergirem.
2009 - novembro
1 post[Off-Topic] Restaurantes e Tecnologia
A analogia com restaurantes separa empresas cujo negócio central é tecnologia das que apenas a usam como suporte. Nas primeiras, programadores devem experimentar e criar ferramentas, como no GitHub.
2009 - setembro
1 post[Off-Topic] Procurar Raciocinar Faz Bem
Uma reflexão sobre programação em par, responsabilidade e as divergências entre Spolsky e Bob Martin defende testar práticas ágeis, entender seus motivos e rejeitar dogmas.
2009 - julho
3 posts[Tradução] O que faz um bom programador?
Duas traduções defendem que bons programadores priorizam usabilidade, responsabilidade, colaboração e entrega. A segunda acrescenta a preguiça criativa e a humildade de fazer perguntas simples ao depurar.
[Off-Topic] Intervir ou não Intervir? O "Catch-22" dos Co-Pilotos
A partir de acidentes aéreos, o autor adapta o protocolo PACE a equipes de software: perguntar, alertar, desafiar e intervir quando um gerente ignora riscos graves.
[Off-Topic] Autoridade vs Responsabilidade
O autor argumenta que separar autoridade e responsabilidade condena processos ao fracasso. Equipes que respondem pelos resultados devem decidir seu próprio trabalho, com especialistas atuando como consultores.
2009 - junho
1 post[Tradução] Conselhos para Gerentes de Desenvolvimento de Software
Gerald Weinberg mostra como a cultura de culpa e a comunicação incongruente sabotam projetos, enquanto a congruência melhora a resolução de problemas. A mudança passa por seis etapas.
2009 - maio
1 post[Off-Topic] As 5 disfunções de equipes em código
Cinco disfunções de equipes aparecem em anti-padrões como null checks, duplicação, código sem testes e soluções difíceis de entender. Técnicas isoladas não resolvem uma organização baseada em comando e controle.
2009 - março
1 post[Off-Topic] Net Negative Producing Programmer
Fabio apresenta o conceito de NNPP, o programador que produz prejuízo acumulando dívida técnica ou virando ponto único de falha, e distingue esse perfil de juniores dispostos a aprender.
2009 - fevereiro
1 postTradução: Scrum Flácido
A tradução de Martin Fowler mostra como adotar Scrum sem práticas técnicas pode deixar o código flácido. Fabio reforça testes, refatoração, integração frequente e propriedade coletiva.
2008 - dezembro
2 postsTradução: Dívida Técnica
A tradução de Steve McConnell separa dívidas técnicas acidentais das estratégicas, explica seus juros e sugere registrá-las no backlog. Atalhos podem fazer sentido quando são rastreáveis e pagáveis.
Off-Topic: Método Científico vs Cargo Cult
Fabio critica o cargo cult na programação e propõe testar hipóteses com pesquisa, protótipos descartáveis e experimentos. Na YellowPages, quatro meses de preparação evitaram transformar quatro meses de implementação em vinte.
2008 - outubro
1 postOff-Topic: O Manifesto Ágil, ou Como se Tornar o Google
O autor argumenta que agilidade depende de filosofia, confiança e equipes auto-organizadas, não só de procedimentos. Com Conway, open source e Google, defende uma cultura que favoreça inovação e adaptação.
2008 - julho
2 postsTradução: Por que você não deve codificar em Português
A tradução defende nomes em inglês para variáveis, funções, classes, campos, bancos e comentários, porque isso facilita manutenção e colaboração internacional. O argumento é pragmático.
Tradução: Regras de Otimização
As regras de otimização são simples: escreva código claro, meça antes de mexer e concentre o esforço nos gargalos comprovados, preservando a manutenção do restante.
2008 - junho
1 postMachucando Código por Diversão e Lucro
Traduzi o keynote de Ryan Davis e gravei um screencast em português sobre cuidar, refatorar e até “machucar” código para evoluir como programador. Os slides também estão disponíveis em PDF.
2008 - fevereiro
1 postTradução: Não sei o que quero, mas sei como conseguir
A tradução separa desenvolvimento iterativo, que espera validar e mudar uma solução, de incremental, que adiciona funcionalidade. O argumento é planejar espaço para descobrir, refinar e descartar.
2007 - dezembro
1 postCuidado com suas Closures
Closures Ruby podem manter vivos objetos e variáveis capturados sem necessidade. O texto explica o problema e sugere criar blocos no menor escopo possível.
2007 - setembro
1 post100% pure Object-Oriented: The Fallacy
O texto questiona a ideia de que mais pureza orientada a objetos torna uma linguagem melhor e defende escolher a tecnologia pelos requisitos concretos de cada projeto.
2007 - julho
1 postGoF Design Patterns - Sobreviveu ao teste do tempo?
A discussão sobre o livro GoF contrapõe críticas à complexidade e à relevância dos patterns com sua utilidade como exemplos de design, desde que não sejam copiados como receitas ou dogmas.
2006 - novembro
1 postMinha Coluna na RubyOnBr: Desenvolvimento Sustentável com Rails
A coluna percorre processos, metodologias e ferramentas para discutir desenvolvimento sustentável com Rails. A conclusão é que todo projeto precisa de algum controle, inclusive no open source, onde mantenedores organizam o trabalho.
2006 - outubro
1 postLivro Free: Getting Real, da 37signals
A 37signals libera Getting Real para leitura online, defendendo software simples, telas reais e decisões baseadas no produto que o usuário vê. A abordagem combina especialmente com web apps que evoluem continuamente.
2006 - setembro
1 postEvolução pela Concorrência
O autor defende que críticas e concorrência fazem tecnologias evoluírem. Em Rails, limitações como internacionalização, legado e tarefas assíncronas já estimularam soluções da comunidade.
2006 - abril
1 postRails Manifesto
O autor apresenta Rails como alternativa ágil à complexidade do J2EE, apoiada em DRY e Convention over Configuration. A proposta é tornar aplicações Web simples e fáceis de adaptar.