Pitch: Construí uma plataforma para ensinar programação pelo celular, com Python, SQL e Flask rodando no navegador

Sou professor de um curso técnico de Desenvolvimento de Sistemas em uma escola pública do Piauí. Neste texto conto o que construí, como funciona por dentro, o que deu errado e o que vem agora, porque também estou começando uma pesquisa sobre isso.

O problema

Nas primeiras semanas de aula, percebi que o maior obstáculo de muitos alunos não era a lógica de programação. Era ter acesso a um computador com Python, um editor e um navegador de desenvolvimento configurados. Quase todos têm celular. Também não queria que os projetos ficassem presos em um aparelho: aluno troca de celular, perde arquivo, usa o computador do laboratório de vez em quando.

O que ela faz

É uma aplicação web que funciona no celular. O aluno cria projetos de Python, SQL, HTML/CSS/JS ou Flask, escreve e roda o código direto no navegador, e tudo fica salvo online. O professor cria atividades, acompanha as entregas e corrige.

A regra que guiou o projeto

Código de aluno nunca roda no servidor. Tudo executa no navegador de quem escreveu, e o servidor só guarda arquivos. Isso simplificou a segurança e permitiu usar hospedagem gratuita (Render e Neon), mas trouxe os problemas mais interessantes.

Stack

Flask, psycopg com SQL puro (sem ORM) e HTML, CSS e JavaScript puros, sem framework de front-end. Escolhi isso de propósito: o código também é material de ensino, e quanto menos camadas, mais fácil de ler. O editor usa CodeMirror empacotado localmente.

Python no navegador (Pyodide) e o input()

• O Pyodide 314 exige worker do tipo módulo. Com worker clássico, o erro que aparece é um "NetworkError" enganoso. O erro real fica escondido porque o script vem de outra origem.
• O input() precisa bloquear a execução enquanto o aluno digita, e isso exige SharedArrayBuffer, que só funciona em páginas com isolamento (COOP/COEP). Como isso quebra imagens externas em prévias de HTML, só as páginas de Python são isoladas.
• Depois de carregar o Python, o worker apaga fetch e XMLHttpRequest. Assim, o código de um aluno, quando aberto pelo professor, não age com o login do professor.

O Flask que roda no navegador

Para ensinar servidores, queria que o aluno rodasse um app Flask sem hospedar nada. O Pyodide não traz Flask, mas as rodas de Python puro (flask, werkzeug, itsdangerous, blinker) são pequenas, uns 357 KB. Elas ficam no próprio site e carregam antes de a rede ser trancada. O app do aluno roda em um worker, e Flask.run é trocado por um laço que espera pedidos da página e os atende com o test_client. Uma barra de endereço e um iframe isolado formam um "navegador de mentira" que mostra as páginas, intercepta links e formulários e mostra no terminal o registro dos pedidos. Templates, static/ e SQLite funcionam de verdade.

Limite: não é um servidor de verdade. Não há endereço público, e o banco recomeça a cada execução. A ideia é ensinar o conceito e depois publicar de verdade.

Edição em grupo

Alunos editam o mesmo projeto ao mesmo tempo. Cada salvamento manda o texto atual e a "base" (o texto do servidor com o qual a tela concorda), e o servidor mescla por linhas, como o Git. Mudanças em partes diferentes entram as duas. Se duas pessoas mexem no mesmo trecho, nada se perde: as duas versões ficam no arquivo entre marcas de conflito, e o navegador avisa. Resolver conflito virou parte da aula.

O histórico de versões guarda um estado a cada salvamento com mudança real e deixa voltar o projeto inteiro ou só um arquivo. Voltar não apaga nada: vira uma nova versão.

Testes sem entregar a resposta

O professor cadastra testes com entrada e saída esperada. O aluno toca em "Testar" e vê "3 de 5 passaram". A resposta esperada nunca chega ao navegador do aluno: o servidor manda só o hash SHA-256 da saída normalizada, e o navegador compara. Em testes de SQL, compara-se o resultado da última consulta. O teste roda no navegador, com tempo limite para laço infinito.

O resultado vai junto com a entrega, mas é informado pelo navegador do aluno e pode ser adulterado, então o professor pode rodar os testes de novo. Não vale nota automática.

O lado do professor

Atividades com prazo, entrega com versões, correção com comentário e botão para ir direto para a próxima entrega.

O que deu trabalho

• Hospedagem gratuita: 512 MB de RAM e banco que suspende depois de 5 minutos parado. O primeiro acesso depois de um tempo é lento.
• Celular: teclado cobrindo botões, zoom automático no iPhone com fonte menor que 16 px e altura do editor seguindo o visualViewport.
• Pyodide em celulares fracos: bibliotecas grandes (matplotlib passa de 10 MB) pesam na primeira vez.

A pesquisa

Isso marca também o início de uma pesquisa livre, sem vínculo formal. A primeira fase é entender, com os alunos, quais dificuldades eles enfrentam ao aprender programação (acesso, lógica, motivação, inglês, mensagens de erro) e se uma ferramenta pensada para o celular ajuda a incluir quem tem menos acesso à tecnologia. A pesquisa mede isso, e não parte do pressuposto de que ajuda. Ainda não tenho resultados. Quero compartilhar o caminho, e os dados dos alunos nunca serão publicados de forma identificável.

Peço ajuda

• Se você ensina programação: o que seus alunos mais travam? Faria diferente algo do que descrevi?
• Se você pesquisa informática na educação: que leituras e cuidados você recomenda?
• Se você é dev: encontrou furo de segurança na ideia de rodar tudo no navegador?

Comentários, críticas e sugestões são muito bem-vindos.