Em destaque agora
Ver todas as dicas
Guia de Compra de Ferramentas Elétricas
Guia completo para você escolher ferramentas de acordo com sua necessidade.
Ler dica
Cartões SD Sandisk Piratas
Dicas que podem auxiliar a escolher o melhor dispositivo e evitar os piratas!
Ler dica
Organizando os desenhos
Organizar esses desenhos tem sido um desafio em tempos de confinamento...
Ler dica
Template html básico para Arduino, ESP82
O básico pra quem esta com pressa!
Ler dica
Como embalar malas para viagem
Embale malas para viagem como os serviços de aeroportos fazem
Ler dica
Como deixar o libreoffice em pt-br
O LibreOffice é uma alternativa gratuita
Ler dica
Como economizar detergente
Aproveitar melhor o uso do sabão na hora de lavar louça
Ler dica
Como limpar sua grelha da churrasqueira
Faça uma limpeza rápida e prática da sua grelha
Ler dica
Remova riscos da lataria do carro
Remova riscos da lataria do seu carro facilmente com óleo lubrificante
Ler dica
Reaproveitando o rolinho de papel
Algumas dicas de como reutilizar o rolinho do papel higiênico
Ler dica
Tire o cheiro de alho das mãos
Uma dica super fácil e funcional
Ler dica
Pré-amplificador de áudio
Pré-amplificador de áudio para microfones de eletreto
Ler dicaMais recentes
Como trabalhar com LLMs de forma eficiente e profissional
1. Introdução e Contexto Esta apostila é baseada na palestra e workshop ministrados por Matt Pocock, professor e especialista em TypeScript, no evento de conferência documentado no vídeo de referência. O tema central é que, apesar de a IA representar um novo paradigma tecnológico, os fundamentos da engenharia de software que sempre funcionaram para humanos também funcionam de forma excelente ao trabalhar com IA. 1.1 A Tese Central A ideia chave da palestra é: • Todos acreditam que a IA é um paradigma completamente novo • Esquecemos que os fundamentos da engenharia de software continuam essenciais • Essas práticas clássicas funcionam muito bem quando aplicadas a LLMs Citação do autor "Quando falamos sobre IA como um novo paradigma, esquecemos que os fundamentos da engenharia de software - as coisas que são cruciais para trabalhar com humanos - também funcionam muito bem com IA." 1.2 Público e Contexto A palestra foi apresentada para um grupo de desenvolvedores com diferentes níveis de experiência com IA, com perguntas e demonstrações ao vivo. O workshop tem duração de aproximadamente 2 horas e inclui exercícios práticos. 2. Restrições Fundamentais dos LLMs Antes de entrar nas técnicas práticas, é essencial compreender as limitações técnicas dos modelos de linguagem grandes (LLMs). O autor identifica duas restrições principais que moldam toda a abordagem de desenvolvimento com IA. 2.1 As Duas Restrições Principais Restrição Descrição Zona Inteligente / Zona Burra LLMs degradam em qualidade conforme a janela de contexto cresce O Efeito Memento LLMs não possuem memória entre sessões; resetam ao estado inicial Compreender essas duas restrições é o ponto de partida para toda a metodologia apresentada neste workshop. 3. O Problema do Contexto: Zona Inteligente e Zona Burra Este conceito, atribuído a Dex Hardy da empresa Human Layer, é fundamental para trabalhar com LLMs de forma eficiente. 3.1 Como Funciona a Atenção nos LLMs Cada vez que você adiciona um token a um LLM, o número de relações de atenção cresce de forma quadrática - semelhante ao número de jogos em uma liga de futebol conforme novas equipes são adicionadas. Isso ocorre porque há relações de atenção de cada token para todos os outros, envolvendo posição e significado individual de cada token. 3.2 Definição das Zonas Zona Característica Zona Inteligente Início da conversa, contexto limpo, LLM trabalha com máxima eficiência Zona Burra Contexto sobrecarregado (~100K tokens), LLM começa a tomar decisões ruins Marcador prático O autor usa ~100K tokens como referência para o início da zona burra, independentemente do tamanho total da janela de contexto (1 milhão ou 200K). Sempre monitore o contador de tokens. 3.3 Estratégias para Trabalhar na Zona Inteligente • Dimensione as tarefas para caber dentro da zona inteligente • Não deixe a IA 'morder mais do que pode mastigar' • Mantenha o prompt de sistema (system prompt) pequeno e enxuto • Evite acumular sedimentos desnecessários no contexto Referência clássica O autor cita Martin Fowler (Refactoring) e The Pragmatic Programmer - livros que já ensinavam: 'Não assuma mais do que você pode executar. Mantenha suas tarefas pequenas para que você, como desenvolvedor humano, não entre em pânico e caia na zona burra.' 3.4 Fases de uma Sessão LLM Toda sessão com um LLM passa pelas mesmas fases: • Prompt de sistema (system prompt) - sempre presente no contexto • Fase exploratória - o agente explora o código-base • Implementação - escrita efetiva do código • Testes - loops de feedback e validação 3.5 Compactação vs. Limpar o Contexto Quando você se aproxima do limite, existem duas opções: • Compactação (Compacting): resume toda a conversa em um histórico menor e continua • Limpar (Clear): apaga tudo e volta apenas ao prompt de sistema O autor prefere claramente a segunda opção (limpar), pois: ◦ O estado inicial é sempre o mesmo - previsível e consistente ◦ Compactações acumulam 'sedimentos' que degradam a qualidade ◦ Reiniciar permite trabalhar sempre na zona inteligente 4. Os LLMs como o Personagem de Memento A segunda restrição fundamental é que os LLMs são como o protagonista do filme Memento: eles esquecem tudo e voltam ao estado base a cada nova sessão. Não há persistência de memória entre conversas. Isso significa que toda estratégia de desenvolvimento com IA precisa considerar: • Não confiar na memória do LLM entre sessões • Criar documentos e artefatos externos que persistam o contexto • Projetar fluxos que funcionem bem com contexto recém-inicializado • Enxergar o reinício como uma vantagem (sempre começa no melhor estado) Insight-chave Em vez de tentar compensar o esquecimento do LLM, o autor abraça essa característica e projeta seu fluxo de trabalho para tirar vantagem dela: trabalhar sempre com contexto limpo significa trabalhar sempre na zona inteligente. 5. O Fluxo de Desenvolvimento com IA Com base nas restrições entendidas, o autor apresenta um fluxo de desenvolvimento estruturado que maximiza a eficiência do LLM enquanto mantém o controle humano nos pontos críticos. 5.1 Visão Geral do Fluxo Fase Atividade 1. Alinhamento Sessão de interrogatório (Grill Me) - HUMANO no loop 2. Documentação Criação do PRD (Product Requirements Document) - HUMANO revisa 3. Planejamento Criação do Kanban Board com issues paralelas - HUMANO valida 4. Implementação Loop AFK com agentes (Ralph Loop) - IA trabalha sem supervisão 5. QA e Review Testes, code review, iterações - HUMANO impõe padrões e gosto 5.2 Tarefas Humanas vs. Tarefas AFK O autor distingue claramente dois tipos de tarefas: Tipo Descrição Human-in-the-loop Requerem presença humana: planejamento, alinhamento, QA AFK (Away From Keyboard) Podem ser delegadas totalmente à IA: implementação Analogia: turno do dia e da noite O planejamento é o turno do dia - o humano organiza tudo. A implementação é o turno da noite - a IA trabalha AFK enquanto o humano descansa ou faz outras coisas. 5.3 Crítica ao Movimento 'Specs to Code' O autor critica fortemente a abordagem de 'especificações para código' que é popular atualmente: • Consiste em escrever especificações detalhadas e simplesmente transformá-las em código via IA • Se algo der errado, você edita a especificação, não o código • É essencialmente 'vibe coding' com outro nome • O autor testou e afirma que simplesmente não funciona O motivo pelo qual falha: ◦ Você precisa manter controle sobre o código ◦ Você precisa entender o que está dentro do código ◦ Você precisa moldar o código porque ele é o seu campo de batalha 6. Fase 1 - O Interrogatório (Grill Me Skill) A primeira fase do fluxo é o que o autor chama de 'Grill Me' (me interrogue). Esta é a etapa de alinhamento entre o desenvolvedor e o LLM antes de qualquer escrita de código. 6.1 O Problema de Alinhamento O principal problema ao trabalhar com IA no desenvolvimento de software é o misalignment - quando o desenvolvedor e o LLM têm entendimentos diferentes sobre o que está sendo construído. O 'Grill Me' resolve isso. 6.2 Como Funciona O skill 'Grill Me' é uma instrução pequena e concisa que instrui o LLM a: • Fazer perguntas agressivas e diretas sobre a ideia sendo desenvolvida • Continuar questionando até ter um entendimento completo do problema • Explorar edge cases, decisões técnicas e escopo • Criar um 'conceito de design compartilhado' entre humano e IA Resultado do Grill Me Após uma sessão de interrogatório, o autor usa ~25K tokens. Todo esse conteúdo é 'ouro' - um alinhamento profundo sobre o que será construído. Esse contexto é então destilado em documentos permanentes. 6.3 Por Que Não Usar Ferramentas como Taskmaster ou Spec Kit? O autor foi questionado sobre frameworks alternativos. Sua posição: • Com tantas ferramentas surgindo e mudando, você precisa ser dono do seu planejamento • Estudantes que adotam stacks de terceiros sem entendê-las ficam presos quando algo dá errado • Controle total da sua stack = capacidade de corrigir problemas 6.4 Aplicação em Equipes Para equipes maiores, o Grill Me pode ser usado em par ou em grupo: • Pair programming com IA: um terceiro personagem que questiona incansavelmente • Mob programming com IA: múltiplos humanos e a IA na mesma sessão • As decisões cruciais precisam de humanos; a IA facilita o processo 7. Fase 2 - O Documento de Requisitos (PRD) Após o interrogatório, o próximo passo é transformar o alinhamento alcançado em um documento permanente: o Product Requirements Document (PRD). 7.1 A Função do PRD O PRD serve como o 'documento de destino' - descreve para onde estamos indo. Diferente dos planos de implementação, o PRD define o estado final desejado. 7.2 Estrutura Recomendada do PRD Seção do PRD Conteúdo Declaração do Problema Qual problema o usuário enfrenta Solução Proposta Como resolver o problema User Stories Lista de histórias de usuário (~15-20 itens) Decisões de Implementação Escolhas técnicas feitas Decisões de Testes Estratégia de testes Módulos Propostos Quais partes do código serão modificadas Fora do Escopo O que NÃO será feito nesta iteração 7.3 Módulos no PRD - O Código Sempre em Mente Um diferencial importante da abordagem: ao criar o PRD, já se pensa nos módulos de código que serão afetados. Isso garante que o processo nunca ignore o código-base real. • Identifica os módulos que serão criados ou modificados • Define as interfaces que cada módulo vai expor • Classifica dependências: locais, substituíveis, banco de dados de teste 7.4 Deve-se Revisar o PRD? Surpreendentemente, o autor afirma que geralmente NÃO lê o PRD gerado: • LLMs são excelentes em sumarização - isso já está garantido • Após a sessão de interrogatório, o alinhamento já existe • Revisar seria apenas verificar a capacidade de sumarização do LLM 7.5 Doc Rot - Cuidado com Documentação Antiga O autor alerta sobre um perigo chamado 'doc rot': documentação antiga que permanece no repositório e contamina o contexto do agente com informações desatualizadas. Boa prática Após a implementação ser concluída, feche ou arquive o PRD. Se usar GitHub Issues, marque como fechado. Não deixe documentação de especificação desatualizada flutuando no repositório, pois o LLM pode encontrá-la e usá-la como verdade. 8. Fase 3 - O Kanban Board e Paralelismo Com o PRD definido, o próximo passo é transformar os requisitos em issues (tickets) independentes que podem ser trabalhados em paralelo por múltiplos agentes. 8.1 De Plano Sequencial para Grafo Acíclico Dirigido A maioria dos desenvolvedores usa planos sequenciais em fases (fase 1, fase 2, fase 3). O autor argumenta que isso limita o paralelismo: • Plano sequencial: apenas um agente pode trabalhar por vez • Kanban com dependências: múltiplos agentes podem trabalhar em paralelo nas tarefas sem bloqueio A estrutura ideal é um Directed Acyclic Graph (DAG) - um grafo acíclico dirigido onde as dependências entre tarefas são explícitas e apenas o necessário é sequencial. 8.2 Vertical Slices vs. Horizontal Slices Um conceito central na criação dos issues é preferir fatias verticais: Tipo de Slice Descrição Horizontal (BAD) Implementa uma camada por vez (ex: só o serviço, só o banco) Vertical (GOOD) Implementa uma funcionalidade completa de ponta a ponta Exemplo de vertical slice Em vez de 'criar o serviço de gamificação' (horizontal), prefira 'mostrar pontos ganhos por conclusão de aula no dashboard' - isso toca no schema, no serviço e no frontend simultaneamente, resultando em algo visualmente testável. 8.3 Características dos Issues Ideais • Independentes - podem ser pegos por qualquer agente • Com dependências explícitas mapeadas • Com critérios claros de conclusão • Em fatias verticais (mostram resultado visível ao final) • Organizados como um grafo, não uma lista linear 8.4 Ferramentas para o Kanban O autor usa GitHub Issues como ferramenta principal, mas menciona que arquivos locais em Markdown também funcionam para fins didáticos. Issues fechadas no GitHub ficam acessíveis mas com indicador visual de 'feito'. 9. Fase 4 - Implementação AFK (Loop Ralph) Com o Kanban preparado, chega a fase onde o humano sai do loop e os agentes trabalham autonomamente. O autor chama isso de 'Ralph Loop'. 9.1 O Conceito Ralph Baseado na ideia de 'Ralph Wiggum' como prática de software, o Ralph Loop funciona assim: • Define-se um destino (PRD + issues) • O agente faz uma pequena mudança de cada vez que o aproxima do destino • O loop continua até que todas as tarefas estejam completas Analogia com o loop O autor compara ao raciocínio: se você tem fase 1, fase 2, fase 3, fase N... por que não ter apenas fase N? Um loop que continua até a conclusão. 9.2 Estrutura Técnica do Loop O script (once.sh) que executa o loop faz o seguinte: • Coleta todas as issues do backlog em arquivos Markdown • Captura os últimos 5 commits do repositório • Passa tudo para o Claude Code com modo de permissão automática • O agente escolhe a próxima tarefa, implementa, e registra o resultado 9.3 Prioridades do Agente no Loop O prompt do loop AFK define prioridades: • 1. Correções de bugs críticos • 2. Infraestrutura de desenvolvimento • 3. Tracer bullets (funcionalidades de ponta a ponta mínimas) • 4. Quick wins e refatorações 9.4 Modo Sequencial vs. Paralelo O autor recomenda começar com o modo sequencial (um agente de cada vez) para ganhar familiaridade antes de partir para a paralelização. Paralelização avançada Com múltiplos agentes em paralelo, cada um trabalha em uma branch separada dentro de um sandbox Docker. Um agente 'planner' escolhe as tarefas sem bloqueio mútuo, agentes 'implementers' executam em paralelo, e um agente 'merger' consolida os resultados, resolvendo conflitos de tipos e testes. 10. Test-Driven Development (TDD) com IA O TDD é apresentado como absolutamente essencial para obter o máximo dos agentes de IA. O autor afirma ter moldado toda a sua técnica em torno de fazer o TDD funcionar bem. 10.1 Red-Green-Refactor com IA O ciclo clássico do TDD funciona assim: • Red: Escreva um teste que falha (a funcionalidade ainda não existe) • Green: Escreva o código mínimo para fazer o teste passar • Refactor: Melhore o código mantendo os testes passando 10.2 Por Que a IA Escreve Testes Ruins Sem TDD Sem TDD, a IA tende a 'trapacear': • Escreve toda a implementação primeiro • Depois escreve os testes para a implementação que já existe • Os testes ficam acoplados à implementação, não à especificação Com TDD, esse problema é muito mais difícil de ocorrer porque: ◦ O teste é escrito ANTES da implementação ◦ O código é instrumentado antes de ser escrito ◦ A ordem natural força testes baseados em comportamento 10.3 Loops de Feedback - O Teto da Qualidade Os loops de feedback (rodar testes, verificar tipos) são essenciais para qualquer output razoável da IA: Loop de Feedback Propósito npm run test Verificar que a lógica de negócio funciona npm run type-check Garantir correção de tipos (TypeScript) Feedback visual (QA) Verificar que o resultado é visível e correto Insight fundamental Se você está recebendo outputs ruins do agente, frequentemente a solução é melhorar a qualidade dos seus loops de feedback. O teto da qualidade do output é determinado pela qualidade dos seus mecanismos de verificação. 11. Arquitetura de Código: Módulos Profundos vs. Rasos Baseado no livro 'The Philosophy of Software Design' de John Ousterhout, o autor apresenta um conceito crucial para código que funciona bem com IA. 11.1 Módulos Rasos (Shallow Modules) - Evitar Módulos rasos são caracterizados por: • Muitos arquivos pequenos com poucas responsabilidades • Interfaces complexas expondo muitas funções • Dependências cruzadas difíceis de rastrear Problemas com módulos rasos para IA: ◦ A IA precisa navegar manualmente por todo o grafo de dependências ◦ Difícil definir fronteiras de teste ◦ Mocks excessivos tornam os testes frágeis e sem sentido 11.2 Módulos Profundos (Deep Modules) - Ideal Módulos profundos têm: • Interface pequena e simples (poucos pontos de entrada) • Muita funcionalidade encapsulada internamente • Fronteiras de teste claras e naturais Vantagens para IA: ◦ A IA entende facilmente o que o módulo faz pela sua interface ◦ Fácil envolver com um único teste abrangente ◦ Comportamento testável do exterior sem necessidade de mocks complexos Comportamento natural da IA Sem orientação, a IA naturalmente produz código com módulos rasos. É preciso orientá-la ativamente para criar módulos profundos, tanto no PRD (definindo as interfaces) quanto durante a implementação. 11.3 A Estratégia dos 'Gray Boxes' O autor propõe uma abordagem mental para manter domínio sobre o código: • Projete as interfaces dos módulos você mesmo • Delegue a implementação interna para a IA • Você não precisa saber todos os detalhes internos • Você precisa saber o que cada módulo faz e como ele se comporta Resultado: você mantém o senso do código-base enquanto preserva sua sanidade mental diante do volume de código gerado por IA. 11.4 A Habilidade 'Improve Codebase Architecture' O autor demonstra uma skill que escaneia o código-base em busca de: • Módulos que poderiam ser aprofundados • Grupos de módulos relacionados que poderiam ser testados como uma unidade • Lacunas de cobertura de testes • Oportunidades de simplificação de interfaces 12. QA e Code Review com IA A fase de QA é onde o desenvolvedor humano impõe seus padrões, gosto e julgamento ao código gerado pela IA. 12.1 A Importância do QA Humano O autor observa que equipes que tentam automatizar tudo - incluindo planejamento, QA, pesquisa e protótipos - acabam com aplicações que: • Carecem de gosto e qualidade • Não funcionam como esperado • São 'slop' (conteúdo de baixa qualidade sem julgamento) O toque humano é essencial. QA não é apenas sobre bugs - é sobre impor os padrões e a visão do desenvolvedor. 12.2 Code Review na Zona Inteligente Um insight técnico importante: fazer code review após uma longa implementação significa revisar na zona burra. A solução: • Limpe o contexto antes de fazer code review • Revise com o contexto em estado inicial (zona inteligente) • O revisor terá mais capacidade de atenção e identificará mais problemas 12.3 Estratégia de Review Processo recomendado pelo autor: • 1. Revisar primeiro os testes - verificar se estão testando coisas razoáveis • 2. Revisar o código - verificar se não está fazendo nada louco • 3. Fazer QA manual - testar visualmente o resultado • 4. Criar novas issues para problemas encontrados - alimentando o Kanban Code Review pelo Agente Para review automático: use um agente revisor separado com o contexto limpo, passando tanto o código quanto os padrões de codificação (push). O implementador pode consultar os padrões por pull quando necessário. 13. Padrões Push e Pull para Agentes Para garantir que os agentes sigam os padrões de codificação e estilos do projeto, o autor distingue dois mecanismos complementares. 13.1 Push - Instrução Proativa No padrão Push, você injeta informações diretamente no contexto do agente: • Colocar regras no Claude.md ou em arquivos de configuração • O agente sempre recebe essas instruções, independente da tarefa • Ideal para padrões críticos que nunca devem ser ignorados 13.2 Pull - Informação sob Demanda No padrão Pull, você disponibiliza informações que o agente pode consultar quando necessário: • Skills (habilidades) armazenadas no repositório com cabeçalho descritivo • O agente lê 'OK, agente, você pode puxar este arquivo quando precisar' • Reduz o tamanho do contexto inicial • Ideal para conhecimento especializado usado em contextos específicos Mecanismo Quando Usar Push Padrões críticos, regras de segurança, convenções sempre aplicáveis Pull (Skills) Conhecimento especializado, padrões de contexto específico 13.3 Aplicação em Code Review Para code review automatizado, a estratégia é: • PUSH os padrões de codificação para o agente revisor • PULL os padrões para o agente implementador (ele pode consultar se tiver dúvida) • O revisor precisa dos padrões ativamente; o implementador os consulta ocasionalmente 14. Sandcastle: Automação Avançada Para demonstrar a paralelização completa, o autor apresenta o Sandcastle, uma biblioteca TypeScript que ele desenvolveu para orquestrar agentes em paralelo. 14.1 O Problema que Sandcastle Resolve O autor não estava satisfeito com as opções existentes para executar agentes 'AFK'. Sandcastle oferece: • Função run() que cria uma work tree em uma branch Git • Sandbox em container Docker para cada agente • Execução de prompts dentro desse ambiente isolado • Paralelização simplificada de múltiplos agentes 14.2 Fluxo do Sandcastle O processo completo: • Um agente Planner analisa o backlog e escolhe tasks sem bloqueios mútuos • Para cada issue, cria um sandbox e executa um agente Implementer • Se commits foram criados, um agente Reviewer faz code review • Um agente Merger consolida as branches, resolvendo conflitos de tipos e testes 14.3 Modelo de IA por Função O autor usa modelos diferentes por tipo de tarefa: Função Modelo Implementação Claude Sonnet (rápido e eficiente) Code Review Claude Opus (maior capacidade de análise crítica) Repositório open source O autor disponibiliza o Sandcastle publicamente. Quem quiser aprofundar a paralelização de agentes pode consultar o código-fonte para aprender mais. 15. Princípios e Boas Práticas - Resumo Final O autor encerra com uma síntese dos principais aprendizados. Esta seção consolida todos os conceitos em princípios acionáveis. 15.1 Os 10 Princípios Fundamentais • 1. Conheça a Zona Inteligente Monitore o contador de tokens em toda sessão. Nunca deixe o contexto crescer ao ponto de entrar na zona burra. Limpe o contexto regularmente ao invés de compactar. • 2. Abrace o Esquecimento da IA Projete seu fluxo para funcionar com contexto sempre limpo. Isso é uma vantagem, não uma limitação: você sempre começa no melhor estado possível. • 3. Alinhe Antes de Implementar Nunca delegue código sem antes executar uma sessão de interrogatório (Grill Me). O custo do realinhamento depois é sempre maior do que o custo do alinhamento antes. • 4. Mantenha o Código em Mente Nem durante o planejamento você pode ignorar o código. Pense em módulos, interfaces e arquitetura desde o primeiro momento. • 5. Prefira Vertical Slices Cada issue deve resultar em algo visível e testável de ponta a ponta. Evite 'camadas de bolo' (horizontais) que só mostram resultado depois de muitas implementações. • 6. TDD é Inegociável A IA sem TDD tende a escrever testes ruins ou a trapacear. Com TDD, a ordem natural força melhores práticas e gera código que a IA pode verificar autonomamente. • 7. Melhore Seus Loops de Feedback A qualidade do seu código gerado por IA é limitada pela qualidade dos seus mecanismos de verificação. Invista em testes bons, type checking e verificações automáticas. • 8. Módulos Profundos, Não Rasos Oriente a IA a criar módulos com interfaces pequenas e muita funcionalidade interna. Projete as interfaces você mesmo; delegue as implementações. • 9. QA é Onde Você Impõe Seu Gosto Não tente automatizar tudo. A fase de QA é onde o julgamento humano, a experiência e o senso estético são aplicados. Sem isso, o resultado é 'slop'. • 10. Leia os Livros Clássicos A recomendação final do autor: compre e leia os livros clássicos de engenharia de software (Martin Fowler - Refactoring, The Pragmatic Programmer, A Philosophy of Software Design). Eles codificam práticas que funcionam igualmente bem com humanos e com IA. 15.2 O Fluxo Completo em uma Visão Etapa Responsável 1. Ideia inicial Humano 2. Grill Me (alinhamento) Humano + IA (interativo) 3. PRD (documento de destino) IA gera, Humano valida 4. Kanban (issues paralelas) IA gera, Humano valida 5. Implementação (Loop AFK) IA trabalha autonomamente 6. QA + Code Review Humano + IA (revisão) 7. Iteração (novas issues) Humano cria, ciclo repete Reflexão final do autor Este não é um compilador de especificações para código. Não é uma IA que simplesmente cospe código. É um processo intencional onde nos preocupamos com os módulos e com a forma do código-base. Usamos o interrogatório para garantir o máximo de alinhamento. Convertemos isso em issues paralelizáveis. Implementamos e fazemos QA e code review rigorosos, continuando a iterar. Referências e Recursos Livros Recomendados • Refactoring - Martin Fowler • The Pragmatic Programmer - David Thomas e Andrew Hunt • A Philosophy of Software Design - John Ousterhout Conceitos e Pessoas Mencionados • Dex Hardy (Human Layer) - conceito de Zona Inteligente / Zona Burra • Ralph Wiggum Loop - iteração contínua orientada a destino • John Ousterhout - módulos profundos vs. rasos Ferramentas e Recursos • Claude Code - ferramenta principal usada no workshop • Sandcastle - biblioteca TypeScript para paralelização de agentes (Matt Pocock) • AI Hero - site do autor com artigos e dicas adicionais • GitHub Issues / Kanban local - gestão de backlog para agentes
Ler dica
Como Saber se uma Bebida Contém Metanol: Testes e Perigos
O consumo de bebidas alcoólicas sem procedência confiável é um risco sério para a saúde. Um dos maiores perigos é a presença de metanol, também conhecido como álcool metílico. Diferente do etanol (álcool comum usado em bebidas), o metanol é extremamente tóxico: pequenas quantidades podem causar cegueira, insuficiência renal e até morte. Por que o metanol é perigoso? Quando ingerido, o metanol é metabolizado no fígado em formaldeído e ácido fórmico, substâncias altamente tóxicas para o sistema nervoso e a visão. Dose letal: cerca de 30 mL (menos de um cálice). Dose tóxica: até 10 mL já pode causar cegueira irreversível. Por isso, identificar a presença de metanol em bebidas adulteradas ou artesanais é uma medida fundamental de segurança. Principais métodos de detecção do metanol 1. Cromatografia Gasosa (GC) Método laboratorial mais preciso. Permite separar e quantificar diferentes compostos voláteis, distinguindo etanol de metanol. Usado em laboratórios de alimentos, saúde pública e fiscalização. Vantagem: alta precisão. Limitação: custo elevado e necessidade de equipamento especializado. 2. Cromatografia Líquida de Alta Eficiência (HPLC) Outra técnica laboratorial avançada. Funciona de forma semelhante à cromatografia gasosa, mas usando fase líquida. Vantagem: resultado confiável e detalhado. Limitação: também exige laboratório e técnicos especializados. 3. Testes Colorimétricos (Kits rápidos) Kits químicos que mudam de cor na presença de metanol. Usados em destilarias, universidades e até fiscalização de bebidas clandestinas. Funcionam a partir da reação do metanol com reagentes específicos (como dicromato ou permanganato). Exemplo: alguns kits utilizam a reação de iodoformo ou de ácido crômico. Vantagem: resultado rápido (minutos). Limitação: indicativo, não quantitativo. 4. Teste de Oxidação com Permanganato de Potássio O metanol é oxidado mais rapidamente que o etanol, formando formaldeído, que pode ser reconhecido pelo odor forte e irritante. Problema: envolve reagentes tóxicos e não deve ser feito em casa. 5. Teste da Chama Consiste em acender a bebida para observar a cor da chama. Metanol: queima com chama azul clara e quase invisível. Etanol: queima com chama azul mais brilhante com bordas amareladas. Limitação: pouco confiável, pois a diferença pode ser sutil e enganosa. Por que não confiar apenas em testes caseiros? Apesar de alguns testes improvisados circularem na internet, a maioria não é confiável e pode dar falsos negativos ou falsos positivos. A única forma 100% segura de confirmar a presença de metanol é através de análises laboratoriais oficiais. Como se proteger? Compre apenas de fontes confiáveis – evite bebidas de procedência duvidosa, sem rótulo ou sem registro no MAPA (Ministério da Agricultura, Pecuária e Abastecimento). Desconfie de preços muito baixos – adulteração geralmente visa reduzir custos. Não consuma bebidas artesanais desconhecidas – a destilação caseira sem controle pode gerar metanol. Em caso de suspeita de intoxicação – sintomas como visão turva, dor de cabeça intensa, náuseas e confusão mental exigem atendimento médico imediato. Conclusão O metanol é um veneno silencioso que pode estar presente em bebidas clandestinas. Existem diversos métodos para detectá-lo, como cromatografia gasosa, HPLC, testes colorimétricos e até observação da chama, mas apenas os métodos laboratoriais garantem segurança real. A melhor prevenção é simples: consumir apenas bebidas de procedência confiável. Afinal, uma economia momentânea pode custar a visão — ou a vida.
Ler dica
O que é o OPL e por que usá-lo
Open PS2 Loader (OPL) é um loader/homebrew para o PlayStation 2 que permite executar backups de jogos a partir de dispositivos externos como USB, HD interno (via adaptador de rede) ou via rede (SMB) — sem necessidade de usar discos originais. GitHub+2ConsoleMods+2 Ele suporta múltiplos modos de carregamento: USB Mass Storage (pendrive, HD externo) HDD interno conectado por meio de adaptor de rede (IDE ou SATA) Rede via SMB (compartilhamento de pastas no PC) Cartões SD via interfaces como MX4SIO Outros formatos (ex: iLink) GitHub+1 Vantagens de usar o OPL: Menos desgaste físico do leitor de discos. Carregamento mais rápido (dependendo do dispositivo). Organização de biblioteca com capas, nomes e configurações específicas de jogo. Facilidade de transportar sua coleção digital. Possibilidade de jogar mesmo se o leitor óptico estiver com falha. Requisitos e pré-requisitos Antes de começar, você vai precisar de alguns itens e condições: Hardware necessário Um PS2 (qualquer modelo, mas alguns modelos slim têm mais limitações). Um Memory Card compatível (geralmente oficial “Magic Gate”). Um dos seguintes dispositivos para armazenar os jogos: • Pendrive ou HD externo (USB) • HD interno via adaptador de rede (Network Adapter + HD IDE ou SATA) • Cartão SD com adaptador tipo MX4SIO (opcional) Para uso por rede via SMB: cabo de rede (Ethernet) conectado entre o PS2 e o PC/roteador. (Se necessário) computador para preparar os arquivos, dividir ISOs grandes, etc. Software / ferramentas necessárias OPL (arquivo ELF / bundle mais recente) — você pode obter da página oficial ou repositório do projeto. GitHub+1 uLaunchELF (gerenciador de arquivos / launcher) Ferramentas de formatação (por exemplo, formatação em FAT32 para dispositivos USB) Software de divisão de ISO para arquivos maiores que 4 GB (se necessário) OPL Manager (ferramenta auxiliar no PC para organizar jogos, capas, converter BIN → ISO, etc.) (Opcional) exploit como FreeMcBoot, FHDB, Fortuna ou método similar para permitir executar homebrew no PS2 Observações importantes Dispositivos USB ou externos maiores que 32 GB podem precisar de formatação especial ou utilitários. Jogos maiores que 4 GB normalmente precisam ser “divididos” em pedaços (split) para compatibilidade com FAT32. A compatibilidade de jogos varia; alguns títulos exigem configurações especiais no OPL (patches, modos específicos). O OPL deve ser “injetado” ou iniciado de alguma forma no PS2, seja via Memory Card com um exploit (FreeMcBoot / FHDB) ou via adaptador, conforme o modelo do console. Fluxo de instalação e configuração detalhada Aqui está um passo a passo aprofundado, com explicações adicionais: 1. Preparar o exploit / ambiente homebrew Se o seu PS2 ainda não roda homebrew, você precisa de um método para executar o OPL: FreeMcBoot (FMCB) é um dos métodos mais comuns: permite que você carregue aplicativos a partir do cartão de memória. Outros métodos: Free Hard Drive Boot (FHDB), Fortuna Project, FreeDVDBoot, etc. O método vai depender do modelo do PS2 (fat ou slim) e se ele já está desbloqueado. Após instalar o exploit, normalmente você terá um menu de inicialização ou opção para lançar o uLaunchELF ou diretamente o OPL. Uma vez que você tenha o ambiente homebrew ativo, você pode avançar para instalação de arquivos no Memory Card ou no dispositivo de armazenamento. 2. Instalar o OPL no Memory Card / adaptador interno Esse passo garante que o OPL fique acessível a partir do menu do PS2. Obtenha o arquivo OPL.ELF (ou versão equivalente) e a pasta de suporte OPL. Usando uLaunchELF, navegue até o dispositivo onde você armazenou os arquivos (pendrive, HD externo, etc.). Copie a pasta OPL para o root (raiz) do Memory Card (slot 0 / mc0). Se necessário, crie a pasta BOOT no mc0 e coloque um arquivo como BOOT.ELF que aponte para o OPL. Você pode configurar no menu do FreeMcBoot (ou equivalente) para que o OPL apareça automaticamente. Reinicie o console; o OPL deve aparecer como opção no menu ou via uLaunchELF. Este método garante que você não dependa de inserir pendrive toda vez para rodar o OPL. YouTube+2GGames+2 3. Preparar o dispositivo de jogos (USB / HD / rede) Aqui você prepara o dispositivo onde os ISOs (ou arquivos compatíveis) dos jogos ficarão. 3.1 USB / HD externo Formate o dispositivo em FAT32 (é o formato compatível mais comum). Se houver jogos maiores que 4 GB, você precisará “splitar” (dividir) usando ferramentas como USBUtil ou utilitários similares. Crie pastas padrão esperadas pelo OPL, como DVD, CD (se aplicável). Coloque os arquivos ISO (ou pastas do jogo) nas pastas corretas. Use OPL Manager para renomear, adicionar capas, configurar metadados (facilita visualização no PS2). Verifique se o OPL tem o modo USB ativado: no menu Settings → USB Device Start Mode (Manual / Auto). GitHub+1 3.2 HD interno via adaptador Instale um HD no PS2 usando o adaptador de rede (Network Adapter). O OPL suporta o formato de games utilizado pelo HD Loader, e também ISOs / ZSO no HD interno. GitHub+1 Transfira os jogos do PC para o HD via cabo IDE/SATA ou adaptador USB-IDE. Configure no OPL para detectar o dispositivo interno. 3.3 Rede via SMB No PC, crie uma pasta compartilhada via SMB contendo os jogos (ex: uma pasta “PS2Games”). Nas configurações de rede do OPL, você define o IP estático, endereço SMB, nome da pasta compartilhada, etc. ConsoleMods+1 No OPL, vá em Network Config e configure adequadamente os campos de rede. Se tudo estiver correto, o OPL vai listar os jogos presentes na pasta compartilhada. Algumas versões também permitem utilizar DHCP em vez de IP estático. YouTube 4. Primeira execução e ajustes no OPL Depois que o OPL for instalado e o dispositivo com jogos preparado: Inicie o OPL via menu ou usando uLaunchELF. No menu principal, selecione o modo de exibição (USB, HDD, SMB) conforme aplicação. Vá em Settings e ajuste: USB Device Start Mode (Auto ou Manual) Check USB fragmentation: deixar ligado evita problemas. Definir Default Menu para que inicie diretamente no modo de jogos desejado. Outras configurações como modo de vídeo, cheat codes, etc. GitHub+1 Em Save Changes, confirme as alterações. Volte ao menu principal → selecione a categoria de jogos (USB / HDD / SMB) → veja a lista de títulos. Escolha um jogo e execute. Se funcionar sem travar, ótimo! Se houver problema, talvez precise de ajustes por jogo (patches, modos “e” / “e + patch especial”). 5. Dicas avançadas e soluções de problemas Alguns jogos exigem modo especial de compatibilidade (usando patches no OPL). Se um jogo não aparece, verifique o nome do arquivo — ele deve estar no padrão esperado (p. ex. SLUS_123.45.GameName.iso). Ative a opção Check USB fragmentation para evitar falhas em dispositivos USB fragmentados. GitHub Se o dispositivo USB estiver “fragmentado”, a recomendação é: backup → formatar → restaurar (evite tentar defragmentar diretamente). GitHub Verifique se o console está configurado para usar o dispositivo correto (selecione modo USB / HDD / SMB). Em casos de PS2 “slim” ou modelos menos compatíveis, pode haver limitações (difícil detecção de HD interno, velocidades baixas por USB). Use a lista de compatibilidade do OPL (OPL-CL) para ver se o jogo tem exigências específicas. GitHub+1 Se o leitor óptico estiver danificado, use sempre o método externo (USB / HDD / rede). Em consoles sem leitor funcional, peça para alguém já configurar o Memory Card com o exploit / OPL e então leve para o seu PS2. Exemplo passo a passo (fluxo completo) Aqui está um exemplo simplificado de como alguém faria do zero: Prepare um Memory Card com FreeMcBoot. Baixe OPL e copie para um pendrive com o OPL Manager. Conecte o pendrive no PS2, use uLaunchELF para mover a pasta OPL ao mc0:/ do Memory Card. Configure o FreeMcBoot para exibir o OPL no menu inicial. No PC, formate um pendrive em FAT32 e copie jogos menores que 4 GB para DVD/ e jogos maiores divididos para DVD/ com método split. No OPL, ajuste USB Device Start Mode para AUTO. Salve configurações e acesse o menu de jogos USB. Carregue um jogo e teste. Para jogos com falha, tente forçar modo compatível no menu de configurações do jogo no OPL.
Ler dica
Veja 10 dicas de segurança para Windows 10 - preparando-se para o fim do suporte
O fim do suporte a uma versão do sistema operacional aumenta o risco de exposições a vulnerabilidades não corrigidas. Se você ainda utiliza Windows 10, é fundamental adotar medidas de proteção adicionais enquanto planeja a atualização para uma versão suportada. Abaixo estão 10 recomendações práticas e priorizadas para reforçar a segurança das máquinas com Windows 10. 1. Garanta atualizações críticas e mantenha o Windows atualizado enquanto possível Mesmo que o fim do suporte esteja próximo, instale todas as atualizações de segurança e cumulativas disponíveis. Configure o Windows Update para baixar e instalar atualizações automaticamente e verifique também atualizações de firmware e drivers fornecidos pelo fabricante do hardware. 2. Use uma solução antivírus/antimalware confiável e mantenha-a atualizada Ative o Microsoft Defender ou um antivírus comercial de confiança. Além da proteção tradicional, avalie soluções com EDR (Endpoint Detection and Response) que detectam comportamentos suspeitos e podem reduzir o impacto de ameaças não corrigidas. 3. Faça backups regulares e verifique a capacidade de restauração Estabeleça um plano de backup (local e offsite) e teste regularmente a restauração. Utilize imagens completas do sistema para recuperar rapidamente máquinas críticas e automatize snapshots quando possível. 4. Aplique políticas de menor privilégio e use contas de usuário padrão Evite operar rotineiramente com contas administrativas. Crie contas padrão para atividades diárias e mantenha uma conta de administrador separada para tarefas de manutenção. Isso reduz a superfície de ataque em caso de comprometimento. 5. Habilite e configure o Firewall do Windows e restrinja conexões de rede Use o firewall para bloquear tráfego desnecessário e aplique regras que limitem acesso a serviços sensíveis. Em ambientes corporativos, combine com segmentação de rede para isolar sistemas legados. 6. Proteja dados com criptografia (BitLocker) e políticas de senha fortes Ative BitLocker nas unidades sistemas sempre que possível para proteger dados em caso de perda ou roubo do dispositivo. Defina políticas de senha robustas e considere autenticação multifator (MFA) para contas que suportem essa tecnologia. 7. Desative serviços antigos e protocolos inseguros Revise serviços e protocolos legados (por exemplo, SMBv1) e desative-os se não forem necessários. Serviços antigos são alvos comuns de ataques; remova ou reduza permissões sempre que possível. 8. Controle aplicações e remova software desnecessário Remova aplicativos que não são utilizados e mantenha apenas softwares suportados e atualizados. Considere a aplicação de políticas de controle de execução (AppLocker, Windows Defender Application Control) para limitar quais programas podem ser executados. 9. Monitore e registre eventos de segurança Habilite logs e encaminhe eventos críticos para uma solução de SIEM ou central de logs. Monitoramento proativo aumenta a chance de detectar intrusões cedo e responder rapidamente. 10. Planeje a migração e estratégias compensatórias Elabore um plano de migração para um sistema suportado (por exemplo, Windows 11) priorizando ativos críticos. Enquanto a migração não ocorre, implemente controles compensatórios: segmentação de rede, regras de firewall, EDR, listas de bloqueio e restrições de acesso remoto. Passos imediatos recomendados (prioridade) Implemente backups semanais e valide a restauração. Instale ou atualize a solução antimalware e ative proteção em tempo real. Desative serviços/protocolos antigos (SMBv1, telnet) e aplique patches de firmware. Ative BitLocker e configure senhas fortes + MFA quando possível. Segmente a rede e limite o acesso remoto apenas a usuários autorizados. Boas práticas de usuário e treinamento Usuários bem informados reduzem riscos. Treine a equipe sobre phishing, links suspeitos, anexos e a importância de atualizar senhas. Estabeleça um canal claro para reportar possíveis incidentes de segurança. Perguntas frequentes (FAQ) O que acontece se eu continuar usando Windows 10 após o fim do suporte? Você ficará sem atualizações de segurança oficiais, o que aumenta a probabilidade de exposições a vulnerabilidades. Sistemas sem suporte exigem controles extras para mitigar riscos. Posso contratar suporte estendido? Em alguns casos, empresas oferecem opções de suporte estendido por tempo limitado. Avalie custos e compare com o esforço de migração para decidir a melhor alternativa. Quais sistemas eu devo priorizar para migrar primeiro? Priorize sistemas que armazenam dados sensíveis, máquinas expostas à internet, servidores e estações usadas por equipes críticas. Esses devem ser os primeiros a migrar ou a receber controles compensatórios rígidos. Conclusão Enquanto planeja a migração do Windows 10 para uma plataforma suportada, aplique as medidas descritas nesta lista para reduzir riscos. Atualizações, backups, antivírus, políticas de menor privilégio e monitoramento são pilares que aumentam a resiliência do ambiente. { "@context": "https://schema.org", "@type": "Article", "headline": "10 dicas de segurança para Windows 10 — preparando-se para o fim do suporte", "description": "Saiba 10 medidas práticas de segurança para proteger computadores com Windows 10 enquanto você planeja a migração. Proteção contra vulnerabilidades, backups, atualizações e recomendações para reduzir riscos após o fim do suporte.", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://suadica.com/dicas/seguranca-windows-10-fim-suporte" }, "author": { "@type": "Person", "name": "Flavio Cabral" }, "publisher": { "@type": "Organization", "name": "SuaDica", "logo": { "@type": "ImageObject", "url": "https://suadica.com/imagensgeral/logo.png" } }, "image": "https://suadica.com/imagensgeral/seguranca-windows10.jpg", "datePublished": "2025-09-22" } { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "O que significa o fim do suporte ao Windows 10?", "acceptedAnswer": { "@type": "Answer", "text": "Fim do suporte significa que a Microsoft deixará de publicar atualizações de segurança e correções para a versão. Sem essas atualizações, vulnerabilidades recém-descobertas podem não ser corrigidas." } }, { "@type": "Question", "name": "Posso continuar usando o Windows 10 com segurança?", "acceptedAnswer": { "@type": "Answer", "text": "É possível, mas o risco aumenta. Recomendamos aplicar medidas extras de proteção: usar antivírus atualizado, isolar máquinas críticas, realizar backups regulares e planejar a migração para um sistema suportado." } }, { "@type": "Question", "name": "Quais são as opções para usuários após o fim do suporte?", "acceptedAnswer": { "@type": "Answer", "text": "As opções incluem migrar para Windows 11 ou outra plataforma suportada, contratar suporte estendido (quando disponível) ou aplicar controles compensatórios como EDR, segmentação de rede e políticas restritivas." } } ] }
Ler dica
Como montar um NAS caseiro com Raspberry Pi Compute Module 5 e RAID-5 (Guia Completo)
Aprenda a montar um NAS DIY com Raspberry Pi Compute Module 5, OpenMediaVault e RAID-5 para armazenamento seguro e econômico.O armazenamento em rede (NAS) pode ser uma solução muito poderosa paraquem precisa guardar grandes volumes de dados com segurança, acessocompartilhado e redundância. Neste guia, mostramos passo a passo comoconstruir um NAS caseiro usando o Raspberry Pi Compute Module 5 junto deum adaptador NVMe‑para‑SATA, configurado em RAID‑5 com o softwareOpenMediaVault.------------------------------------------------------------------------Materiais necessáriosPara montar esse sistema, foi usado:1. Raspberry Pi Compute Module 5 (CM5) — módulo compacto com bom desempenho.2. Adaptador NVMe para SATA com chip ASM1166 — permite conectar vários discos SATA via interface NVMe.3. Rack ou suporte para HDDs em acrílico — para organizar fisicamente os discos.4. Cabo de alimentação SATA apropriado — juntamente com uma fonte DC de 12V, 7,5A, para alimentar os discos.5. Discos rígidos (HDDs) — múltiplos para formar o array RAID‑5.6. OpenMediaVault (OMV) — sistema operacional/software de gestão do NAS.------------------------------------------------------------------------Instalação do sistema operacional e configurações iniciais- Foi usado como base o Raspberry Pi OS Lite, versão leve adequada para rodar o OpenMediaVault.- Durante a instalação, surgiu um problema: o sistema não reconhecia os discos ligados via o adaptador ASM1166.- A solução foi compilar manualmente o driver necessário, garantindo a detecção dos HDDs.dtparam=pcie-32bit-dma-pi5 dtoverlay=pciex1-compat-pi5,no-mipApós esse ajuste, a instalação do OpenMediaVault pôde prosseguirnormalmente.------------------------------------------------------------------------Configurando o RAID‑51. Acesse o painel do OMV pela interface web.2. Vá até a seção de Armazenamento → RAID Management.3. Crie um novo array selecionando RAID‑5 e adicione os discos rígidos conectados.4. Após a sincronização, formate o array com um sistema de arquivos (por exemplo, EXT4).Esse processo cria um volume tolerante a falhas: se um dos discosapresentar defeito, os dados podem ser reconstruídos a partir dosdemais.------------------------------------------------------------------------Vantagens da solução- Baixo custo: aproveita hardware acessível como o Raspberry Pi CM5.- Escalabilidade: permite adicionar mais discos SATA.- Redundância: o RAID‑5 garante maior segurança em caso de falha de um HDD.- Flexibilidade: o OpenMediaVault traz recursos como compartilhamento de arquivos, integração com Docker e plugins adicionais.------------------------------------------------------------------------Considerações finaisCom poucos componentes e um pouco de paciência para compilar drivers econfigurar o sistema, é possível montar um NAS DIY robusto, econômico econfiável usando o Raspberry Pi Compute Module 5.Essa é uma alternativa interessante tanto para uso pessoal quanto parapequenas empresas que precisam de armazenamento seguro sem investir emsoluções proprietárias de alto custo.
Ler dica
ESP32-C3 Super Mini
O ESP32-C3 Super Mini é uma placa de desenvolvimento compacta com chip ESP32-C3 com Wi-Fi e Bluetooth integrados. Ao contrário de outros modelos de placas ESP32, este é um chip de núcleo único. Ele ocupa um espaço muito pequeno e é otimizado para baixo consumo de energia, consumindo apenas cerca de 43 μA no modo de espera profunda, de acordo com a ficha técnica. A placa possui 16 pinos, com 11 GPIOs programáveis que suportam ADC, PWM, UART, I2C e SPI.Inclui botões RST (reset) e BOOT. O botão BOOT é usado para colocar a placa no modo bootloader para carregar código, enquanto o botão RST redefine o board—useful para reiniciar e executar código recém-carregado.Aqui está um resumo do ESP32-C3 especificações técnicas:Processador: CPU RISC-V de 32 bits rodando até 160 MHzProtocolos IEEE 802.11b/g/n WiFi e Bluetooth 5 (LE)SRAM de 400 KB, ROM de 384 KB e flash 4M integradoAntena SMD compacta11 GPIOs que suportam as seguintes interfaces:4 pinos ADCPWMUARTI2CSPILED integrado no GPIO 8Botões de reinicialização e inicializaçãoConsumo de energia ultrabaixo: tão baixo quanto 43 uA no modo de sono profundoFator de forma pequenoVocê também pode dar uma olhada na tabela a seguir:Microcontrolador (processador)Espressif ESP32-C3 (32-RISC-V single-core, até 160 MHz)Memória Flash4 MB (flash SPI integrado)SRAM400 KBROM384 KBWi-Fi802,11 b/g/n, 2,4 GHz, até 150 MbpsBluetoothBluetooth 5.0 LEPinos GPIO11 GPIOs acessíveisEntradas analógicas (ADC)2 × ADCs SAR de 12 bits, até 6 canaisCanais PWM6 canaisSPI3 × Interfaces SPI (SPI0, SPI1 reservado)I2C1 × Interface I2CUART2 × Interfaces UARTI2S1 × Interface I2SInterface USBUSB-C, suporta USB CDCFonte de alimentação5 V via USB-C ou 3,3 V–6 V via pino VIN (5 V); regulador integrado de 3,3 V (até 500 mA)Tensão operacional3,3 V (nível lógico para GPIOs)Modo de sono profundo43uABotões1 × Botão de reinicialização, 1 × Botão de inicialização (GPIO9)LED1 × LED integrado (no GPIO8, ativo baixo)ProgramaçãoArduino IDE, ESP-IDF, MicroPython, PlatformIO/pioarduinoA imagem a seguir mostra a pinagem da placa ESP32-C3 Super Mini. Observe que a pinagem pode mudar ligeiramente dependendo do fabricante. Então, verifique novamente a pinagem com o mapeamento de pinos na serigrafia do seu quadro.A tabela a seguir descreve o mapeamento de pinos e suas funções.AlfineteFunção3V3Saída/entrada de 3,3 V (sai 3,3 V do regulador de bordo ou é uma entrada para fonte de alimentação externa de 3,3 V)5VEntrada/saída de 5 V (conecta-se à fonte USB-C 5 V ou externa 5 V)GNDPino GNDGPIO 0E/S de uso geral, ADC1, PWMGPIO 1E/S de uso geral, ADC1, PWMGPIO 2E/S de uso geral ADC1, pino de cintagem (modo de inicialização) (evitar para uso geral)GPIO 3E/S de uso geral, PWMGPIO 4E/S de uso geral, PWM, padrão SPI SCK alfineteGPIO 5E/S de uso geral, PWM, padrão MISO SCK alfineteGPIO 6E/S de uso geral, PWM, padrão SPI MOSI alfineteGPIO 7E/S de uso geral, PWM, padrão SPI SS alfineteGPIO 8Conectado ao LED integrado (ativo baixo); Pino de cintagem (evitar para uso geral);Padrão I2C SDA alfineteGPIO 9Conectado ao botão BOOT (LOW para entrar no bootloader), pino de amarração (evitar para uso geral)Padrão I2C SCL alfineteGPIO 10E/S de uso geral, PWMGPIO 20E/S de uso geral, PWM, padrão UART RX AlfineteGPIO 21E/S de uso geral, PWM, padrão UART TX Alfinete
Ler dica