Robot e Mesh

Posto non molto tecnico, pur parlando di tecnologia.

Primo argomento, i Robot. Microsoft ha organizzato una competizione chiamata RoboChamps (già solo il sito in Silverlight vale la pena) che consente a chi usa Microsoft Robotics Developer Studio di far esercitare il "suo" robot in un'arena dove l'obiettivo non è distruggere tutto, ma più semplicemente uscire da un labirinto, fare un sistema di guida automatica, passeggiare su Marte e raccogliere dati da mandare sulla Terra, salvare persone intrappolate dopo un terremoto e vincere una gara di Sumo tra robot. Certo, alla fine il torneo è una competizione che porterà il codice dal simulatore al mondo reale (robot veri!) e il gran finale con robot reali sarà a PDC 2008. Ah, già, quest'anno a fine ottobre ci sarà la PDC, la conferenza dove vengono di solito annunciate le novità più importanti dei prossimi anni per gli sviluppatori che lavorano con tecnologie Microsoft. La competizione servirà a indorare la pillola?

Leggendo alcuni articoli (tecnici e non) su Mesh ho percepito l'idea dei giornalisti che Microsoft stava "finalmente" puntando a un modello non più basato su Windows. In realtà, sarebbe più corretto dire "non più basato solo sul desktop". Per capire la differenza date un'occhiata a questa demo che spiega meglio di molte parole cosa si può fare con Mesh. Purtroppo la beta non è ancora disponibile a tutti, comunque l'idea mi sembra molto più evolutiva (dal punto di vista di Windows) che non rivoluzionaria. Chiaramente è ancora presto per fare commenti e predire come sarà adottata questa tecnologia, però in un certo senso è come se piano piano si realizzassero cose che si erano immaginate già parecchi anni fa (in particolare da quando si cominciò a parlare di Web Services). Per inciso, guardando questa demo ho scoperto Channel 10: una manna se volete perdervi in demo e preview varie… come questo post su Microsoft Surface che punta a una prova reale (non una demo fatta su un palco).

Cosa dicono di LINQ

La settimana scorsa ho avuto l'opportunità di presentare alla European PASS Conference 2008 il mio lavoro sulle relazioni molti-a-molti tra dimensioni in Analysis Services e la possibilità di usarle per scopi "non convenzionali" nella modellazione multidimensionale. Chiaramente, in una conferenza su SQL Server, questo non era l'argomento più "caldo" e ciò di cui mi sono trovato a parlare spesso con partecipanti e speaker riguardava direttamente o indirettamente LINQ.

Purtroppo, alcune delle preoccupazioni che io e Paolo condividevamo prima di scrivere due libri sull'argomento si stanno rivelando reali. Due "problemi" vengono percepiti da chi vede LINQ per la prima volta (relativamente a persone che hanno a fare con i database, questo va chiarito). Primo, LINQ viene associato a LINQ to SQL. Secondo, "se il codice SQL non lo posso controllare, che fine fanno le prestazioni"?

Devo dirlo, comincio a preoccuparmi per il fatto che, se questa sarà la percezione di LINQ, essa creerà problemi nella diffusione e soprattutto nel corretto uso di LINQ. Per cominciare, non credo che LINQ to SQL sia l'implementazione più importante di LINQ. Ciò che ritengo importante è l'approccio a un modello di programmazione più dichiarativa che contestualmente semplifica il modo con cui i dati vengono trattati all'interno di un programma. Se ci si concentra su una singola implementazione significa che si trascura l'aspetto pervasivo di LINQ rispetto alle diverse fonti dati che si possono gestire. Dal mio punto di vista, LINQ to Objects è l'implementazione più importante di LINQ – il rischio è che la si consideri invece un accessorio privo di reale importanza, mentre è da lì che si dovrebbe partire.

Per quanto riguarda l'aspetto prestazionale, è evidente che ciò dipende da molteplici fattori ma ancora una volta c'è un errore di percezione. Il fatto che esista uno strumento non significa che lo si debba usare. Se ho un'automobile in garage, posso anche prenderla per andare a comprare il giornale all'edicola distante 300 metri, ma ci sono altri mezzi di trasporto più efficienti (anche in termini di tempo, oltre che di costi e consumi). Assumere che a priori si debba sempre usare lo stesso strumento indipendentemente dal lavoro che va effettuato è un errore. Molte applicazioni possono trarre vantaggio da LINQ to SQL. In molte altre, non avrebbe senso utilizzarlo. E' più ragionevole parlare di confronto tra LINQ to SQL e prodotti di ORM come NHibernate, perché pur essendo implementazioni molto diverse tra loro, per lo meno il terreno di confronto è simile.

Ragionerò ancora molto su queste cose preparando le sessioni per DevCon 2008. Se qualcuno vuole contribuire alla discussione, i commenti sono aperti.

LINQPad, un tool per imparare LINQ (e non solo)

Ho da poco cominciato a usare LINQPad e devo dire che è un tool molto utile. Si può usare per provare query LINQ in maniera interattiva. Se si usa LINQ to SQL, LINQPad genera automaticamente la classe DataContext necessaria e fornise un ambiente di esecuzione delle proprie query.

Al momento si sente la mancanza di qualcosa simile a IntelliSense, ma una prossima versione di LINQPad dovrebbe includere una funzione di AutoComplete. Consiglio di provare questo tool a tutti quelli che vogliono studiare LINQ e a quelli che, pur conoscendolo, vogliono avere un ambiente in cui sia molto semplice sviluppare e provare le proprie query LINQ.