Data Mining, birre e pannolini: fine di una leggenda metropolitana

Chiunque abbia mai sentito qualche introduzione sul Data Mining, si sarà certamente imbattuto prima o poi nella mitologia di “birra e pannolini”: si narra(va) che grazie ad algoritmi di data mining si era scoperto che negli USA un acquisto combinato piuttosto frequente era quello di birra e pannolini per bambini. Personalmente credo di non aver mai usato questa storia per introdurre i concetti del data mining perché ho sempre pensato che fosse una storia un po’ tirata per i capelli.


Finalmente ho letto che qualcuno si è preso la briga di verificare le fonti della storia, che è molto meno vera di quanto compare e non è nemmeno frutto di un algoritmo di Data Mining.


Ciò nonostante, le tecniche di Data Mining restano molto utili e interessanti, ma per lo meno adesso si divulgheranno con qualche esempio più realistico… 🙂


A questo punto l’unico dubbio è se la leggenda metropolitana abbia comunque avuto effetto o meno sulla disposizione logistica dei reparti che contengono birra e pannolini nei supermercati. Dall’ancora scarso utilizzo di questi strumenti (almeno in Italia) scommetterei di sì (nessuno controlla i numeri e si va avanti per luoghi comuni…).

Team italiano vince Imagine Cup

Grazie all’esultante post di Andrea ho scoperto che un gruppo italiano ha vinto la Imagine Cup 2006 (quest’anno ci sono state varie categorie ma di certo la Software Design che è la più importante).


Tanto per aggiungere un po’ di campanilismo (tanto siamo ad agosto) aggiungo che la gioia per me è doppia visto che i ragazzi sono del Politecnico di Torino.


Battute a parte, ho avuto modo di vedere dal di dentro cosa significa questa manifestazione avendo partecipato (come immeritato giurato!) a una precedente finale italiana e so quanto sia difficile e competitivo l’ambiente (a livello internazionale ho visto progetti veramente impegnativi e anche in Italia non si scherzava). Non conoscevo bene Hello World, il progetto vincente ma dai video si capisce perché hanno vinto…. si tratta di una realizzazione ambiziosa e notevole (tanto per capirci, usano già SQL 2005, WCF e WPF e quest’ultimo in particolare fa veramente effetto nella demo, fatta temerariamente usando anche Windows Vista).


Complimenti quindi al team, che ha un nome bellissimo per chi conosce IL: Even .ctor ed è composto da Giorgio Sardo, Massimo Paternoster, Silvia Perrone, Andrea Sossich.


Veramente bravi, ragazzi!


PS: La demo fatta con strade e mappe di Torino, ormai famosa città olimpica diventata addirittura (ma meritatamente) meta turistica, secondo me qualche aiuto l’ha dato… 🙂

Conferenze vietate ai minori

In una non troppo calda notte di mezza estate ho avuto l’idea di rivedere qualche blog che non seguo più da tempo, come quello di Robert Scoble. La curiosità è caduta su questo post relativo al divieto ai minori di 18 anni di partecipare a una conferenza. L’ironia sta nel fatto che la conferenza è su Linux, e molti sviluppatori nonché utenti di Linux (così come di Windows e di altri sistemi operativi) hanno meno di 18 anni.


Ironia a parte, in realtà in un post successivo Robert segnala che in molte altre conferenze vige la stessa policy, benché nessuno (me compreso) ne abbia mai visto traccia. Credo sia una di quelle regole “all’italiana”, fatte per poter essere applicate con discrezionalità in caso di eccessi da parte di qualcuno (tutto il mondo è paese), ma chiaramente il cartello esplicito fa più notizia. Il mio giudizio su una cosa simile credo sia quasi scontato: si tratta comunque di un divieto inutile e controproducente.


Personalmente non avevo mai pensato che esistessero limiti simili e, anzi, ho sempre visto accogliere bene eventuali “ragazzi piccoli”. Qui ovviamente si innesta una strana valutazione basata sul fatto che, poiché siamo tutti “ragazzi” e poiché personalmente ho cominciato a 14 anni a occuparmi di faccende inerenti l’informatica, il mio metro di giudizio è che uno è veramente “piccolo” in questo mondo quando ha meno di 12 anni. Insomma, se vedo un quindicenne davanti a una tastiera parto sempre dal presupposto che potrebbe saperne più di me. Quindi il rischio vero lo corro con i dodicenni pluricertificati (il più giovane c’è arrivato a 9 anni) che vanno in giro senza spillette. Ecco, forse dovrebbero rendere obbligatoria l’esposizione della spilletta di certificazione ai minori di 14 anni, hai visto mai che non ne incontri uno da qualche parte… 🙂

Perché usare FxCop

