Non categorizzare corsi in magistrale

[samuelemusiani]

La maggior parte dei corsi della magistrale non sono obbligatori e possono essere scelti l'anno che si vuole. Tutte le categorie presenti in degrees.json che vanno bene per la triennale non funzionano quindi più per la magistrale.

Secondo me può avere senso togliere proprio le categorie in magistrale ed elencare semplicemente i corsi. Dobbiamo però ripensare un attimo al json e fare in modo che tutti i servizi che lo usano (es. dynamik) si aggiornino di conseguenza.

@foxyseta ti viene qualche idea belle per riscrivere il json almeno per le magistrali? Per il momento io non ho idee, se mi viene qualcosa lo scrivo

[samuelemusiani]

L'unica soluzione che mi è venuta in mente è quella di introdurre un campo strict nel json che se presente e messo a true utilizza i corsi presenti nell'array years suddivisi per anno, ecc. Se invece il campo è false si utilizzano i corsi senza ordine e categorie presenti in un nuovo array che possiamo chiamare teachings.

Quindi la magistrale verrebbe tipo così:

  {
    "id": "informatica-magistrale",
    "name": "Informatica Magistrale",
    "icon": "🧑‍🏫",
    "chat": "t.me/mag_informatica_unibo",
    "strict": false,
    "teachings": [
            "usability-e-user-experience-design",
            "complementi-di-linguaggi-di-programmazione",
            "complementi-di-basi-di-dati",
            "intelligenza-artificiale",
            "digital-forensics",
            "decision-making-with-constraint-programming",
            "ingegneria-del-software-orientata-ai-servizi",
            "simulazione-di-sistemi",
            "modelli-e-sistemi-concorrenti",
            "computer-graphics",
            "matematica-computazionale",
            "modelli-probabilistici",
            "sistemi-context-aware",
            "fisica-dei-sistemi-complessi",
            "fondamenti-logici-informatica",
            "didattica-informatica",
            "emerging-programming-paradigms"
    ]
  }

E una triennale verrebbe cosi:

  {
    "id": "informatica",
    "name": "Informatica",
    "icon": "🧑‍💻",
    "strict": true,
    "years": [
      {
        "year": 1,
        "chat": "t.me/uniboinfo23",
        "teachings": {
          "mandatory": [
            "analisi-matematica",
            "architettura-degli-elaboratori",
            "logica-per-informatica",
            "programmazione",
            "algoritmi-e-strutture-di-dati",
            "algebra-e-geometria"
          ]
        }
      },
      {
        "year": 2,
        "chat": "t.me/uniboinfo2223",
        "teachings": {
          "mandatory": [
            "calcolo-numerico",
            "ottimizzazione-combinatoria",
            "tecnologie-web",
            "reti-di-calcolatori",
            "linguaggi-di-programmazione",
            "calcolo-delle-probabilita-e-statistica",
            "sistemi-operativi"
          ]
        }
      },
      {
        "year": 3,
        "chat": "t.me/joinchat/jTyZ03cqDRliOTY0",
        "teachings": {
          "mandatory": [
            "basi-di-dati",
            "introduzione-apprendimento-automatico",
            "ingegneria-del-software",
            "fondamenti-di-cybersecurity",
            "informatica-teorica"
          ],
          "electives": [
            "laboratorio-di-applicazioni-mobili",
            "metodi-logici-per-la-filosofia",
            "progetto-di-sistemi-virtuali",
            "strategia-aziendale",
            "storia-informatica-e-dei-dispositivi-di-calcolo",
            "fisica",
            "introduzione-alla-scienza-e-tecnologia-quantistica",
            "ing-laboratorio-sicurezza-informatica-t",
            "ing-laboratorio-amm-sistemi-t",
            "isi-computational-statistics"
          ]
        }
      }
    ]
  }

[foxyseta]

