DevCon 2005 feedback post-conference

DevCon 2005 è alle porte e stiamo già partendo per l’organizzazione di DevCon 2006. A breve maggiori informazioni sul prossimo appuntamento.


Abbiamo ricevuto molti feedback dai partecipanti, ma come sempre più ne riceviamo meglio è, quindi non pensiate che le mail che ci mandate restino lettera morta, tutt’altro.


In questi giorni abbiamo cercato di ragionare su cosa è andato bene e cosa è andato male.


Sembra che sia andato bene il contenuto dei due track, in particolare il track architetturale, oltre a essere il più seguito, ha avuto un grande ritorno con feedback molto molto positivi; qui forse non abbiamo sbagliato niente, ma se ci fosse qualche voce critica, è sempre bene accetta. Il track “dati, analisi e strumenti” era invece più discontinuo come contenuti (ma non poteva essere diversamente) andando ad abbracciare un parco di tecnologie molto ampio, da Office a SQL Server passando per Analysis Services e Integration Services; in generale la scelta di privilegiare gli aspetti “strategici” a scapito di un’overview più completa sembra essere stata digerita bene, ma anche qui se ci fossero voci fuori dal coro sarebbero sempre molto ben ascoltate.


La logistica sembra sia stata soddisfacente così come i servizi di ristorazione e i coffee break. Mi sembra anche che a pranzo ci fosse l’ambiente giusto per fare quattro chiacchiere e conoscere meglio i partecipanti, noi vorremo sempre parlare con tutti anche se non è fisicamente possibile, ma apparentemente a tutti i tavoli c’era una certa convivialità. Forse non è l’aspetto più importante di una conferenza, ma la possibilità di confrontarsi con chi fa lo stesso lavoro in realtà diverse è un valore che non va sottovalutato in eventi simili. Se possibile vorremmo riuscire in futuro a valorizzare questo aspetto, ogni partecipante porta con sé un tesoro di esperienze che può essere di grande valore.


Cosa non ha funzionato. La plenaria del primo giorno non è piaciuta, inutile girarci intorno. Troppo poco tecnica. Era uno degli esperimenti, cercare di dare una visione d’insieme. Forse non ci siamo riusciti, forse non siamo andati abbastanza in profondità, ma sicuramente se l’avessimo tolta nessuno si sarebbe lamentato. Meglio la plenaria del secondo giorno, ma forse era troppo breve? Qui abbiamo pareri discordanti, qualche commento in più ci farebbe bene.


Cosa non sappiamo valutare: diverse cose.


Orari: troppo corti o troppo intensi? Sicuramente rimodulare meglio il pomeriggio, 2 ore tirate sono troppe, anche senza coffee break una pausa ci vuole, soprattutto dopo pranzo. Dovremmo andare avanti a oltranza? Scavalcare la cena? Feedback graditi.


E sulla posizione dell’hotel? Era meglio andare in centro o allontanarsi di più da Milano? Infine, molti hanno criticato la data, pur essendosi iscritti. Troppo affollamento a novembre? Qualcuno non è venuto a causa di questo? Probabilmente sì, ma anche qui i feedback sono graditi, anche da chi non ha potuto/voluto partecipare.


Sale: è furbo avere il tavolo con la corrente o avreste preferito la tradizionale sedia senza niente intorno? Vi ha dato fastidio il vicino con il notebook aperto?


Cosa ci dite degli sponsor? Cosa avete gradito? C’è qualcosa che vi ha dato fastidio? Avreste voluto vedere una sessione in cui si smontava un server pezzo per pezzo per capire cosa c’è dentro un server da più di 80.000 euro?


Bene, i commenti sono aperti!

Il vero problema delle applicazioni on-line

Ieri pomeriggio un amico mi chiede (via messenger) se riesco a raggiungere Google. Non risponde. Gmail nemmeno, news.google neppure. Prima ipotesi: attentato? Un giro sul sito di CNN riduce questa probabilità. Il tempo di chiedere a qualche altra persona on-line in questo momento e il sito ritorna raggiungibile. Diamo la colpa a Interbusiness (eravamo entrambi su quella dorsale) e dimentichiamo la cosa. Brutto vizio che abbiamo (noi italiani) di trovare una colpa a casa nostra se possibile.


Oggi leggo che non è così, il problema è stato proprio di Google. E non sembra neppure che sia stata la prima volta. Tutto ciò induce a una riflessione, non tanto su Google quanto in generale sui servizi on-line (vedi i recenti annunci anche di Windows e Office Live): possono davvero sostituire le applicazioni off-line? Io qualche dubbio continuo ad averlo. Oggi, e nel futuro prossimo, la soluzione più ragionevole è un’integrazione tra servizi on-line e off-line. Insomma, gli smart client che tanto ci sono cari sembrano la soluzione ibrida migliore di cui possiamo disporre. Sul lunghissimo termine possiamo immaginare qualcosa di diverso? E’ difficile, ma ancora oggi esistono gruppi elettrogeni per garantire l’energia elettrica, ponti radio per garantire le telecomunicazioni, autobotti per l’acqua potabile. Cosa può garantire l’accesso a un servizio on-line? Per di più centralizzato (come sono oggi molti servizi, senza un data-center di backup in caso di disastro naturale)?


