Adicionar endpoint que gera horários

[danielmitre]

Criei uma API horarinator pra ajudar a criar horários (interface gráfica em andamento) e proponho adicionar esse endpoint ao projeto do laguinho.

Caso rejeitado (ou talvez até mesmo aprovado), gostaria de adicionar meu repositório na lista de repositórios abertos de CC@UFCG.

Caso aceita a proposta, posso fazer a adaptação da API para um endpoint do laguinho.

[JoseRenan]

Dei uma olhada no repositório, seria mto bom ter um endpoint aqui no laguinho que servisse os horários de CC de cada período, tipo, 2019.1 foram orfertadas essas disciplinas com esses horários, com esse csv do teu repo. algo como /v1/schedule/2019/1 e continuariamos fazendo isso pros próximos tbm. Seria mto top top

[JoseRenan]

gostaria de adicionar meu repositório na lista de repositórios abertos de CC@UFCG.

Pode fazer um PR adicionando aqui esse e outros repositórios que tu quiser divulgar no @OpenDevUFCG/issueai !!!

[JoseRenan]

Sobre criar o endpoint com a lógica do horarinator, talvez seja melhor ter um projeto específico pra isso (no caso o teu mesmo) porque é uma lógica muito específica 🤔 o que vcs acham?? @thayannevls @danielmitre @JuanBarros2

[thayannevls]

Ter os dados de horários dos períodos seria muito bom!
E também acho que a parte de criar horários pode ser algo a parte, talvez pudéssemos nos ajudar e o seu projeto @danielmitre usar os dados daqui mas fazer a lógica de horários por lá, o que acha? Se tiver outra sugestão pode falar

[JuanBarros2]

seria massa demais isso aí, inclusive era uma das ideias que a gente tinha pra o futuro do roadmap

[danielmitre]

Gostei da discursão que foi iniciada nessa issue e no gitter. Como nenhuma decisão foi tomada e vi uma divergência de ideias na comunidade, tomei a liberdade de agregar os prós e contras citados por vocês e adicionar alguns próprios.

Matérias processadas

Adicionar como endpoint as matérias processadas do .csv.

• Prós:
  • Uso geral para outras ferramentas ligadas ao curso
  • Pode ser usado pelo próprio horarinator para facilitar/automatizar seu uso
• Contras:
  • Por ser tão genérico, carece de informações que possam fazer realmente útil
  • Pelo tratamento se dar pelo .csv, é necessário fazer algo com as matérias que não apareceram no semestre (não é algo crítico, mas um dos principais usos para essa API seria capturar as matérias contidas no curso)
• Sugestões:
  • Encontrar mais informações que possam ser agregadas posteriormente nessa API
  • Processar manualmente as matérias, juntando todas em um json e adicionando seu nome oficial para que os consumidores da API possam exibir um nome mais user friendly e que possam ter uma lista mais completa de todas as matérias

Criador de horários

Adicionar como endpoint o algoritmo que lista os possíveis horários a partir das matérias/turmas escolhidas.

• Prós:
  • Tem um uso concreto que perdurará enquanto existirem os pijamas
  • Seu uso (com auxílio de uma interface) imediatamente se torna interessante até para usuários que não estão interessados em desenvolver nada sobre isso
• Contras:
  • Por ser muito específico, poucas coisas podem se criar em volta disso
  • Lógica específica (mas nem tanto assim, pois é um brute-force)
  • Um problema de implementação pode ser prejudicial e difícil de identificar
  • Tem um custo computacional que pode ser problemático em grande tráfego (atualmente tem 69 matérias e algumas com múltiplas turmas, então não dá pra pré-processar tudo)
• Sugestões:
  • Pode ser usado para medir o interesse de matrícula nas matérias/turmas (os dados do formulário de pré-matrícula não é público e não identifica o interesse em turmas específicas) ou até mesmo horários.
  • Com os dados citados anteriormente, poderia ajudar a coordenação a evitar choques de horários com base nas matérias de interesse em comum pela maior parte das pessoas
  • Pré-processar as turmas que causam choque entre si pode otimizar o processamento.

Discursão

Com base nos dados e nas sugestões reunidas, vamos tentar amadurecer alguma ideia para tentar chegar a algum consenso.

