A questo punto ci spero, nonostante io sia il primo a perderci considerato che ho ancora dei biglietti da usufruire.
Arrivo a Parigi da Los Angeles, vado al desk di AirFrance che svolge il servizio per conto di Alitalia e mi dicono che il volo che mi è stato venduto ... NON ESISTE! Non sto dicendo che sia stato annullato ma proprio che non esiste. Sembra che il calendario autunnale non sia stato aggiornato e quindi mi hanno venduto una cosa che non c'è.
Fantastico, non c'è che dire, Non mi interessa sapere se la colpa è di quello che ha fatto il sito, di quello che non ha aggiornato i dati sul DB per i voli autunnali, di quello del call center che mi ha assicurato prima di partire che era tutto a posto, di quello che non ha mandato la mail. Io ho comprato un volo AKA servizio e non mi è stato erogato. La colpa è di tutti perché la vittoria e la sconfitta di una azienda è condivisa da tutti, nessuno escluso.
Questo per non parlare del fatto che sulle prenotazioni Alitalia non viene scritto a quale terminal andare a prendere il volo e che se provi a telefonare al call center per avere informazioni sul tuo volo non ti risponde nessuno. La vergogna viene condivisa da tutti perché nella barca di sono tutti quanti, NESSUNO escluso.
A questo punto forse è meglio che venga demolito tutto e i migliori, se sono veramente tali, troveranno certamente spazio per esprimersi meglio di prima.
Greetings from Paris ...
Prima di tutto vanno i complimenti al brillantissimo Luca Bolognese per la sua splendida sessione su F# che ha riempito e mandato in overflow l'aula. Non lo dico perché ci conosciamo ed è genovese come il sottoscritto ma perché lo ha dimostrato sul campo con applausi continui dalla platea.
F# è un linguaggio funzionale che incorpora una serie di caratteristiche tipici dei linguaggi objecto oriented. Questa scelta lo rende usabile e spendibile in applicazioni reali senza alcun compromesso. Lo stesso Luca alla fine della sessione cita casi reali in cui F# è già stato adottato e in produzione per le sue caratteristiche 'pratiche'.
La sessione è tutta a demo. In prima battuta scrive in F# un algoritmo di parsing che non usa caratteristiche funzionali ma simil C#. È ovviamente sbagliata come impostazione ma aiuta tutta la platea a seguire in che modo un algoritmo di parsing possa essere semplificato.
Purtroppo non ho il tempo di bloggare i dettagli ma certamente ci tornerò sopra considerato anche che ci avevo già cominciato a giocare un po'.
Chris Anderson e Giovanni Della Libera sono gli speaker della sessione che è certamente una delle più interessanti della PDC 2008.
I concetti di Oslo, come ho già detto nel post precedente, non sono stati capiti dalla maggior parte degli attendees. Io ho potuto risolvere i miei dubbi iniziali andando al booth Oslo come fossi un Samurai... ero deciso a metterci le tende pur di avere risposte chiare che mi sono state date.
Il punto è che il messaggio di poca chiarezza è arrivato forte e chiaro al team e infatti in prima fila era presente Don box, Martin Gaudgin e molte altre persone del team.
Ma veniamo al dunque. La sessione parla specificamente di MGrammar, quella parte di M che serve a creare la grammatica di un DSL testuale. Niente di meglio di un esempio per fare chiarezza sull'uso di MGrammar.
Intellipad suddivide la schermata in tre porzioni verticali:
- Sinistra: il comando testuale di cui fare il parsing ... in pratica il nostro nuovo linguaggio
- Centro: il linguaggio che definisce le regole grammaticali
- Destra: il grafo che è il risultato del parsing. È suddiviso in nodi e 'successors' che possono essere iterati recuperando i dati parsati
Il linguaggio è molto versatile e consente di definire semplicemente:
- quali siano i caratteri da ignorare (per esempio spazi e 'a capo')
- la sintassi per riconoscere i vari pezzi da parsare che fa uso di lambda function
- i token che, in modo simile alle regular expression, definiscono come sono costituiti gli elementi cghe rappresentano i dati
- ricorsività che serve ad eseguire un parsing efficiente dei dati che possono ripetersi
Una volta definita la grammatica uso mg.exe per creare i file mx (l'integrazione di Visual Studio arriverà presto ed è comunque già possibile con pochi passi manuali in questa prima CTP).
Il risultato della compilazione è un file mgx che è un package OPC, quindi uno zip con dei contenuti XML al suo interno.
Fatto questo, creo un normale progetto .NET, referenzio un paio di assembly (Microsoft.M.Grammar e System.DataFlow) e scrivo il codice per caricare e parsare la grammatica, ottenendo così il grafo.
Questo è l'inizio e non sembra poi così complesso. Personalmente credo che il successo di questo strumento sia strettamente legato ai tool visuali che Microsoft o terze parti integreranno in Visual Studio per rendere più semplice (visuale) la creazione del file che definisce la grammatica. Se questo avverrà, credo che vedremo finalmente nascere l'epoca dell'industrializzazione del software.
Oggi tutti i software sono opere di artigianato in quanto ogni singolo sviluppatore può fare la differenza tra un software di successo o un clamoroso flop. I DSL danno la possibilità alla software house di costruire una serie di piccoli mattoncini verticali al dominio dell'applicazione che possono essere usati da un power user per eseguire delle customizzazioni.
Facendo un parallelo tra l'industria automobilistica e il software, in una catena di montaggio di una specifica automobile si può costruire solo quel modello ma sono ammesse una serie di varianti come il colore, gli spoiler, etc.. L'operaio non solo non è determinante sulla perdità totale di qualità del prodotto, ma ha dei constraint, cioè possiede solo gli strumenti che servono a quella specifica attività (montare il finestrino piuttosto che il paraurti).
La strada di Oslo è lunga ma promette certamente molto bene.
È Joshua Goodman lo speaker della affollatissima sessione sulle novità nel CLR 4.0. Dopo il CLR 2.0, la 4.0 è la versione successiva (nel Framework 3.x il CLR è quello della 2.0) ed introduce numerose novità.
- Certamente la novità più importante è quella che un processo potrà far girare sia la versione 2.0 che 4.0 contemporaneamente. In pratica dei plugin che girano con una versione differente di CLR rispetto a quella dell'applicazione potranno girare con la versione di CLR desiderata. Questo evita tuta una serie di side-effect e lo speaker cita un plugin di Outlook usato internamente dagli 'executive' che era realizzato con la versione 1.1 ed aveva un bug sul multithreading. Con la versione 2.0 il runtime, essendo più veloce, ha evidenziato il bug rendendo sistematicamente impossibile il suo utilizzo. Sarà anche possibile usare file di configurazione differenti per il codice che gira con una versione differente di CLR.
- No-PIA di cui ho già parlato nel dettaglio nel post della sessione dedicata a questo tema
- Nuova classe Tuple<> che facilita linguaggio com F# e Python ma che sono comodi anche per C#
- Notifiche prima di una Garbage Collection di tipo Server in generazione 2. Questo consente di eseguire load balancing ed evitare latenza.
- Background Collection sul GC di tipo Workstation. Con la 3.5 SP1 il GC può eseguire buona parte della Garbage Collection di generazione 2 in background senza sospendere l'esecuzione del codice managed.
Con il CLR 4.0 la collection in generazione 0 e 1 può avvenire contemporaneamente a quella di generazione 2, eliminando così buona parte dei problemi di latenza. - Possibilità di eseguire attach/detach di profilatori su memoria e performance counters. Il meccanismo non è invasivo (niente registry) e usabile anche in produzione.
- È possibile ora eseguire il catch di eccezioni di bassissimo livello come la corruzione dello stato e della memoria nel processo. Utile per eseguire dei log/dump prima di abbandonare l'esecuzione del processo.
- Supporto per il debugging misto 32/64 bit.
- API per capire chi sta mantenendo un lock o chi ne è in attesa
- Code Contracts. È un nuovo sistema per validare i parametri di input e il valore di output di un metodo. Nel metodo si usa CodeContract.Requires per validare i parametri di input oppure CodeContracts.Ensures per verificare che l'output rispetti certe condizioni. La cosa interessante è che è possibile usare i CodeContract sia con dei tool di analisi statica che a runtime. Siamo di fronte a una nuova generazione di validatori.
Non ci resta che provare tutte queste belle cose nella Virtual Machine. Da quello che vedo il CLR è sempre più potente e l'incremento delle performance e la duttilità del Garbage Collector lo rendono sempre più appetibile persino per applicazioni estreme come i videogame.