Prime impressioni su Cuil

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.

La gestione della memoria in Windows

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…

Alcune segnalazioni per LINQ

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.

C# 4.0 a PDC 2008

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.

Quando usare LINQ to SQL?

Un commento al mio post precedente su ADO.NET Entity Framework contiene la domanda fatidica:  che fine farà LINQ to SQL? E implicitamente ne contiene un'altra altrettanto importante: quando usare LINQ to SQL?

Andiamo con ordine: LINQ to SQL sarà supportato per almeno 10 anni. Fa parte di .NET Framework 3.5, la sua interfaccia pubblica sarà mantenuta anche nelle prossime versioni di .NET Framework. Difficile che facciano marcia indietro su questo, almeno nel breve. Ma sicuramente potrebbero cambiarne l'implementazione. Questo è un argomento molto più complesso che però non siamo in grado di analizzare almeno fino a che non vedremo (a PDC 2008?) quali sono i piani per .NET 4.0. Nella peggiore delle ipotesi, non evolverà dallo stato attuale.

Ciò detto, veniamo alla seconda domanda, che non può non tenere conto delle considerazioni precedenti. Premetto che quello che segue è una mia personale opinione e non rappresenta una posizione espressa da Microsoft in alcuna sede, ufficiale e non.

LINQ to SQL va bene in molti scenari che mi trovo ad affrontare con una certa frequenza. Raggruppati per categorie:

  • Procedure batch di trasformazione/elaborazione di dati.
    • Tipicamente sono fatte apposta per un database (SQL Server nel nostro caso) e sono scritte in C# perché con T-SQL o SSIS non si avrebbe a disposizione uno strumento adeguato
    • Esempi: algoritmi di valorizzazione del magazzino; procedura di import formati custom (binari o ascii con strutture variabili); …
  • Semplici interfacce di manutenzione di un database (es. a scopo amministrativo, edit tabelle di configurazione et simili)
  • Accesso a database locali (es. per contenere dati di configurazione)

Probabilmente ve ne sono altre, ma è importante sottolineare quello che manca e che oggi non scrivere usando LINQ to SQL:

  • Applicazioni enterprise e/o n-Tier (salvo usare LINQ to SQL per alcune parti del DAL, ma la cosa richiederebbe una lunga discussione)
  • Framework per sviluppo ERP
  • Implementazioni ERP – insomma il classico "gestionale"

I motivi per non usarlo in questi casi sono sia implementativi (prestazioni, architettura, ecc.) che strategici (supporto nel lungo periodo, evoluzione in versioni future, ecc.). Mentre i motivi per usarlo nei casi che ho esposto in precedenza sono riassumibili in una parola: produttività.

Ho usato LINQ to SQL in alcuni casi dove ho potuto confrontare il risultato ottenuto con la realizzazione corrispondente senza LINQ to SQL. Semplicemente, aumenta la produttività. Si scrive meno codice, quello che c'è è più leggibile e non si perde troppo in prestazioni (a meno che non dobbiate scrivere molti dati – purtroppo non c'è un supporto diretto al bulk insert e bisogna ricorrere ad ADO.NET). Qualche preoccupazione in più per la gestione degli errori, problematica che però negli scenari che ho descritto è di solito meno critica.

Un aspetto determinante nell'usare LINQ to SQL negli scenari che ho descritto è la facilità di deployment. Se c'è .NET 3.5, c'è tutto quello che serve. Non ci sono altre DLL o altri componenti da installare. Sarà banale, ma su applicazioni con poche centinaia di righe di codice il fatto di dover installare delle librerie aggiuntive su dei server (penso ai batch notturni) può diventare un problema peggiore dei vantaggi dati dall'uso di LINQ to SQL.

Sarei felice di avere dei feedback a queste considerazioni, soprattutto se avete già iniziato a usare LINQ to SQL.