DEV Community: Davi Max

20 anos entre consertar computador e dar aula sobre eles

Davi Max — Wed, 16 Sep 2026 00:09:07 +0000

Comecei a trabalhar com tecnologia em 2003, consertando computadores e dando suporte a sistemas de loja em uma fábrica de calçados. Vinte e dois anos depois, sou professor de Ensino Superior e ainda escrevo código todo fim de semana. Entre um ponto e outro, a trajetória não foi nada linear — e acho que é exatamente por isso que vale contar.

O começo: hardware, não software

Meus primeiros anos em TI foram quase inteiramente técnicos, no sentido mais literal: manutenção de impressoras e micros, instalação de softwares empresariais, suporte por telefone e no balcão. Passei por uma fábrica de calçados, uma revenda de informática e, depois, virei gerente de suporte técnico em uma consultoria.

Nenhum desses trabalhos envolvia "programação" no sentido que ensino hoje em sala. Mas envolvia algo que continua sendo a base de tudo: entender por que um sistema quebrou, com pouca informação e alguém esperando a solução na hora.

A virada: voltar a estudar sem parar de trabalhar

Em paralelo a esses anos de suporte, nunca parei de estudar. Informática Empresarial e Comercial, depois Licenciatura em Informática, depois — já como professor — uma sequência de especializações que não parou mais: Mídias na Educação, Engenharia de Software com Métodos Ágeis, Gestão de Projetos, e por fim um Mestrado, cuja pesquisa resultou em um software protótipo de verdade para auditoria de dados clínicos.

Se tem um padrão nessa lista, é este: nunca escolhi entre "ser professor" e "continuar técnico". Fui empilhando os dois ao mesmo tempo, mesmo quando isso significava estudar depois do expediente por anos seguidos.

Hoje: professor que ainda quebra a cabeça com código

O que acho mais interessante nessa trajetória, olhando para trás, é que ela não terminou quando virei professor. Ainda desenvolvo sistemas — alguns para projetos de extensão da universidade, outros só para resolver problemas meus mesmo, como gerenciar minhas próprias turmas e notas.

Ensinar sem continuar praticando me parece um risco silencioso: o conteúdo pode ficar desatualizado sem que ninguém perceba, nem o professor. Continuar construindo software de verdade é, para mim, a forma mais honesta de saber se o que estou ensinando ainda faz sentido no mundo real.

Vinte anos depois do primeiro chamado de suporte técnico, a pergunta que mais uso em sala ainda é a mesma de quando eu tinha 22 anos consertando computador: "o que exatamente está acontecendo aqui, e por quê?"

Por que a primeira função de IA que construí não foi um chatbot

Davi Max — Wed, 16 Sep 2026 00:07:32 +0000

Quando decidi colocar IA generativa dentro do leanpulse, tinha uma lista de possibilidades óbvias — chatbot de dúvidas, resumo automático de frequência, previsão de desempenho. Escolhi nenhuma delas. Integrei o Google Gemini para ajudar professores a criar provas e atividades.

A escolha não foi por ser a ideia mais impressionante tecnicamente. Foi por ser a que resolve a dor que eu mesmo sinto toda semana.

O problema não é falta de conteúdo, é tempo

Montar uma prova boa não é o mesmo que montar uma prova rápida. Escrever questões que realmente avaliam o que foi ensinado, variar o formato, calibrar a dificuldade — isso consome um tempo que, na correria de um semestre com várias turmas, quase nunca sobra do jeito que deveria.

Foi esse o problema que quis atacar: não gerar conteúdo pedagógico do zero sem critério, mas dar ao professor um ponto de partida sólido para revisar, em vez de partir da folha em branco.

Como a funcionalidade funciona, na prática

O professor descreve o que precisa — o tema, o formato desejado, o nível da turma — e o Gemini gera uma sugestão de prova ou atividade a partir disso. A palavra que mais importa aí é sugestão: o conteúdo gerado não vai direto para o aluno. Ele entra em uma tela de revisão, onde o professor ajusta o que quiser antes de efetivamente aplicar.

