Programmare non è semplice organizzarsi non è facile

A lunga distanza dal mio ultimo post.. ritorno a farmi vivo. Programmare richiede un piano preciso, ovvero mi sto accorgendo che NON è tanto più importante sapere come si programma (conoscere cicli, strutture, ecc.. ecc…), ma conta molto di più sapere cosa ci serve, di cosa abbiamo bisogno.. insomma quali procedure dobbiamo seguire per portare a termine i nostri calcoli di elaborazione.

Io, per esempio, mi sono bloccato perchè ad un certo punto mi sono accorto di non avere nessuna conoscenza su quale sia la maniera più sensata per confrontare dei dati (in questo caso dei risultati calcistici) registrati da una certa squadra, in un certo anno, per una certa competizione (ecc.. ecc…)

Al momento sto migliorando alcune metodi delle strutture centrali (della mia apllicazione) atte ad accogliere questi dati: inizialmente concentravo tutte le partite giocate da una stessa squadra in una unica “Tree Map Indicizzata” (detta anche “tmi”), ma ciò avrebbe voluto dire dover scorrere migliaia di dati solo per recuperarne un minuto sotto-insieme nel caso volessi ri-cercare le partite disputate in una sola stagione. Ho pertanto fatto in modo che queste partite, al momento della lettura dal database (nel mio caso un foglio di documento *.Xml), vengano collocate in una struttura gerarchica basata sulla distribuzione temporale: partendo dalla considerazione che è una squadra non gioca più di una partita in un giorno dell’anno ho fatto si di creare

  1. una tmi ‘Stagione’ che raccoglierà tutte le partite giocate da <<questa>> squadra nella stagione del biennio, per esempio, ‘1982-1983′.
  2. si scende di un livello e troviamo una nuova tmi che accoglierà i singoli anni che costituiscono il biennio citato poco fa, cioè troviamo una tmi per l’anno ‘1982′ ed un’altra tmi per l’anno ‘1983′.
  3. per ciascuna tmi dei suddetti anni vi è una tmi per ogni mese giocato: la tmi ‘1982′ conterrà 4 diverse tmi ‘mese’ ovvero ‘09′, ‘10′, ‘11′ e ‘12′ (settembre, ottobre,  novembre e dicembre) mentre la tmi dell’anno ‘1983′ (l’anno in cui terminano le competizioni calcistiche – serie A, serie B, … Coppa Italia, Coppa dei Campioni, … iniziate proprio nel settembre dell’anno precedente, il ‘1982′) conterrà i restanti mesi di gioco, da ‘01′ (Gennaio) a ‘05′ (Maggio).

ed infine, punto 4., ognuna di queste tmi ‘mese’ conterrà la coppia univoca <Giorno, Partita>. Notiamo come per questa coppia ne esistano due versioni simili contenute ciascuna nella tmi ’squadra’ di entrambe queste formazioni che si sono incontate in questo match. La Partita() contenuta nella tmi della squadra locale avrà dati propri, speculari ed in comune con la Partita() contenuta nella tmi della squadra avversaria. I dati propri possono essere il nome dell’allenatore, i dati speculari potrebbero essere il numero dei goal fatti e delle reti subite (per la squadra avversaria si invertono tali valori, ovvero il numero dei goal fatti dalla squadra locale, squadraHOME, è uguale al numero delle reti subite dalla squadraaway, ospite), invece alcuni dati in comune potrebbero essere il nome dell’arbitro, il nome dello stadio in cui si è giocato, i nomi dei marcatori, degli ammoniti o degli espulsi… insomma, nel momento in cui scrivo ciò, mi chiedo se non sia meglio gestire tutti questi dati mantenendoli comuni alle due squadre?? Ciò mi potrebbe aiutare, per esempio, a trovare tutte le partite vinte con & contro un dato allenatore… Ci rifletterò.

Per adesso completo solo l’ottimizzazione delle classe Tmi(), come vedete l’intera organizzazione dei dati -per la loro futura elaborazione- si basa su questa struttura, ma come già detto all’inizio di questo post CONTA MOLTO DI PIU’ SAPERE COSA FARCI CON I DATI (come vanno elaborati al fine di ottenerne il miglior risultato utile ai nostri scopi) PIUTTOSTO CHE SAPERE COME ORGANIZZARLI/ACQUISIRLI AL MEGLIO NELLA MEMORIA RAM DEL NOSTRO CALCOLTAORE.

Ciao ragazzi, e se passate da qui, fatemi sapere che ve ne pare: ogni consiglio e/o critica è ben accetta :)

There are no comments on this post

Leave a Reply