dia 3 - projeto Estudo Eficiente · allbertuu

esse é um projeto que estou criando em público, pelo prazer de retomar as discussões técnicas do passado que hoje se perderam. por isso, pode com certeza comentar, dizer o que acha, e o que você faria melhor se fosse eu. valeu!

Não consegui colocar imagens aqui!! Veja o post no In: https://www.linkedin.com/posts/albertov-albuquerque_dia-3-com-as-funcionalidades-definidas-e-ugcPost-7486156848170164224-7bkz/?utm_source=share&utm_medium=member_desktop&rcm=ACoAADcUr88B0Lh2LWHvq6TlcOiCuL4UZ98zwbo

para os outros dias, veja:

com as funcionalidades definidas e a lógica do ponto de vista do usuário lapidada, hora de modelar tecnicamente a primeira funcionalidade do sistema: Sessão de Estudo (iniciar ou pular).

a primeira grande definição nesse começo foi de que as informações da sessão de estudos devem persistir, num banco de dados por exemplo, sendo possível abrir a plataforma em qualquer outro dispositivo e encontrar tudo atualizado. isso é importante porquê cria minha primeira restrição/trade-off, já que trago os problemas dessa implementação para o app, que poderia operar offline, ou com outra abordagem, e tudo bem. o importante é saber exatamente o que eu deixo na mesa, e seguir. somos devs.

como a dinâmica é de ciclo de estudos, defini que no banco de dados vou seguir uma estrutura de Fila circular, e não sequencial (tem fim). funciona assim: ao finalizar a disciplina de ordem “N”, a próxima será a “N + 1”. Se “N” for a última da lista, o sistema volta para a ordem “1”. essa vai ser a lógica de passagem de disciplina.

e isso me permitiu montar as primeiras tabelas (nas imagens abaixo).

note que, na lógica do app, as disciplinas são entidades quase estáticas, no sentido de que a sessão de estudo que brinca com elas. é como se a sessão de estudo fosse uma caixa vazia, onde eu insiro a disciplina que estou estudando, e depois que terminei eu insiro a próxima da lista. isso é fundamental pra entender (de fato) as responsabilidades entre essas duas entidades, e evitar modificar desnecessariamente qualquer uma delas por erro de modelagem. um exemplo disso é em qual delas coloco o tipo_sessao - falo mais abaixo.

e isso tudo porquê pular uma sessão de estudos deve levar para a próxima, ou a mesma, na lista de disciplinas, pois cada disciplina se repete 2 vezes nessa lista. calma, não vou criar redundância. explico depois.

enfim, hora de mapear os estados para tornar tudo mais divertido (claro que não).

o principal fator de troca de disciplina é saber o tipo da sessão (dentro da sessoes_estudo), e como lidar a partir dela, por isso começamos com ela:

Se eu verifico que a última sessão salva foi do tipo ‘ENTENDIMENTO’, a nova sessão terá um novo ID, a mesma disciplina_id, o status retoma para NAO_INICIADA, a hora de início e término são removidas/resetadas, e o tipo_sessao passa para ‘PRATICA’
Se eu verifico que a última sessão salva foi do tipo ‘PRATICA’, a nova sessão terá um novo ID, passará para a próxima disciplina_id com base na ordem da tabela DISCIPLINA, o status retoma para NAO_INICIADA, a hora de início e término são removidas/resetadas, e o tipo_sessao passa para ‘ENTENDIMENTO’

dessa forma eu consigo montar um histórico de sessões de estudo, com cada registro na sessao_estudos.

e aí, acha coerente? já implementou um sistema que obedece uma ordem/fila para registrar novos registros? o que deu certo, o que deu errado? me conta ai que eu adoraria saber

também queria saber o que vocês acham de nomes em português para ENUM. isso pode prejudicar traduzir a plataforma para qualquer idioma, né. já que as informações salvas em código são em português.

bom, essas foram algumas das decisões técnicas que tomei hoje.

até logo!