Il modo idiomatico di farlo (ispirato a Schema JSON, che è un buon riferimento anche se non lo usiamo al momento) sarebbe un unico campo "teachings" che è di "tipo" union/either e può essere o teachings sfusi o anni. Tuttavia nel nostro caso sarebbe un breaking change perché dovremmo rinominare "years" in "teachings". D'altro canto src/config lo usiamo solo in casa, non ha rilasci né un'interfaccia pubblica dichiarata... Inoltre basta rinominare un campo (years -> teachings) lato progetti per sistemare. Cosa ne dici? È molto simile alla tua come soluzione ma non usa una flag apposita (perché l'analisi dei JSON di solito non ne ha bisogno) e chiama i due campi nello stesso modo.

[samuelemusiani]

Non ho ben capito sorry. Intendi che rinominiamo years in teachings per tutti gli oggetti o solo per le magistrali che non hanno ordine?

Immagino per le magistrali e verrebbe qualcosa del genere giusto?

[
  {
    "id": "informatica-magistrale",
    "name": "Informatica Magistrale",
    "icon": "🧑‍🏫",
    "chat": "t.me/mag_informatica_unibo",
    "teachings": [
            ...
    ]
  },
  {
    "id": "informatica",
    "name": "Informatica",
    "icon": "🧑‍💻",
    "years": [
      {
        "year": 1,
        "chat": "t.me/uniboinfo23",
        "teachings": {
          "mandatory": [
            ...
          ]
        }
      },
      {
        "year": 2,
        "chat": "t.me/uniboinfo2223",
        "teachings": {
          "mandatory": [
            ...
          ]
        }
      },
      {
        "year": 3,
        "chat": "t.me/joinchat/jTyZ03cqDRliOTY0",
        "teachings": {
          "mandatory": [
            ...
          ],
          "electives": [
            ...
          ]
        }
      }
    ]
  }
]

Poi durante il parse controlliamo se è presente il campo years o teachings e ci comportiamo di conseguenza?

[foxyseta]

Tecnicamente pure "years" per le triennali diventa "teachings", perché negli schemi JSON esprimere che "teachings" può essere fatto in un modo o nell'altro è immediato, mentre esprimere che un certo oggetto o ha un campo "years" o un campo "teachings" genera molto codice duplicato (sia nel caso generale che nel nostro caso). Però se siamo sicuri di non voler mai formalizzare la struttura di questi JSON da nessuna parte se ne può discutere.

Discorso a parte: gli esami obbligatori in magistrale un anno ce l'hanno (il primo). Scegli tu se lasciare almeno il primo anno o proprio togliere anche quello.

[samuelemusiani]

Ok chiaro mettiamo tutti a teachings. Ci lavoro io nei prossimi giorni e prima di mergiare su main faccio in modo che almeno informabot e dynamik si aggiornino di conseguenza

Per la questione degli esami obbligatori mi hanno detto che dal prossimo anno anche al primo di magistrale diventa tutto facoltativo, per quello non stavo più a fare distinzioni

[foxyseta]

Per la questione degli esami obbligatori mi hanno detto che dal prossimo anno anche al primo di magistrale diventa tutto facoltativo, per quello non stavo più a fare distinzioni

ah lol no lo sapevo. Perfetto allora

[lucat1]

Samu mi dice che è un po’ rognoso di fare parsing di questa union in Go. Perché non facciamo semplicemente che ogni corso di laurea ha la lista teachings (come suggerisci tu @foxyseta) e gli elementi di questa lista anzi che essere stringhe sono oggetti con un nome (che prende come valore la quello della semplice stringa che c’era prima) e un campo opzionale che specifica in quale anno si trova il corso. Poi i corsi di laurea divisi in anni hanno anche il campo opzionale years che è una lista di anni con le varie informazioni per quell’anno. È una rappresentazione più da db relazionale che da db a documenti, quindi magari non super idiomatica, ma rende il parsing molto più facile in linguaggi con un sistema di tipi non troppo avanzato come Go.

[foxyseta]

Ah sisi a me va bene tutto è che pensavo volessimo evitare breaking changes non triviali. Comunque ok.

[lucat1]

Si non piace neanche a me la breaking change, però mi pare una struttura migliore questa. Per le breaking change in futuro io scriverei una piccola libreria in Go che prende sto JSON e ne fa il parsing in delle strutture (anche strutture più complesse non 1:1 con il json) in modo da facilitarne l'uso. E in questo modo possiamo nascondere tutte le breaking change che vogliamo dietro l'interfaccia della libreria che idealmente non dovrebbe cambiare molto. L'unica cosa che rimarrebbe fuori è dynamik.

[samuelemusiani]

Per le breaking change in futuro io scriverei una piccola libreria in Go che prende sto JSON e ne fa il parsing in delle strutture...

Ho fatto una repo in cui ho messo tutto il parsing che era in informabot. Così possiamo lavorarci a parte. Ovviamente andrebbe definita una sorta di interfaccia da minimizzare i breaking changes

[lucat1]

Si esatto samu. Per me è un buon approccio. Sentiamo cosa dice @foxyseta

[foxyseta]

Ma sì siccome facciamo unmarshaling in tutti i progetti Go che usano src/config mi sembra sensato. Come CI/CD per config-parser-go possiamo tentare il parsing di tutti i JSON in una volta sola. Lascerei comunque aperta la possibilità di aggiungere in futuro degli schemi json a src/config e poi validare i JSON via CI/CD.

[samuelemusiani]

Ho aggiunto la CI/CD per config-parser-go. Mi metto a lavorare sulla nuova struttura del json