/projects/ulbra-student-dashboard
← Todos os projetosStudent Dashboard
Uma tela na parede que diz aos alunos onde estar.
Head de Tecnologia — design & implementação · Abr 2026 – Atual
Visão geral
Um painel de horários instalado no prédio 1 da universidade, o da medicina, onde mostra aos alunos as aulas do dia. Um sistema com duas faces: um totem em tela cheia, desassistido, e uma administração protegida por login em que a equipe gerencia o conteúdo que ele alterna. Os dados acadêmicos vêm do lakehouse analítico da universidade.
O que eu fiz
Construí de ponta a ponta — a API, a integração com o lakehouse, os dois front-ends e o deploy.
- A conexão com o lakehouse que alimenta o horário.
- O painel do totem, sua rotação e seus temas de dia e noite.
- A administração de conteúdo e sua playlist agendada.
- O deploy no cluster interno.
O problema
Alunos chegando ao prédio não tinham como ver o horário do dia sem consultar o celular, e a universidade não tinha como colocar nada à frente deles no momento em que entravam. Uma folha impressa responde mal à primeira necessidade e não responde à segunda.
O que faz
- Um modo tela cheia dimensionado para o painel físico em que roda, não para uma janela de navegador.
- Alterna entre páginas de horário e conteúdo do campus numa cadência fixa.
- Troca entre tema diurno e noturno pelo relógio, para ser legível nos dois.
- A equipe agenda conteúdo com data de início e fim; ele aparece e expira sozinho.
Decisões de engenharia
Polling, não conexão persistente
O painel pede dados novos ao servidor em intervalos curtos em vez de manter um socket aberto. Socket é a melhor resposta quando há alguém olhando e a latência importa; aqui é uma tela na parede sem ninguém à frente. O polling se recupera sozinho de uma queda de rede, e ninguém precisa ir até o prédio reiniciar nada.
O lakehouse analítico como fonte
O horário é lido da plataforma analítica da universidade e não do sistema acadêmico diretamente. É a cópia já modelada para leitura, que já tem controle de acesso concedível de forma restrita ao painel e que — o ponto decisivo — não é afetada por uma tela no saguão consultando o dia inteiro.
Um sistema, dois públicos
O totem não tem login nem interação; a administração tem os dois. Separá-los em dois deploys era o movimento óbvio e foi descartado: eles compartilham inteiramente o modelo de conteúdo, e dois serviços significariam dois lugares para mudar quando o formato de um slide mudasse. A fronteira é uma rota e uma verificação de acesso, não um processo.