In Visual Studio 2005 (versione Team System, ma leggete i commenti per link a un’integrazione minima con le altre versioni) hanno fatto una cosa bellissima integrando FxCop con l’ambiente di sviluppo: nelle proprietà di un progetto è possibile abilitarne l’esecuzione post-compilazione abilitando “Enable Code Analysis” nelle proprietà del progetto (il tab è Code Analysis, se avete Visual Studio in italiano la traduzione spero sia qualcosa che ci assomiglia, comunque è l’ultimo tab in fondo a sinistra…).


Purtroppo non sono andati fino in fondo: tale voce per default è disabilitata, ed è un vero peccato vista la quantità di potenziali errori che FxCop è in grado di trovare. Prima di andare avanti, però, rispondo subito a chi potrebbe pensare “ma FxCop non è pensato per chi scrive librerie?”. In partenza sì, ma in realtà il 90% di quello che fa sono controlli su regole di buona scrittura del codice applicabili anche a un normale eseguibile.


Nella migrazione di alcuni programmi che sto facendo in questi giorni è di grande aiuto per individuare alcuni potenziali trabocchetti: per esempio uno è la chiamata a Dispose su SqlCommand, che come scrivevo 18 mesi fa è diventata necessaria in .NET 2.0 mentre non lo era in .NET 1.x, visto che il costruttore della classe chiamava GC.SuppressFinalize. Ottimizzazioni inutili che non ho mai sponsorizzato… ma nonostante questo ho riesumato del codice che aveva un paio di mancanze di questo tipo.


Di aiuti ce ne sono parecchi, così come trovo fondamentale anche usare ReSharper 2.0 (nonostante il refactoring di Visual Studio 2005, trovo quello di ReSharper più completo e avanzato, inoltre il controllo del codice nell’editor fornisce segnalazioni importantissime come errori nell’uso dei placeholder nelle stringhe di formattazione, classici errori che il compilatore non vede).


Veniamo ora a qualche consiglio pratico. Il primo istinto è quello di disabilitare le segnalazioni che possiamo considerare “inutili”: per esempio, compilando un’applicazione (e non una libreria) che magari usa delle librerie senza strong name, diventa inevitabile rinunciare a quest’ultimo nel nostro eseguibile. Capita. In generale, è preferibile usare l’attributo SuppressMessage che all’interno del codice può dare le direttive corrette a FxCop. Trovo che usare questo attributo nel codice sia di gran lunga preferibile a disabilitare le regole all’interno delle proprietà del progetto di Visual Studio 2005, perché si evita di disabilitare la regola in generale per eliminare un warning su caso particolare.


Ecco cosa scrivo nel mio AssemblyInfo.cs per evitare due warning inutili per un’applicazione che sto migrando:

[assembly: SuppressMessage( “Microsoft.Usage”, “CA2209:AssembliesShouldDeclareMinimumSecurity” )]

[assembly: SuppressMessage( “Microsoft.Design”, “CA2210:AssembliesShouldHaveValidStrongNames” )]

Unica eccezione che faccio: su alcune applicazioni disabilito completamente le GlobalizationRules, perché il rapporto costo/beneficio in questo caso è altissimo, visto che il beneficio per certi applicativi è nullo (ho a che fare con applicazioni che non interagiscono con l’utente e non avranno mai a che fare con lingue estere). Chiaramente bisogna valutare caso per caso.


A questo punto chi comincia a seguire il mio consiglio avrà due rimostranze: il lavoro iniziale può essere pesante (se non avete mai fatto girare FxCop di roba ne trovate sempre…) e i tempi di compilazione rallentano. Per il lavoro iniziale, vedetelo come un investimento per migliorare la qualità del codice – ripaga nel medio termine, anche solo per poter usare efficacemente FxCop in futuro. Per i tempi di compilazione, un’idea che ho è di disabilitare le segnalazioni in Debug (una volta portati i warning a 0) e lasciare le segnalazioni abilitate per la versione Release: in questo modo sulla compilazione “finale” per il rilascio di una versione emergono alcune magagne… In realtà sarebbe meglio lasciarlo sempre abilitato perché si potrebbero trovare prima certi errori, ma in definitiva questo dipende dalla velocità della macchina e dalla complessità dell’applicazione – anche qua è meglio valutare caso per caso.


Pillola finale: questo errore trovato da FxCop non l’avrei mai scoperto (anche se è quasi innocuo, lo ammetto).


throw new ArgumentException( “period”, “Invalid period, not a year nor a month” );


L’errore è il seguente:

Warning 9 CA2208 : Microsoft.Usage : Calls to System.ArgumentException’s constructor ‘ArgumentException.ArgumentException(String, String)’ should be in the order message, paramName instead of ‘period’, ‘Invalid period, not a year nor a month’. Note that the provided parameter name should have the exact casing as declared on the method.


Tradotto in italiano significa che i parametri sono invertiti (in realtà lui accerta che il secondo parametro corrisponda al nome di uno dei parametri in cui si trova la chiamata, ma è quanto basta). Non vale la pena avere un aiutante così?

Vantaggi nell’uso dei Generic