• Eu compreendo as desvantagens de uma API com lógica tão restrita e consequentemente porque pode-se não querê-la nesse repositório.
• Acho que o processamento de matérias pode ser algo legal e genérico pra se ter em uma API como essa voltada ao curso, mas sinto que ela ainda precisa de mais razão pra existir antes mesmo de existir.
• O que for discutido aqui pode ser usado para definir melhor as diretrizes do próprio repositório e estas encontrariam um bom lugar no arquivo de contribuição ou no README.

Por favor, deem suas próprias opiniões e sugestões para incrementar que eu edito para condensar as informações em um único comentário

[JuanBarros2]

Acredito que sobre o processamento das disciplinas podemos agregar mais informação juntos com o outro CSV que estarei adicionando à API essa semana. Sobre a lógica do criador de horários acredito que é bom deixar ela separada deste repositório, pois acredito que a aplicação tem um potencial maior. Vejo um cenário que talvez, no futuro, faça sentido adicionar técnicas de IA para auxiliar a gerar o horário, se baseando nos dados de consultas anteriores e até mesmo nos índices de aprovação e informações extras que poderiamos extrair dos dados disponíveis. Acho que seria válido colocar no README do laguinho isso que @danielmitre falou sobre processamento. O quanto pudessemos livrar a API de lógica de negócio, melhor ficaria para pessoas conseguirem consumir dela.

[JoseRenan]

Isso, acho que @JuanBarros2 resumiu tudo. No caso adicionarei ao README.md que a ideia de adicionar endpoints é mais sobre adicionar dados para serem consumidos, sem lógica de negócio e etc.

[danielmitre]

Massa, então todos concordam com a API dos horáros né?
Antes de fechar essa issue, gostaria de confirmar o formato da API, imagino algo como:

[GET] /v1/horario/20191

{
    20191: [
        nome-materia1: {
            disciplina: "nome-materia1",
            alias: "Nome da Matéria",
            categoria: "obrigatoria",
            periodo: "5;4"
            turmas: {
                1: {
                    professor: "professor1",
                    sala: "sala1",
                    horario: ['s08', 'x10']
                },
                2: {
                    professor: "professor2",
                    sala: "sala2",
                    horario: ['i08', 's10']
                }
            }
        },
        ...
    ],
    ...
}

Alguma sugestão? A parte de alias posso fazer a mão para as matérias que já tem, mas vocês acham que isso se encaixaria melhor em outro endpoint?

[JoseRenan]

@danielmitre, por mim pode ser esse formato mesmo. É necessário um objeto interno indicando o período 2019.1, tendo em vista que o período é descrito na URL? e sobre a URL, hoje foi merjado o PR #6 que adiciona o endpoint v1/subjects que diz todas as disciplinas da nova PPC, o teu poderia ser dentro desse tbm, algo como v1/subjects/schedule/{periodo}. O que acha?

Outra coisa que me chamou atenção agr que tu fez foi sobre deixar as coisas em português o que faz muito sentido já que é uma coisa pra CC UFCG e que a gente quer incentivar a contribuição 🤔 mas vou criar uma outra issue pra isso.

[EDIT]: Criei a issue pra discutir a nossa lingua padrão kkkkkk #10

[danielmitre]

@JoseRenan, realmente eu misturei as ideias. para a rota em questão seria logo o array mais interno, sem o objeto indicando os períodos.

Esse objeto mais externo foi pensado para guardar a informação no data.js e para uma rota como /schedule/all, assim como imagino uma rota /schedule/latest para retornar o período mais recente.

[EDIT]: Vejo um problema de compatibilidade entre os nomes utilizados para referenciar as matérias entre os CSV's, devo adicionar um schedule-alias na v1/subjects?

[JoseRenan]

@danielmitre, tu vai fazer esse endpoint ainda? eu tava pensando em criar uma issue separada com as coisas que foram definidas aqui caso eu possa disponibilizar ela pra outras pessoas fazerem.

[danielmitre]

Infelizmente algumas atividades aconteceram e vou demorar a conseguir focar em algo assim novamente, pode distribuir à vontade.
Se alguém não quiser começar do 0, tenho um repositório com a API do horarinator, deve ser bem similar à lógica que ele usa por baixo, mudando as alterações discutidas aqui.
Bom jogo e boa sorte a todos.

[thayannevls]

Devido a reformulação do laguinho #31, vou fechar a issue. Era uma boa submeter esse projeto pra lista de publicações depois