Biblioteca Virtual: meu TCC, dois anos depois
Um sistema de biblioteca em Django, feito no técnico em 2024. Ele ensina mais pelos erros que ficaram no repositório do que pelo que funcionava.
- Publicado
- há 21 horas
- Atualizado
- há 20 horas
- Assunto
- Python, Django, Segurança
- Obra
- Ver o código (abre em nova aba)
A Biblioteca Virtual foi o Trabalho de Conclusão de Curso do Ensino Médio Técnico em Informática para Internet, entregue em novembro de 2024 na Escola Estadual Prof. Luiz Simione Sobrinho. Foi trabalho de grupo, com Caio Cardoso Silva, Gabriel Medeiros e Heloisa Teodozio.
É um sistema de acervo em Django: cadastro de livro, autor, gênero e idioma, cada exemplar com status de empréstimo, login de usuário e uma área de bibliotecário que renova prazo. Banco em SQLite, templates em HTML, um pouco de CSS próprio.
A parte honesta primeiro
O projeto foi construído em cima do tutorial LocalLibrary da MDN, o guia de
Django da Mozilla. Dá para ver no código sem esforço: a pasta do projeto se
chama locallibrary, os modelos são Book, BookInstance, Author, Genre,
e o campo de falecimento do autor está escrito exatamente como no tutorial,
models.DateField('died').
Digo isso de saída porque é o contrário de demérito. Primeiro contato com framework web seguindo um tutorial bom é como quase todo mundo aprende, e esconder isso é que seria estranho num site que tem “o que não deu certo entra com a mesma ficha” escrito na entrada.
O que o grupo acrescentou por cima: o modelo de Language, que é um exercício
proposto no fim do tutorial e não vem pronto, o índice reescrito, o CSS e a
identidade da escola.
O que ele ensinou
ORM e migração. São cinco arquivos de migração no repositório, e eles contam a evolução do modelo: a primeira cria o esqueleto, a segunda troca o modelo de exemplo pelos quatro de verdade, a terceira adiciona o campo de quem pegou o livro emprestado, a quarta mexe na ordenação, a quinta introduz idioma. Ler essa sequência é ler o projeto sendo pensado.
Modelagem de verdade. A ideia central do sistema é a diferença entre
Book e BookInstance: o livro é a obra, a instância é o exemplar físico na
prateleira. A biblioteca tem um “Dom Casmurro”, mas três cópias, e só uma está
emprestada. Quem nunca modelou isso acha que livro é uma tabela só, e essa
distinção é a primeira aula de modelagem que presta.
Permissão, não só login. Tem tela de login, recuperação de senha e uma área que só bibliotecário acessa. É diferente de “tem usuário logado”: é usuário com papel.
O que eu faria diferente hoje
Aqui está o motivo real deste texto. Revisitei o repositório em agosto de 2026 e achei quatro coisas que hoje eu não deixaria passar.
A chave secreta do Django está no repositório. O SECRET_KEY do
settings.py foi commitado junto com o resto, em repositório público. No caso
específico o estrago é pequeno: é a chave de desenvolvimento que o próprio
Django gera com prefixo django-insecure-, o projeto tem DEBUG = True e
ALLOWED_HOSTS vazio, ou seja, nunca foi para produção. Mas a lição vale
inteira: chave vai para variável de ambiente, não para o commit, e o
histórico do git é permanente.
O banco de dados foi commitado. Tem um db.sqlite3 de 245 KB no
repositório. Banco de desenvolvimento não entra em git: ele muda toda hora,
suja o histórico e, dependendo do que tem dentro, publica dado de gente que
não pediu para ser publicado.
Arquivo compilado no repositório. As pastas __pycache__ estão todas lá.
São artefatos que o Python gera sozinho e que um .gitignore de três linhas
resolveria.
Uma pasta chamada catalog - Copia. Ficou uma cópia inteira dos templates,
com o nome que o Windows dá quando alguém aperta Ctrl+C e Ctrl+V. É o backup
manual de quem ainda não confia no controle de versão, e é justamente o que o
git existe para tornar desnecessário.
O que eu fiz a respeito
Escrever tudo isso e deixar como estava seria estranho, então limpei o repositório.
O banco, os __pycache__ e a pasta duplicada saíram do histórico inteiro,
não só do estado atual. Essa distinção é o ponto: tirar um arquivo num commit
novo não tira ele do passado, e no git o passado continua baixável por qualquer
um. A chave passou a vir de variável de ambiente. Entraram um .gitignore, um
requirements.txt com a versão do Django da entrega e um README explicando
como rodar o projeto do zero, já que sem banco versionado é preciso criar um.
O código de 2024 não mudou uma linha. Comparei arquivo por arquivo, antes e depois: os 58 arquivos batem, e a única diferença em todo o repositório é a linha da chave.
E sobrou uma curiosidade que eu não esperava. O repositório tinha dois commits.
Quando o banco saiu do histórico, o segundo virou vazio: a única coisa que ele
mudava era o db.sqlite3, que engordou 4 KB porque alguém abriu o sistema e
clicou em algumas telas. Meses de trabalho couberam em um commit só, e o outro
era o banco crescendo.
Por que isso está aqui
Nenhum desses quatro erros aparece no site rodando. O sistema funciona, a banca aprovou, o curso terminou.
Eles apareciam quando alguém abria o repositório, que é exatamente o que um recrutador faz. E eu só enxerguei os quatro porque hoje sei o que procurar, o que dois anos atrás eu não sabia.
É por isso que este projeto continua na coleção em vez de ser apagado. A distância entre o que eu fiz em 2024 e o que eu enxergo em 2026 é a informação mais útil que essa pasta guarda.