La nostra vita lavorativa dipende già dalla rete. Ma per periodi di tempo più o meno brevi possiamo farne a meno e lavorare lo stesso. Inevitabilmente, questa dipendenza aumenterà sempre di più. I servizi on-line hanno di fronte questa barriera: Internet, in quanto tale, si è diffusa grazie alla non-centralità del sistema. I singoli servizi possono cessare, il sistema nel suo complesso si tiene comunque in piedi. Quanto più dipendo da un singolo servizio, tanto più il vantaggio di Internet “non centralizzata” può venire meno. Credo che i servizi on-line si diffonderanno; ma credo anche che le applicazioni “desktop” non si estingueranno.

PromptSQL: decisione presa (troppo presto?)

Un mese fa (come avevo scritto in questo post) ho installato PromptSql, un’utility che consente di avere IntelliSense su Query Analyzer e SQL Server Management Studio. Nonostante non sia perfetto, il motivo che mi ha indotto all’acquisto è l’aver scoperto che una mia segnalazione/richiesta di fine ottobre era già stata implementata in una nuova release (anche se beta) del 7 novembre. Quindi è una sorta di investimento sulla fiducia, cercherò di suggerire nuovi miglioramenti sperando che arrivi a essere un prodotto più completo.


Rivedendo i commenti mi sono però reso conto che non ho fatto una prova comparativa: mi erano infatti stati suggeriti Aqua Data Studio (tool sostitutivo di Query Analyzer, multidatabase peraltro, che giustamente costa anche un po’ di più, 149$) e QuerySense, un tool che mi sembra scritto da un italiano (magari proprio il Michele che l’ha segnalato) e anche abbastanza interessante a vedere gli screenshot. Purtroppo ho avuto tempo zero per provarli (DevCon è alle porte…), se qualcuno volesse farlo e confrontare in particolare QuerySense con PromptSQL, i commenti sono aperti.


 

Frustrazioni da hardware troppo potente

Premetto che questo post va interpretato in parte con una certa ironia e leggerezza, anche se le considerazioni finali sono più serie…


Oggi ho vissuto la frustrazione di non riuscire a saturare un server a disposizione. A DevCon avremo un server particolarmente potente gentilmente messo a disposizione da IBM, uno degli sponsor dell’evento. Grande è stata la mia sorpresa (da cui la frustrazione) di non riuscire a sfruttare appieno le risorse a disposizione.


Primo problema: 28Gb di RAM sono tanti. La somma dei database che uso per le demo arriva intorno ai 10Gb, e ovviamente è difficile avere una serie di query che vada a sfruttare tutti questi dati e indici, quindi l’occupazione di memoria in condizioni di cache massima è addirittura inferiore a questo valore, almeno per la parte SQL Server. Quindi qui, a parte caricare qualche macchina virtuale con 3/4 Gb di RAM a disposizione, non potevo fare molto. Ah, duplicare dei dati tanto per aumentare le masse non era una politica condivisibile, visto che vogliamo fare delle demo il più possibili reali (raddoppiando i dati effettuiamo una distorsione nella distribuzione di questi ultimi ed è comunque difficile raddoppiare i dati lasciandoli anche consistenti, condizione indispensabile per una corretta elaborazione dei cubi).


Però le CPU, queste speravo di poterle usare tutte. Grazie alla parallelizzazione di Analysis Services in fase di elaborazione, contavo di avere un bel carico di query in parallelo. Beh, che dire.. questa magia avviene ma dura meno di due secondi, e non perché ci sia qualcosa che non va, ma semplicemente perché dopo due secondi ha elaborato il grosso delle dimensioni (una quarantina) del cubo. A questo punto partono poi le elaborazioni dei cubi veri e propri che però, ahimé, non sono partizionati. Ecco quindi che la scalabilità è limitata dal fatto che alcune query che caricano sequenzialmente i dati di una tabella non possono sfruttare le tante CPU a disposizione. Anche le query ORDER BY effettuate per le misure DISTINCT soffrono di un problema analogo, nel senso che non scalano su più CPU.


A questo punto qualcuno potrebbe dire: crea qualche partizione sui cubi e riparti… Beh, sarebbe una buona idea se poi le query verso le tabelle dei fatti restassero ottimizzate, ma questo non può avvenire senza partizionare a monte le tabelle dei fatti… Insomma, non è fattibile in tempi brevi e non è ragionevole per lo scenario reale presentato.