Essa decisão de design não foi acidental. Escrevi, há pouco tempo, sobre como uso IA para preparar minhas próprias aulas — e o princípio que defendo ali é o mesmo que apliquei aqui como funcionalidade: a IA acelera a produção, mas a responsabilidade pelo que chega ao aluno continua sendo do professor. Não faria sentido construir uma ferramenta que pedisse de mim, como usuário, menos cuidado do que eu mesmo pratico.

O que aprendi integrando IA generativa de verdade

Tecnicamente, a parte mais delicada não foi "chamar a API do Gemini" — isso é relativamente direto. Foi desenhar a interface para que o resultado gerado nunca parecesse definitivo. Cada sugestão vem claramente marcada como rascunho, com espaço de edição em destaque, não escondido atrás de mais um clique.

Se existe uma lição que levo desse recurso para qualquer projeto futuro com IA generativa, é essa: a parte difícil raramente é fazer a IA gerar algo. É desenhar o produto para que ninguém confunda "gerado por IA" com "pronto para usar".

ProfessorOS

Davi Max — Tue, 15 Sep 2026 23:59:30 +0000

Quando comecei a construir o ProfessorOS — um sistema pessoal para gerenciar minhas turmas, notas e frequência — cheguei ao ponto que todo projeto com login enfrenta: como fazer a autenticação.

A resposta mais rápida seria instalar uma biblioteca pronta e seguir em frente. Decidi não fazer isso. Não por implicância com bibliotecas, mas porque autenticação é exatamente o tipo de coisa que, se você nunca entendeu por dentro, vira uma caixa-preta que você só reza para estar configurada certo. Preferi construir a minha, entender cada decisão, e só então confiar nela.

Aqui está o que ficou de pé no final.

Senha não se guarda, se transforma

A primeira decisão é a mais óbvia, mas vale reforçar: senha em texto puro no banco de dados não é opção, nem por um segundo. Uso bcrypt, que não é só um algoritmo de hash — é um hash deliberadamente lento.

Isso é intencional. Um hash rápido (como MD5 ou SHA-256 sozinho) permite que um invasor teste bilhões de combinações por segundo se o banco vazar. O bcrypt inclui um "custo" configurável que torna cada tentativa mais cara computacionalmente — lento o suficiente para não incomodar um login legítimo, e caro o suficiente para inviabilizar um ataque de força bruta em escala.

Um cookie que não pode ser falsificado

Depois do login, o sistema precisa lembrar quem você é nas próximas requisições. A forma mais simples seria guardar um ID de sessão em um cookie e comparar com o banco a cada requisição.

Fui um passo além: o cookie de sessão é assinado com HMAC-SHA256. Na prática, isso significa que o conteúdo do cookie carrega uma "assinatura" matemática gerada com uma chave secreta que só o servidor conhece. Se alguém tentar alterar o conteúdo do cookie manualmente — trocar o ID de usuário, por exemplo — a assinatura não bate mais, e o servidor rejeita a sessão na hora.

O cookie também é httpOnly, o que impede que ele seja lido por JavaScript no navegador — uma proteção direta contra ataques de XSS tentando roubar a sessão.

Duas camadas de verificação, não uma

Essa foi a parte que mais me fez repensar o próprio desenho do sistema. Segui um padrão recomendado pela própria documentação do Next.js: verificar a sessão em dois lugares diferentes, com propósitos diferentes.

Uma verificação otimista, na borda (proxy.ts), que só confere se existe um cookie com formato válido — rápida, usada para decidir se redireciona o usuário para a tela de login antes mesmo de carregar a página.
Uma verificação definitiva, na camada de acesso a dados (auth.ts), que valida a assinatura do cookie de verdade e confere permissões — essa é a que decide se uma ação sensível (ver notas de um aluno, editar uma turma) realmente acontece.

A lógica é simples: a primeira camada existe para dar uma resposta rápida ao usuário; a segunda existe porque a primeira, sozinha, nunca deveria ser a única linha de defesa.

Limitando tentativas de login

