Oggi inizia il secondo giorno di Microsoft SharePoint Conference 2008 e in coincidenza di questo evento debutta il sito di Devlead, che non è un errore ortografico ma una costola di Devleap, che nasce con il nuovo look grafico che è debuttato a Devcon e che arriverà presto anche sul nostro sito principale.
La conferenza ha chiuso le iscrizioni dieci giorni prima del suo inizio, quasi raddoppiando il numero di partecipanti della precedente edizione. L'interesse intorno a SharePoint è veramente grande, ma d'altra parte si farebbe un errore a considerarlo soltanto un prodotto. Si tratta di una piattaforma, che attira sia le società che sviluppano soluzioni informatiche, sia "clienti finali" che hanno un loro team interno per la gestione dei sistemi informativi. Credo sia un segnale ottimo, perché indica come venga compreso dal mercato che dare completamente in outsourcing una soluzione basata su SharePoint sia un approccio valido magari per lo sviluppo iniziale - ma, nel tempo, la manutenzione ordinaria viene meglio soddisfatta con skill interni all'azienda, visto che è difficile pensare a SharePoint come a una scatole chiusa che una volta in produzione non verrà mai riaperta.
Io ho tenuto una sessione sulla creazione di dashboard con SharePoint (integrato ad altri prodotti come Reporting Services e PerformancePoint Server) e la prossima settimana sarò a Seattle per la Microsoft Business Intelligence Conference, dove presumibilmente arriverà qualche annuncio che, indirettamente, avrà un impatto anche sulle cose che ho mostrato in conferenza (lo dico a beneficio di chi a seguito la sessione). Ho già fatto qualche speculazione su cosa potrebbe arrivare, ma ancora non sono chiari i dettagli. Ancora pochi giorni e avremo più notizie.
Da quando è uscito SQL Server 2005, ho lavorato a molti progetti di Business Intelligence usando Analysis Services, Integration Services, Reporting Services e altri prodotti / servizi. Grazie alla collaborazione con Alberto Ferrari (che partecipa con me a mantenere il sito SQLBI), nel tempo abbiamo sviluppato una vera e propria metodologia che si adatta a questi strumenti ma che allo stesso tempo integra le metodologie esistenti (Inmon e Kimball in particolare) in un insieme consistente di pattern architetturali e implementativi.
Pur avendo scritto molto materiale, è venuto il momento di raccogliere feedback e confrontarci con una community più vasta per raccogliere critiche e suggerimenti. Abbiamo cominciato quindi a pubblicare degli articoli (il primo oggi) in forma di bozza. Abbiamo anche aperto un forum dedicato per raccogliere tutti i feedback e aprire una vera e propria discussione. Il forum è in inglese, se preferite potete anche scrivermi direttamente in italiano.
Una delle prime domande sarà sicuramente "perché un'altra metodologia?" - per rispondere subito, ho scritto un post in inglese in cui presento i ragionamenti dietro alla creazione di una metodologia separata. Uno svolgimento più esteso del confronto tra Kimball, Inmon e SQLBI è contenuta nel primo articolo, Introduction to the SQLBI Methodology.
Spero di ricevere molti feedback... Buona lettura!
Segnalo che sul blog inglese ho pubblicato un altro post della serie di cui ho accennato una decina di giorni fa. Tra poco arriverà anche il contenuto più sostanzioso, consistente in un paper piuttosto articolato sulla metodologia da usare per sviluppare soluzioni di BI con i servizi di SQL Server. L'argomento odierno è poi una delle motivazioni che ci hanno portato a lavorare a questa metodologia: la possibile indipendenza della (metodologia) stessa dagli strumenti utilizzati. Sono graditi i feedback (anche in italiano in questo blog, eventualmente) rispetto alle considerazioni fatte.
Segnalo volentieri questo testo completamente gratuito: Data Structures and Algorithms: Annotated Reference with Example. Si tratta di una versione ancora preliminare del testo che stanno scrivendo Granville Barnett and Luca Del Tongo. Il testo tratta strutture dati (linked list, binary trees, heap, ecc.) e algoritmi (quick sort, merge sort, priority search, ecc.).
Una delle cose che mi ha più colpito è che si tratta di un testo molto diretto, che va subito al punto, con gli algoritmi descritti in pseudo-codice così da poter essere implementati in qualsiasi linguaggio. In ogni caso, l'implementazione in C# è già disponibile e ne avevo già parlato a gennaio.
Sul blog in inglese dedicato alla BI con SQL Server ho iniziato a pubblicare una serie di post dedicati alla metodologia da usare per sviluppare soluzioni di BI con la piattaforma SQL Server. Si tratta di un lavoro a 4 mani realizzato con Alberto Ferrari, con cui lavoriamo al sito SQLBI. Purtroppo non ho il tempo di tradurre il materiale in italiano, ma invito chi si occupa di soluzioni di BI a seguire i post che scriverò prima della pubblicazione di alcuni whitepaper che tratteranno l'argomento in maniera più organica.
Si tratta di argomenti poco trattati nel contesto di soluzioni simili sviluppate con tecnologie Microsoft. Se avrete dei commenti da fare, potete anche scrivermi direttamente (e in italiano) per darmi i vostri feedback. Anche le segnalazioni di approcci alternativi e/o documentazione simili saranno i benvenuti.
Il primo post della serie riguarda la classificazione delle soluzioni di BI (small, medium, large). Tutti dicono sempre di avere tanti dati, ma il problema non è il volume in sé quanto il tempo necessario a elaborarli. E già a partire da questa semplice definizione mi aspetto opinioni contrastanti...
Ho appena scritto un post sul blog in inglese dove spiego un problema veramente curioso che ho dovuto risolvere oggi. In breve: su una tabella heap, se si cancellano e poi inseriscono righe, lo spazio delle righe cancellate non viene recuperato (tranne che in alcuni casi particolari). La cosa può portare a problemi di spazio su disco e/o di prestazioni molto lente.
Per fortuna, questo comportamento è descritto in un articolo di knowledge base: KB 913399.
Su MSDN è possibile trovare un blog sulla progettazione delle funzionalità di Windows 7 (la prossima versione di Windows, dopo Vista). Chi ci scrive è addirittura Steven Sinofsky, a nome del team di sviluppo.
Al momento non ci sono notizie importanti, ma è sicuramente un feed da seguire prossimamente.
Il mio blog è nato nel 2003, anche se i primi esperimenti li avevo fatti già nel 2002. All'epoca il fenomeno dei blog era agli albori, in 5 anni quello che era uno strumento un po' di nicchia è diventato uno strumento di massa, usato per creare contenuti di ogni tipo, relegando i blog "tecnici" (come il mio) a una piccola nicchia.
Negli USA è già qualche anno che i blog "aziendali" sono una realtà consolidata (tanto che ormai esistono anche policy aziendali in alcune corporation rispetto al loro uso) e come tale viene usata anche per "tastare il polso" dell'azienda. Non parlo di blog istituzionali, ma di quei blog creati da dipendenti (a volte in forma anonima, a volte no) per parlare della loro azienda vista dall'interno.
In Italia, per una questione più culturale che di massa critica, questo fenomeno è ancora poco diffuso. La mia citazione di "questione culturale" è esemplificata da un episodio accaduto oggi, che probabilmente passerà più inosservato di quanto avrebbe potuto visto il periodo ferragostano. Oggi Repubblica ha pubblicato un articolo che parla del blog di un assistente di volo di Alitalia, con tanto di foto catturate dal blog stesso. Già nel 2005 mi era capitato di tirare in ballo il rapporto tra blog e testate giornalistiche in un caso relativo a questioni più "tecniche". Da allora le cose sono migliorate, se non altro perché è diventata consuetudine anche per le "testate ufficiali" mettere link espliciti ai blog usati come fonte. In questo caso il link esiste, anche se forse si potrebbe discutere sull'uso fatto delle foto (a quanto pare senza chiedere autorizzazione preventiva all'autore).
L'aspetto di questa vicenda che mi pare interessante è il "rovesciamento" di ruoli. Il blog fa la notizia, il quotidiano la riprende. Il blog esiste dal 2005 ma fino a ieri era noto solo a una ristretta cerchia di persone. In poche ore ha ricevuto oltre 30.000 visite (se fosse stato fatto a settembre sarebbero state sicuramente almeno 3 volte tanto) ma la cosa che più mi lascia stupito sono i commenti. Ce n'è di molti tipi, ma le due categorie più numerose sono quelli che approvano e quelli che preferirebbero l'auto-censura. Dirò la mia: ho letto un po' di post di questo blog, anche di mesi/anni indietro, e tutto si può dire tranne che questo sia un blog "delatorio". La mia esperienza è che chi si prende la briga di scrivere un blog "aziendale" lo fa perché all'azienda ci tiene, anche quando è estremamente critico nei suoi confronti (come nel caso di Mini-Microsoft che probabilmente ho già citato in passato). Dal mio punto di vista, invece, questo blog è meglio di quanto l'azienda (in questo caso Alitalia) non faccia "istituzionalmente" per migliorare le relazioni con il pubblico. Lo dico anche da (ex) utente più volte bastonato e maltrattato dalla nostra compagnia di bandiera.
Tralasciando però il caso specifico, è il meccanismo di comunicazione che mi interessa. Censurare questo tipo di blog è impossibile. Con un minimo di precauzioni, può essere fatto in forma anonima e difficilmente riconducibile al responsabile se non tramite un'inchiesta giudiziaria. Tentare di limitarne la creazione e diffusione sarebbe comunque poco lungimirante, perché al momento i dati (per lo più di casi americani) dicono che la percezione esterna di un'azienda migliora quando i propri dipendenti sono liberi di parlarne che non quando ciò viene limitato o (peggio) controllato. Il giornale che fa la notizia partendo da un blog corre un paio di rischi: da una parte l'uso di fonti non verificate/verificabili, dall'altra la distorsione del contenuto che poi il lettore può verificare di persona andando a controllare personalmente la fonte. Secondo me questo dovrebbe, alla lunga, aiutare a rendere i giornalisti più responsabili nel creare il servizio, pesando meglio le parole. Il caso esemplificativo (nel blog citato prima) è la discussione nata attorno a un post che il giornalista trasforma in un possibile problema di sicurezza (la cosa in realtà viene poi ingigantita soprattutto nei tanti commenti che potete vedere nei post linkati).
Per dirla tutta, l'articolo deve necessariamente sintetizzare e riportare note di colore che lo rendono interessante - mi è capitato di vedere distorsioni ben peggiori quando conoscevo bene i fatti che si celavano dietro un pezzo. E il trasferimento di traffico dice anche che, oggi, il giornale "ufficiale" comanda ancora e guida il traffico dei lettori, anche sul web. Però, allo stesso tempo, questi episodi presentano a un numero sempre più vasto di persone (in ordini di grandezza!) le potenzialità offerte dai blog. Non credo che le testate giornalistiche, così come le conosciamo oggi, siano destinate a sparire. Ma certamente cambieranno, anche se il come è ancora in fase di definizione. Resta da vedere quanto tempo ci metteranno le aziende italiane ad adeguarsi al fenomeno dei "blog aziendali" - per ora molte fanno probabilmente la cosa più semplice, che è non pensarci (basta leggere i disclaimer di alcune mail aziendali per capire quanto sia ancora inconcepibile concedere questa libertà espressiva).
UPDATE: poco dopo il mio post, il blog di cui ho parlato è stato chiuso, a quanto pare dall'autore stesso. In realtà adesso allo stesso URL compare un nuovo blog, che ha "preso" il nome appena liberato, così prenderà un po' di traffico. Come ho detto nei commenti, è un peccato l'esito finale di questa vicenda, un'occasione persa.
Uno dei problemi introdotti da WPF (e più in generale dalle più recenti tecnologie per sviluppare interfacce utente, partendo già da Flash) è la mancanza di un paradigma predefinito per l'interfaccia utente, che allo stesso tempo concede maggiore libertà ma anche un più grande problema "interpretativo" che non sempre viene risolto al meglio. La problematica mi incuriosisce da tempo e, sebbene non possa permettermi di occuparmene "professionalmente", ho letto tra le altre cose il libro Sketching User Experiences di Bill Buxton.
Uno dei dubbi che mi è venuto leggendolo è la necessità di trovare "esperti" di disegno dell'interazione con l'utente (attenzione, non parliamo di grafica!) per arrivare a dei risultati significativi. Oggi però ho letto questo articolo che descrive come le tecniche di "sketching" siano state adottate nella progettazione di ANTS Profiler 4 (se vi interessa la beta andate qui). In questo caso c'è stato un lavoro di squadra, anche perché molti del team sono anche potenziali utenti del prodotto stesso e questo semplifica le cose.
Lo ammetto: sono per l'eliminazione della carta, ma quando questa è inutile. Nella fase iniziale di progettazione (si tratti di un'interfaccia, di un'architettura o dell'organizzazione di un evento) carta e penna (e magari pennarelli colorati) mantengono un ruolo importante.
Ho appena letto questo articolo su SDTimes che fa alcune interessanti considerazioni sull'aumento della complessita del .NET Framework e soprattutto sulla sovrapposizione di alcune tecnologie, traendo spunto dall'annuncio del rilascio appena avvenuto di .NET 3.5 SP1. Per esempio: esistono due modelli per l'interfaccia utente (Windows Forms e WPF). Esistono due librerie -stile ORM- in parte concorrenti come LINQ to SQL e ADO.NET Entity Framework.
La notizia è che Microsoft percepisce il problema e pensa di risolverlo con tecnologie come il Client Profile che debutta in .NET 3.5 SP1 (in breve: si può installare solo una parte del .NET Framework contenente gli assembly utili per il client tralasciando quelli pensate più per applicazioni lato server).
Non so se il problema sia riconducibile solo alle problematiche di deployment, sinceramente al giorno d'oggi mi pare più problematico fare le scelte giuste in fase di disegno e sviluppo che non pensare che la distribuzione di nuovi componenti (che poi sono l'aggiornamento di una parte del sistema operativo...) possa costituire IL problema principale. Semmai, ci sarebbe da discutere se sia meglio distribuire alcune classi come parte del framework o come assembly distribuibili anche in modo "privato". Per esempio... LINQ to SQL quando si chiamava ancora DLINQ (in Beta) poteva essere distribuito con una serie di assembly privati, ora che è stato rilasciato è un pezzo di .NET e, come tale, va a finire nella Global Assembly Cache e, per i soliti motivi di compatibilità, è poco probabile che versioni future introducano dei "breaking changes" significativi, anche qualora sarebbe molto utile farlo. Mi chiedo se non sarebbe meglio introdurre delle nuove tecnologie in una forma più leggera (ma rilasciata e supportata, non solo quando sono in beta) e poi "annegarle" nel .NET Framework "ufficiale" solo una volta arrivate a una versione 2 o 3. Credo che l'evoluzione potrebbe essere migliore e non si creerebbero troppi problemi a chi vuol fare early adoption (un conto è distribuire degli assembly privati, un altro è "obbligare" ad aggiornare il .NET Framework - non è che sia impossibile ma i tempi sono diversi specialmente in reti di una certa dimensione, dove queste cose vanno pianificate per tempo).
Il 15 e 16 ottobre 2008 a Londra si terrà la prima edizione del Virtualization Congress.
Il motivo per cui ne scrivo è almeno duplice. Pur non essendo un esperto di virtualizzazione (nel senso sistemistico del termine) ho usato prodotti di virtualizzazione sin dagli albori e attualmente non potrei farne a meno per tutta l'infrastruttura di sviluppo che uso quotidianamente. Nonostante questo, non sono ancora totalmente convinto di virtualizzare alcune cose (come SQL Server in ambienti dove le prestazioni sono importanti) ma ciò non toglie nulla ai vantaggi di questa tecnologia.
L'altro motivo è più personale: conosco bene Alessandro Perilli e ho seguito il suo sito virtualization.info sin dai primi post. Una conferenza internazionale indipendente sulla virtualizzazione è un suo preciso obiettivo da anni e tra pochi mesi questa conferenza sarà realtà. A Londra, con speaker del calibro di Mark Russinovich (per rimanere tra quelli che chi segue questo blog probabilmente conosce). Mark ha anche registrato un video promozionale per la conferenza.
Insomma, i fatti parlano da soli, non serve che aggiunga commenti...
Chi fa il nostro lavoro usa un motore di ricerca più volte al giorno. Ok, questo lo fanno tutti, ma per noi "sviluppatori" è diventato più comodo cercare la documentazione on-line che sui dischi locali.
Inutile girarci intorno: Google per ora resta il motore migliore per cercare documentazione anche sui siti di Microsoft. Live Search migliora ma, purtroppo, resta ancora indietro. Va detto però che nel tempo Google ha fatto qualche passo indietro, nel senso che è soggetto a interferenze di siti "inutili" (con contenuti riciclati anziché puntare all'originale) molto più di quanto non lo fosse in passato.
Stamattina ho voluto provare Cuil, che pur non essendo migliore di Google (e forse nemmeno di Live Search, almeno dal punto di vista "ricerca di contenuti tecnologici) ha qualcosa di interessante. Prima di tutto il layout grafico: risultati su 3 colonne (si può passare a 2 cliccando in basso a dx), impaginati in modo curato, senza una classifica vera e propria ma i primi 4-6 risultati che sono ugualmente "accessibili" nella prima pagina dei risultati. Poi, soprattutto, l'uso di foto. Che sarebbe bello se fossero giuste, nel senso che mediamente una foto su due è completamente fuori contesto (per esempio: perché vedere la copertina di Programming Visual Basic 6.0 nel link corrispondente al libro Programming Microsoft LINQ? Se volete provare, scrivere "Programming LINQ", non è uno dei primi risultati ma lo trovate in prima o seconda pagina). Ultimo, quando la ricerca dà molti risultati, compare un tab che li organizza per parole chiave o sezioni. Lo vedete se scrivete un nome che può corrispondere a molti nomi/termini, per es. Hudson, Pat, Rossi, Italy...
Velocità: mi sa che dipende dal carico dei server. In alcuni momenti è velocissimo, in altri si aspetta qualche secondo.
Responso: è certamente un motore giovane e va rivisto tra qualche mese. Può essere interessante riprovarlo per ricerce "non tecniche", anche se con l'abitudine a interpretare i risultati di Google può essere difficile all'inizio abituarcisi, anche se l'occhio resta decisamente più appagato.
Periodicamente ricevo mail con richieste di chiarimenti in merito ad alcuni post (scritti anche diversi anni fa) relativamente alla gestione della memoria (e in particolare della memoria virtuale e del paging file) di Windows.
Mark Russinovich ha scritto un post che aggiorna i concetti includendo anche le versioni a 64 bit di Windows. La sostanza non cambia, ma è un post che vale la pena leggere se volete una spiegazione chiara di cosa Windows fa della memoria del vostro computer. Se sapete già tutto, vale la pena vedere il post anche solo per ammirare il Task Manager di un server con 2TB di RAM (non è un errore). Notare che nello screenshot ci sono 96Gb di memoria usata e vedere quanto è basso l'indicatore vi fa capire meglio di mille parole cosa significa 2TB di RAM. Volevo scrivere un commento finale adeguato, ma non trovo le parole...
Recentemente ho scritto alcuni post in inglese nel mio blog su LINQ:
Purtroppo non ho tempo di scrivere tutto in due lingue, per questo segnalo a chi usa LINQ di dare un'occhiata a questi post, in particolare all'ultimo (Distinct e OrderBy) che rischia di far perdere molto tempo perché può far pensare a un bug della libreria, quando in realtà (come direbbe Microsoft con una frase un po' irritante) si tratta di un comportamento "by design".
Buona lettura.
A PDC 2008 verrà presentata la nuova versione di C#, che sarà appunto la 4.0. Al momento non sono disponibili specifiche o dettagli tecnici, ma questa intervista al team che progetta il linguaggio, guidato da Anders Hejlsberg, anticipa le considerazioni e le linee guida che sono state adottate per arrivare alla nuova versione.
Tra i temi trattati: programmazione funzionale, linguaggi dinamici (e C# resterà un linguaggio statico) e soprattutto programmazione concorrente. Ricordiamoci che C# 4.0 sarà rilasciato nel 2009/2010, verrà usato per scrivere i programmi che saranno rilasciati nel 2011/2012 e per allora un desktop con 4 o 8 core sarà qualcosa di assolutamente normale, mentre sui server parleremo di core usando 2 o 3 cifre.
Ripeto, non ci sono dettagli e il webcast dura 50 minuti - non si impara nulla, ma è una conversazione interessante da vedere in qualche ritaglio di tempo.
More Posts
Next page »