Thesis
Tutti , chi più chi meno, alla fine della nostra carriera universitaria ci scontriamo con il fantomatico “lavoro di tesi”. Per molti tale lavoro di tesi comporta, almeno per quanto mi riguarda direttamente, lo sviluppo di applicazioni atte a supportare le nostre brillantissime e innovative idee.
Si parte da un bell’articolo, si studiano le forume e gli algoritmi, si prende il buon caro vecchio MatLab e via a scrivere codice a muzzo, o se preferite, passatemi il francesismo, alla cazzo . Funzionerà, non funzionerà, chi lo sa, l’importante è scrivere e fare dei bei grafici o tirare fuori un numero che si avvicina molto a quello dell’articolo letto. Sfido chiunque a sostenere il contrario…
Riassumendo il metodo di lavoro iniziale è il seguente:
- Leggi articolo e parti di gran carriere ad implementare
- Ti scontri subito con la scarsa padronanza del linguaggio di programmazione, qualunque esso sia
- Spendi due settimane a capire come funziona il linguaggio di programmazione
- Parti con implementare il primo paragrafo di dieci righe che esplode in 2500 righe di codice e ti chiedi se sei tu un pirla o loro che ci hanno fatto dentro
- Avanzi con il secondo paragragfo, ti rendi conto che quelle 2500 righe sudate prima non servono a una mazza, le tieni per ricordo
- Sudi sangue ma alal fine arrivi alla formula finale, fai girare il tuo programma e non esce nessun errore però, chissà perchè, i tuoi numeri sono diversi da quelli dell’articolo… si ripone il dilemma : o tu sei un pirla o loro ci hanno fatto dentro ancora sui risultati
- Vai dal tuo assistente di fiducia, gli fai vedere il tuo lavoro, anche un pò soddisfatto delle ormai 10mila righe di codice prodotto e scopri che:metà del codice era già stato fatto da altri prima di te e bastava chiederlo, i tuoi risultati fanno cagare
- Tutto questo si può inserire in un bel ciclo repeat-until
Dopo dieci, quindici iterazioni completedi tale procedura una cosa buona l’hai portata a casa: inizi a capire come si deve programmare…
TASK 1 completed: abbiamo gli strumenti per poter lavorare.
Decidi, o decidono per te, che DEVI RIFARE TUTTO. Seguiranno 38 minuti di sacrosante madonne condite di belle parole, minuti effettivi, senza contare i tempi per le rimesse laterali. Il giorno dopo ti metti a riscrivere il tuo programma, questa volta oltre a sapere programmare hai dalla tua un potente quanto subdolo e bastardo alleato, il copia e incolla. Parti di gran carriera, questo lo riscrivo un attimo, rattoppo di qua, copia di la.. alla fine in due giorni fai tutto quello che hai fatto in due mesi di lavoro precedente.. beh, ora sai programmare meglio ti dici, stavolta vinco io… lanci l’applicazione, e , porcaputtana, numeri del lotto… non ti perdi d’animo e vai a capire qual’è quella cosa che sputtana il tuo risultato finale.. trovi magari un bel coefficiente o parametro che sballa tutto, lo modifichi e via, tutto sembra essere molto vicino al risultato atteso, euforia, stappi la bottiglia buona e uccidi il vitello grasso. Il tutto dura tra i 10 e i 15 minuti, dopodichè un dubbio ti attanaglia… e se cambio il set di dati, metto rumore o altro, che succede? Dovrebbe comportarsi da manuale, seguire il bel grafico visto nell’articolo… Provi. Non c’entra una mazza.TASK 2 completed: ti rendi conto che non puoi farci dentro così facilmente…tocca fare le cose seriamente.
Sei giunto al terzo grado Jedi-thesis-coding: scrivere qualcosa dal nulla è un gran casino. Ti illumini e dici: “Se io ho questi dati, e processandoli devo ottenere questi risultati, perchè non generare i dati a partire dai risultati e poi far girare su questi il mio programma?”.
Ora sei pronto per scrivere del software corretto e coerente al tuo lavoro. Sei finalmente pronto per affrontare il lato oscuro della scrittura della versione finale del tuo software. Nella fattispecie organizzerai il lavoro in diverse fasi:
- Scrittura di una routine che generi i dati sintetici a partire da risultati attesi
- Organizzazione del software razionale, in librerie possibilmente per il riutilizzo del codice senza il fantasma del copia e incolla
- Scrittura di una applicazione che processa i dati sintetici e ritorna i risultati , usando le chiamate alle funzioni della tua libreria
- Salvataggio dei dati su un file di Log, utile per valutare le prestazioni e i progressi del tuo lavoro
Quello che hai fatto è il lavoro ultimo, summa di tutti gli sforzi, sicuramente non funzionerà al primo colpo ma in questo modo se hai un errore puoi trovarlo facilmente, cambi una riga di codice, fai girare il la tua applicazione di testing e controlli i risultati. Una volta che riesci a tornare indietro sui tuoi passi e riottenere i risultati attesi dai dati sintetici puoi procedere alla validazione del tuo lavoro.
- Scrivi un bel programmino che genera dati sintetici partendo da diversi set di risultati magari, ci metti del rumore o tutto quello che è possibile variare nell’ambiente di lavoro che hai creato per generare i dati
- Fai girare questo batch fino alla morte, raccogli tutti i dati su dei file
- Raccogli i dati in grafici e tabelle e li confronti con quelli trovati negli articoli
I risultati sono soddisfacenti? Se sì buon per te, puoi proseguire con il tuo lavoro alla fase successiva, sia essa scrittura o ampliamento del software stesso, altrimenti si torna al codice, si modifica, si fa girare il test e si validano di nuovo i risultati fino ad ottenere il risultato voluto.
Ovviamente nessuno si rende conto dell’efficacia di tale metodo di lavoro fino a quando non ci arriva passando dalle tre tappe suindicate.
TASK 3 completed: ora sei un vero tesista, peccato che , ad aver saputo prima come fare ti saresti laureato mesi fa..forse…

Entries (RSS)