Por fim, um limite de tentativas: 5 tentativas de login a cada 15 minutos por IP, com um teto global de 30 tentativas no sistema todo. Sem isso, toda a engenharia de hash e assinatura acima ainda deixaria uma porta aberta para um ataque simples de tentativa e erro repetido.

O que fica disso

Nenhuma dessas quatro peças é complexa isoladamente. O que exige cuidado é a soma delas — e entender por que cada uma existe, não só copiar um trecho de código que "funciona".

Como professor, isso mudou até a forma como falo sobre segurança em sala: não como uma lista de boas práticas para decorar, mas como um conjunto de perguntas — o que essa camada impede, especificamente, que aconteça? Se a resposta não é clara, a camada provavelmente não deveria estar ali só por estar.

Passei dias quebrando o Git de propósito — e aprendi mais que em anos de uso

Davi Max — Tue, 15 Sep 2026 23:54:23 +0000

Sou professor de Análise e Desenvolvimento de Sistemas, estou há mais de 20 anos na área de TI, e recentemente preparei um módulo inteiro de Git e GitHub para minha turma. Parecia simples: eu já uso Git há anos, é só passar o conteúdo adiante.

Não foi bem assim.

Decidi rodar, no meu próprio terminal, cada comando que ia ensinar — e, de propósito, provocar os erros que sabia que a turma ia encontrar, só para saber exatamente como explicar cada um quando acontecesse em aula. O resultado foi uma quantidade generosa de mensagens de erro na minha tela, e alguns aprendizados que valem compartilhar.

A tela que trava todo mundo na primeira vez

Rodei git commit sem o -m, e o terminal simplesmente... parou. Sem prompt, sem resposta ao Enter, parecia travado.

Era o Vim, o editor de texto padrão do Git, esperando a mensagem do commit. A saída: i para editar, digitar a mensagem, Esc, :wq e Enter.

Não é um bug. É só um editor que ninguém avisou que ia abrir.

As três fases de um merge que ninguém te conta

Essa foi a que mais me ensinou. Tentei mesclar um branch com conflito de propósito, e fui evoluindo por três erros diferentes, cada um revelando uma parte do que o Git realmente faz internamente:

Fase 1 — conflito aberto. O Git marca o arquivo com <<<<<<<, ======= e >>>>>>>, e recusa qualquer merge novo enquanto isso não for resolvido.

Fase 2 — resolvido, mas sem commit. Depois de editar o arquivo e dar git add, tentei um novo merge e levei um fatal: You have not concluded your merge (MERGE_HEAD exists). O conflito já tinha sumido do arquivo, mas o Git ainda guardava uma referência interna (MERGE_HEAD) esperando o git commit final.

Fase 3 — concluído. Só depois do commit é que o merge realmente termina, e o próximo pode começar.

Até então, eu explicava merge como "um comando só". Agora sei que é um processo de três estados — e faz muito mais sentido assim, tanto pra mim quanto pra quem está aprendendo.

Clonar um repositório dentro do outro

Esse eu fiz sem querer, mas ficou de exemplo. Rodei git clone de dentro da pasta de outro repositório, e o Git avisou: "adding embedded git repository".

Cada pasta .git é uma unidade independente — clonar um projeto dentro de outro cria uma espécie de repositório dentro do repositório, que quebra assim que alguém tenta clonar o de fora. Resolvido com git rm --cached e movendo a pasta para o lugar certo.

Por que valeu a pena

Hoje esses mesmos comandos — branch, merge, commit, resolução de conflito — são parte do dia a dia de projetos reais que venho construindo, incluindo sistemas com autenticação própria, testes automatizados e até integração com IA generativa.

Mas o que fica desse processo não foi só prática técnica. Foi perceber que entender os erros — de propósito, sem pressa, antes de precisar explicar pra alguém — é provavelmente a forma mais rápida de aprender qualquer ferramenta de verdade.

Se você está começando com Git agora: os erros que você vai encontrar não são sinal de que está fazendo errado. São, muito provavelmente, os mesmos que todo mundo encontra — inclusive quem está do outro lado, ensinando.