La morale di questa storia è che per sfruttare un hardware così potente bisogna sfruttare il parallelismo, e anche avendo un’infrastruttura basata su prodotti intrinsecamente multithreading (come SQL Server e Analysis Services) è necessario ragionare in modo diverso e fare delle operazioni che su un computer con uno o due processori potrebbero risultare addirittura controproducenti.


Qui finisce la storia e inizia la ricerca. Uno dei limiti alla scalabilità di Analysis Services 2005 è l’uso di misure Distinct Count. In realtà si può ottenere lo stesso risultato con tecniche diverse, che sfruttano meglio il parallelismo a discapito della complicazione del modello multidimensionale. Spero di poter tornare sull’argomento nei prossimi mesi, ma sfide simili saranno sempre più frequenti ora che per rispettare la legge di Moore bisogna aumentare la potenza in orizzontale (più CPU) anziché in verticale (più clock), e non solo a livello di programmazione multithread ma anche a livelli più architetturali più alti, con conseguenze evidenti nel disegno di un’applicazione.

Perché un case-study

Stasera preparando DevCon (non si pensa mai di aver finito fino a che una conferenza non comincia, ma è un altro discorso…) mi sono soffermato a pensare sui motivi per cui si fanno i case study.


Il più delle volte i case-study nascono da un’esigenza commerciale: dimostrare al mondo (o anche solo al mercato) che un proprio prodotto è in grado di rendere i clienti soddisfatti e di giustificarne il prezzo. Applicato all’informatica, questo vuol dire avere un ritorno dell’investimento, sotto diversi punti di vista non soltanto economici.


Si dà però il caso che un case-study sia costruito a partire dall’esperienza delle persone che hanno effettivamente realizzato e/o utilizzato il prodotto oggetto del case-study. Ecco allora che subentra un fattore umano, probabilmente di gratifica personale, che porta ad azioni apparentemente irrazionali: il case study, di per sé, non sempre giustifica l’investimento volontario delle persone che vi partecipano; insomma, spesso ho visto fare straordinari e attività extra senza che nessuno lo richiedesse.


Spesso il risultato finale del case-study non trasmette appieno il reale valore di esperienza acquisita che potrebbe essere “ritrasmessa”. Si torna al punto di partenza, dove il case-study è uno strumento di marketing. Ma quando il case-study diventa “tecnico”, ecco che sorgono grandi opportunità formative e di apprendimento.


Per tornare al nostro mondo, Microsoft ha realizzato un case-study dal punto di vista prettamente tecnico che riguarda un progetto di Business Intelligence con SQL Server 2005: si chiama Project REAL e riporta le lezioni tratte sul campo in un progetto di BI che coinvolge grandi moli di dati. Ci sono moltissimi spunti interessanti, anche se come al solito bisogna usare la giusta chiave di lettura, perché non sempre si ha a che fare con moli di dati così grandi e di conseguenza alcuni approcci potrebbero non essere ottimali in scenari più “umani”.


Anche a DevCon 2005 cercheremo di sfruttare la tecnica del case study molto spinto sul lato tecnico. Approfondire le tecnologie presentate valutando scenari reali consente di avere una visione molto più critica (nel senso “obiettivo” del termine e non in quello pregidizialmente negativo). A differenza di REAL, però, noi concentreremo le nostre attenzioni su problematiche meno critiche in termini di volumi assoluti, ma decisamente più complesse dal punto di vista della modellazione dei dati, avvicinandoci di più alle realtà che più spesso si incontrano nel mercato italiano.


 

Report Builder e UDM

Report Builder consente di accedere ai dati attraverso un modello che descrive i dati in termini di entità e campi. Il modello è definibile a partire da un modello relazionale (Data Source View) o “ricopiando” il modello UDM definito in un database di Analysis Services. Quest’ultima operazione è tutt’altro che ovvia e deve avvenire da SQL Server Management Studio o da Report Manager. Purtroppo temo di aver scoperto un bug in questa operazione che si scatena con le impostazioni internazionali in Italiano – si può ovviare al problema definendo le impostazioni in inglese da pannello di controllo, ma certo è fastidioso.


Per i dettagli rimando al mio post in inglese. Ricordo anche che su SQLBI.IT c’è un’area forum dove è possibile approfondire tutti questi aspetti. Nonostante gli anni di sviluppo e test, la parte “BI” di SQL Server 2005 presenta qualche difetto di gioventù, ma nonostante tutto io sono già convinto che non vale la pena tornare indietro (o rimanerci per chi ancora non ha fatto il salto).

Fuzzy Lookup e normalizzazione indirizzi