Oggi ho avuto la possibilità di migrare un programma basato su molti algoritmi che fanno largo uso di Collections da .NET 1.1 a .NET 2.0. Finalmente un “caso reale” con uso veramente intensivo di RAM e CPU (elaborazione massiva di molti minuti con allocazioni sopra il Gb di memoria virtuale) su cui verificare il vantaggio di alcune soluzioni.


Da una prima prova molto empirica, a parità di Framework (.NET 2.0) passare dalle vecchie Collection alle nuove basate sui Generics dà un leggero vantaggio prestazionale (7-8% in totale) che unito al vantaggio per il passaggio da .NET 1.1 a .NET 2.0 ha portato a un risparmio complessivo di quasi il 30% di tempo di CPU consumato in meno. Queste prove sono interessanti perché non si tratta di prove di laboratorio, ma di guadagni reali in applicazioni reali…


Per la RAM il risparmio complessivo è di pochi punti percentuali, ma il guadagno marginale sulle strutture allocate in array e code sarebbe certamente più elevato (ma non ce ne sono molte in questo scenario).

SandCastle – creare documentazione come quella di MSDN

Microsoft ha reso pubblico il tool usato internamente per documentare le classi di libreria del .NET Framework: il suo nome è SandCastle.


Ci sono molte informazioni di cui riporto i link: codice da scaricare, blog, slide con alcune spiegazioni (queste ultime sono la prima cosa che vi consiglio di leggere per capire meglio di che si tratta.


L’idea è piuttosto semplice: partendo dal file XML generato dal compilatore che contiene anche i commenti inseriti nel codice all’interno di opportuni tag XML (in .NET 2.0 si può fare anche da VB, con C# si può fare da sempre) e unendo a queste informazioni altre ottenute via Reflection dall’assembly compilato, si ottengono dei file di help nello standard usato anche da MSDN. Quindi i commenti in XML non sono più solo consumabili da Intellisense, ma anche l’unico mezzo per ottenere una documentazione completa ed efficace.

Dave Cutler lascia il team di Windows

Non sto a commentare le milioni di notizie relative al possibile/probabile ennesimo rinvio di Windows Vista. La mia attenzione è più su un dettaglio riorganizzativo (riportato da molte fonti ma che non gode di un comunicato ufficiale che altrimenti avrei riportato) che coinvolge anche Dave Cutler, “padre” storico di Windows NT (del kernel su cui gira anche Vista, insomma): al rilascio di Windows Vista andrà a lavorare nella divisione “Live”, che ingloba un po’ tutte le attività Internet (almeno, tutti quei servizi che hanno la sigla “Live” in mezzo).


Non si può fare a meno di intravedere una vera e propria “virata” all’orizzonte, che coinvolgerà un po’ più le fondamenta del sistema operativo a noi così familiare. O forse, più semplicemente, un tentativo di smuovere un po’ le acque e portare persone più “affamate” ai posti di comando, per poter essere più dinamici e rilasciare qualcosa in tempi meno eterni.


Rilasciare una nuova versione del sistema operativo desktop più diffuso sul pianeta più di 5 anni dopo la release precedente ha costituito per molti una bella garanzia di continuità, ma allo stesso tempo ha fornito a Microsoft un tempo enorme per partorire molto meno di quello che ambiziosamente veniva illustrato nel settembre 2003 (allora si chiamava Longhorn). Era inevitabile che ci fossero delle conseguenze.


Quello che più mi lascia perplesso è questo: nonostante .NET rappresenti il vero snodo cruciale per poter “sostituire” il sistema operativo sottostante (il che è anche un rischio per Microsoft…) il fatto che finora il sistema operativo non abbia nemmeno un servizio o una funzionalità “di base” che sfrutti .NET rende un po’ ambigua la scelta. Non a caso il nome WinFX è stato ridimensionato a .NET 3.0 – doveva eliminare Win32, che invece è ancora vivo e vegeto. Ma Windows Vista non fornisce una dimostrazione che la scelta sia saggia, perché nonostante tutto le prestazioni di Windows Vista non sono eccellenti. Scrivere codice in C o in C++ anziché nel CLR non è di per sé garanzia di prestazioni. Forse ormai ci sono le prove.


Sarei curioso di sapere quale è la strategia a lungo termine (5/10 anni, per capirci) e come è evoluta negli ultimi 2/3 anni. Chiarirebbe forse alcune mosse che oggi non appaiono così chiare.

Considerazioni sul parallelismo

Leggere Joel Spolsky è sempre stimolante, ma mi preme segnalare questo interessante articolo che tratta i fondamenti dell’integrazione del parallelismo all’interno del linguaggio (anche se non è diretto come si penserebbe al’inizio)


Credo comunque che anche Microsoft stia lavorando in termini di ricerca nel campo delle architetture necessarie per ottenere il massimo parallelismo. Sentiremo parlarne ancora, da qui in avanti.