/projects/ulbra-student-dashboard

← Todos os projetos

Student Dashboard

Uma tela na parede que diz aos alunos onde estar.

Head de Tecnologia — design & implementação · Abr 2026 – Atual

.NET 10React 19PostgreSQLMicrosoft FabricODBCDocker Swarm
Privado

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.