Come ho già scritto, venerdì scorso ho tenuto la mia prima sessione in occasione dell’evento community di Roma.
E in piena ottemperanza con l’ineluttabile legge di Murphy, ho dovuto affrontare al volo un paio di difficoltà:
- Nel commentare il sorgente della demo, ad un certo punto mi sono accorto che nel DataContext erano apparse quelle diaboliche sottolineature ondulate in rosso, chiaro segno di errori che avrebbero senzameno impedito la compilazione e l’esecuzione della demo.
- Nel mostrare un esempio d’uso di ISETool, il tool che consente di leggere e scrivere da e verso l’isolated storage del windows Phone, mi è mancato il file di testo sul quale mi ero appuntato la chilometrica linea di testo.
Per quanto riguarda il primo punto, dopo aver fatto un paio di tentativi per capire la causa, ho avuto il buon senso di non intestardirmi e ho ricaricato il progetto da una provvidenziale chiavetta usb che mi ero preparato in caso di guasti o incompatibilità del mio laptop col proiettore della sala. La lezione che ho imparato è che bisogna SEMPRE farsi anche una copia in locale, così se per qualche motivo il progetto non gira, lo si può recuperare dal PC stesso senza chiavette di sorta. E’ meno plateale e più “indolore”. Ma la chiavetta va comunque fatta, e ringrazio me stesso per averci pensato.
Per quanto riguarda il secondo punto, ho dovuto fare a meno di mostrarne l’esecuzione per evitare di perdere tempo ricreando il comando al volo, visto che veder eseguire un tool a linea di comandi che gira e poi scrive qualcosa equivalente a “fatto!” ha poco senso se ci devi spendere più di un microsecondo. La lezione che ho imparato è che non si deve MAI affidarsi ad un link che si riferisce ad un file che ti serve nella demo. Io avevo messo un link sul desktop e poi, chissà perché, cancellato il file dalla cartella della demo. Mistero della fede o più prosaicamente legge di Murphy.
Infine, visto che avevo promesso in sala che avrei postato il motivo degli errori comparsi “misteriosamente” nella solution dell’applicazione demo, ecco la spiegazione:
La mattina di venerdì ho fatto una “dry run” della sessione per verificare se stavo nei tempi e per ripassare il tutto. Quindi ho svolto tutte le fasi previste, tra le quali il commento del sorgente e l’esecuzione della demo, che è andata liscia come l’olio. Poi, come previsto dalla scaletta, ho illustrato il plug-in “SQL Server Compact Toolbox” di Erik Ejlskov Jensen mostrando la funzione di creazione automatica (tramite SQLMetal) del DataContext a partire dal database SQL CE estratto dall’isolated storage mediante ISETool. Infine ho chiuso Visual Studio.
Peccato che a quel punto la solution era stata modificata dall’uso del plug-in, in quanto ora conteneva due classi PlannerDataContext, una creata da me per il corretto funzionamento del programma e una creata dal plugin, che al suo interno ridefiniva anche le classi Projects e Tasks. C’era ben più di un motivo per gli avvisi di errore del compilatore!
Con la tranquillità di casa trovare il motivo è stato semplice, in sala credo sia stato meglio soprassedere e ricaricare la solution da chiavetta.
Altra lezione che ho imparato: quando si fanno le sessioni di prova, è come quando si esegue un test: bisogna ricreare l’ambiente di prova e poi, a sessione terminata, BUTTARLO VIA!
Ad ogni modo una promessa è una promessa, e io ho tenuto fede alla mia :-)
posted @ martedì 11 ottobre 2011 17:40