Una delle trasformazioni di SSIS (SQL Servere Integration Services) che analizzeremo in uno scenario reale a DevCon 2005 è la Fuzzy Lookup. Grazie ad algoritmi statistici, questo tipo di trasformazione effettua un’operazione di ricerca di chiavi identiche o semplicemente “somiglianti” ad altri valori noti. L’esempio di utilizzo è quello della normalizzazione dei nomi delle località presenti in un database (classiche anagrafiche clienti/fornitori): come si potrà vedere, il Fuzzy Lookup è uno strumento che aiuta moltissimo, anche se va utilizzato in maniera corretta e guidata, senza pretendere che possa assolvere al 100% del lavoro senza commettere errori.


I numeri che vedremo dovrebbero confortarci nel pensare di poter utilizzare questa tecnica in produzione, con opportuni accorgimenti che consentano di intervenire tempestivamente nei casi in cui l’algoritmo da solo non riesca a farcela. Rispetto alle versioni beta che avevo usato tempo addietro, l’algoritmo nella versione finale lavora abbastanza bene anche con nomi italiani (si pensi alle abbreviazioni S.Giovanni / San Giovanni e simili). Bisogna però scendere a compromessi e trovare il bilanciamento ideale nei parametri anche in funzione della qualità del database di provenienza dei dati da normalizzare: per esempio, fa una certa differenza poter dare per scontato che la provincia sia sempre assolutamente giusta oppure dover prevedere che anche quest’ultima contenga alcuni errori.


Il vantaggio di fare queste demo usando dati di provenienza reale (opportunamente mascherati solo per tutelare la privacy) consente di capire più rapidamente quali siano le tecniche di utilizzo più corrette (senza aggiungere che in questo campo la documentazione esistente è ancora un po’ lacunosa).

SQL Server 2005 Feature Pack

Il SQL Server 2005 Feature Pack è indispensabile per chi si occupa di Business Intelligence (ma non solo). Si tratta in realtà di una serie di download che riepilogo qui:



  • Microsoft ADOMD.NET

  • Microsoft Core XML Services (MSXML) 6.0

  • Microsoft OLEDB Provider for DB2

  • Microsoft Operations Manager 2005 Management Pack for Microsoft SQL Server 2005

  • Microsoft SQL Server 2000 PivotTable Services

  • Microsoft SQL Server 2000 DTS Designer Components

  • Microsoft SQL Server Native Client

  • Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB Provider

  • Microsoft SQL Server 2005 Backward Compatibility Components

  • Microsoft SQL Server 2005 Command Line Query Utility

  • Microsoft SQL Server 2005 Datamining Viewer Controls

  • Microsoft SQL Server 2005 JDBC Driver

  • Microsoft SQL Server 2005 Management Objects Collection

  • Microsoft SQL Server 2005 Mobile Edition

  • Microsoft SQL Server 2005 Notification Services Client Components

  • Microsoft SQL Server 2005 Upgrade Advisor

  • Microsoft .NET Data Provider for mySAP Business Suite

  • Reporting Add-In for Microsoft Visual Web Developer 2005 Express

C’è un  po’ di tutto: ridistribuibili lato client, driver OLE DB vari, il driver JDBC per chi da J2EE deve connettersi a SQL Server, una serie di componenti per supportare la compatibilità con DTS/DSO/DMO di SQL Server 2000. Qualcosa credo che ci sia già nei CD/DVD di installazione del prodotto, ma è comodo avere questo link il giorno che si avrà bisogno del componente XYZ senza averlo a portata di mano.

Prototipi di interfaccia utente con .NET 2.0 (e Windows Forms)

Chris Sells segnala alcuni esempi di interfacce utente create con Windows Forms per .NET 2.0, tra cui Money e Outlook 2003. Ho sempre pensato che l’interfaccia utente di Money sia l’approccio migliore per un gestionale in Windows dove sia prevalente la parte di inserimento dati (prima nota, fatture, pagamenti, ecc.). Subito dopo DevCon spero di riuscire a dare un’occhiata per vedere quanto sia effettivamente realizzabile questo tipo di interfaccia con Windows Forms 2.0 (Money mi sembra basato anche su DHTML e non è così banale rifarlo con le API di Windows).


Certo con WPF (alias Avalon) alle porte verrebbe voglia di saltare a pié pari Windows Forms, ma sicuramente per chi deve vendere o far usare software entro un arco temporale inferiore ai due anni, conviene guardare bene questi esempi e passare subito a Windows Forms 2.0.

SQL Server Standard

Segnalo che è possibile scaricare gratuitamente il PDF dell’ultimo numero di SQL Server Standard, ottima rivista su SQL Server che in questo numero è tutta dedicata alla Business Intelligence. Ci sono diversi articoli su SQL Server Integration Services ben scritti e approfonditi (non è il solito tutorial, insomma) che affrontano aspetti specifici (migrazione, uso di XML, chiamate a Web Service, componenti script sincroni e asincroni). La rivista è collegata a un’altro ottimo sito, SqlServerCentral.com.