settembre 2005 - Posts
Una funzionalità interessante di Windows Vista e Longhorn server è quella di offrire dei servizi di remote desktop (terminal server) più efficaci.
Questo articolo segnalatomi da Alessandro Perilli analizza più a fondo le nuove caratteristiche, tra cui spiccano la possiblità di pubblicare una singola applicazione e di "remotizzare" non necessariamente il "bitmap" risultato del rendering di un'applicazione ma anche, se si usa Avalon/WPF, l'intero albero di composition del motore grafico. In pratica Avalon compone l'interfaccia utente sul client partendo da un albero di oggetti simile (ma non corrispondente) agli oggetti di Avalon: questo significa occupare molta meno banda e allo stesso tempo avere tutti gli effetti possibili disponibili sul client. Certo, il client dovrà avere una buona scheda grafica per visualizzare al meglio Aero Glass.
L'articolo forse fa un po' di confusione tra WinFx e WPF - se possiamo considerare come applicazione WinFx un'applicazione Windows Forms, credo che la remotizzazione sia quella "tradizionale" basata sul trasferimento dei bitmap; se invece dicendo WinFx sottindendiamo WPF/Avalon (WPF = Windows Presentation Framework) allora l'affermazione è sempre valida. Personalmente preferisco sempre specificare (WPF o Win32/Windows Forms) per evitare di cadere in questa ambiguità.
La buona notizia è che i client "vecchi" saranno compatibili, continuando a lavorare in modalità bitmap: WPF fa il rendering in memoria sul server e spedisce i bitmap risultanti, praticamente come funziona adesso. La cattiva notizia (forse) è che non si prevede supporto per migliorare le applicazioni 3D. Il che non chiarisce cosa significa da un punto di vista pratico (certi effetti non saranno disponibili in remoto?). Si tratta di un punto su cui vale la pena indagare.
Senza fanfare, è uscito ieri Office 2003 SP2. Non mi sembra ci siano grosse novità, più che altro miglioramenti e patch legate alla security, devo ancora installarlo per capire se ci sono miglioramenti prestazionali tangibili.
Colgo l'occasione per segnalare questa risposta (un po' sarcastica?) alla mia segnalazione pubblica di ieri di una mail di protesta di 5 mesi fa che avevo inviato per questo articolo del 5 aprile 2005 letto sul sito de La Stampa. Visto che vengo tirato in ballo, sono andato a controllare. L'autore (Lorenzo Mantero) pubblica nel suo articolo odierno la mia seguente affermazione "non ricordo aggiornamenti legati alla sicurezza, forse uno o due". Questa frase è contenuta in una mail privata, indirizzata alla redazione (ma più che altro perché non avevo una mail di Lorenzo), di cui nessuno mi ha chiesto autorizzazione per la pubblicazione. Al di là degli aspetti legali, è un problema di cortesia: non mi sognerei mai di pubblicare sul mio modesto blog (figuriamoci sulle pagine di un quotidiano) i contenuti di una mail privata senza prima chiederne espressamente autorizzazione all'autore. Ma veniamo alla sostanza: la mia affermazione non era in un contesto pubblico e nella semantica si può identificare la mia volontà di affermare che, in linea di massima, non mi sembrava ci fossero le basi per fare un'affermazione pesante come "Outlook il software più bacato di tutti i tempi". A onor del vero, nella frase originale c'era scritto anche "Internet Explorer", che di pecche ne ha avute (e ne ha) molte di più, ma nella mail (che non è riportata per intero... anche per questo si dovrebbe chiedere l'autorizzazione all'autore...) io parlavo di Outlook 2003.
E allora, quanti bug ha (e ha avuto) Outlook 2003? Non sono riuscito a trovare notizie certe (ma non ho cercato molto). Secunia dice 7, di cui 2 altamente critiche e le altre da moderatamente a meno critiche. SecurityFocus dice 15 (non ho guardato la severità di queste). Quindi ho sbagliato e mi sono ricordato solo di quelle che inducono uno come me a procurarsi in fretta una patch. Sorry, ho sbagliato. In una mail privata. Ma non ho ancora capito se sia vero che "Outlook è il software più bacato di tutti i tempi". Direi di no, visto che ho un cliente che ha un software (che ho realizzato anche io) che è andato in produzione e da quando è andato in produzione abbiamo ricevuto almeno 200 o 300 bug (tutti rigorosamente tracciati nel ns. database): direi che se Outlook 2003 è un riferimento valido, il mio cliente dovrebbe reclamare spazio per entrare nel guinnes dei primati (è un software che usano pochi privilegiati utenti).
Lo ammetto. Sto esagerando. Quei numeri su Outlook 2003 sono le vulnerabilità, non i bug (quelli saranno certamente di più). Forse niente guinnes dei primati (in un certo senso dovrei essere più tranquillo...).
Uso Windows. Lavoro con tecnologie Microsoft. Faccio consulenza e formazione a chi si sviluppa con tecnologie Microsoft. Sono sicuramente più aggiornato su Microsoft che su Linux. Con questo, non sento il bisogno e non proverei nemmeno piacere a dileggiare e irridere Linux con o senza ragione. Non capisco perché qualcuno (qualcuno, non tutti e credo non la maggioranza) usando Linux senta la necessità, il bisogno e il piacere di fare il contrario (dileggiare Microsoft e magari anche chi lavora con i suoi strumenti). Ma magari sono io che sbaglio...
Premetto che il contenuto non è eccessivamente tecnico, nonostante questo potrebbe interessare i più a causa delle implicazioni che ha con il nostro lavoro e/o il nostro hobby.
Certi giorni succedono strane coincidenze. Stamattina ho fatto allusioni a società private che non rispondono ai loro clienti/consumatori, arrivando a essere peggio di quell'amministrazione pubblica tanto bistrattata. Questa sera c'è l'occasione buona per fare nomi e cognomi, non per il gusto di fare inutili delazioni (non rientra nei miei interessi) ma per la reale motivazione di dare dei segnali che stimolino un certo cambiamento.
Lo stimolo nasce da questo post di Alessandro Perilli, che ha le sue motivazioni a criticare un articolo pubblicato su La Repubblica. Qualche mese fa mi è capitato di leggere qualcosa di meno "pericoloso" ma di una faziosità sconcertante su una testata autorevole come La Stampa, dove brilla l'affermazione "Outlook, di gran lunga il software più bacati di tutti i tempi". Nessuno qua vuol vedere una realtà diversa da quella che è per affermare che Outlook sia esente da bug, ci mancherebbe. Ma da qui a fare affermazioni così assolutistiche senza uno straccio di dato a supporto, ce ne passa.
Ma il motivo di questo post non è tanto quello di richiamare l'attenzione sui casi specifici, quanto di ragionare su alcuni aspetti della comunicazione che avviene sui mass-media. La semplificazione del messaggio porta inevitabilmente a un impoverimento dei contenuti, questo è scontato e non possiamo farci molto. Anche io, se dovessi spiegare alcuni concetti in modo chiaro e accessibile a tutti dovrei inevitabilmente ricorrere a semplificazioni che introducono delle imprecisioni almeno formali in quanto si esprime. Questo, ripeto, è tollerabile.
Non andrebbe però mai superato quel confine oltre il quale l'affermazione è priva di un fondamento, non ha un riscontro attendibile o non ha significato. Il giornalista questo dovrebbe fare, raccogliere informazioni, verificare le fonti, riassumere in modo comprensibile anche a chi non conosce un argomento specifico (economia, politica, esteri, scienze, spettacoli). Se il giornalista smette di fare tutto questo, il suo ruolo perde di significato. E' pagato per farlo. A sua volta, la redazione di un giornale è pagata anche per garantire che tali parametri qualitativi siano rispettati. Ci sono milioni di blogger che fanno quello che fa un giornalista, e lo fanno gratis per il gusto di farlo, ma siccome non rispondono che a loro stessi possono permettersi di essere faziosi, falsi, ipocriti, narcisisti e quant'altro... c'è piena libertà. Io lo so, se leggo un blog so che devo "filtrare" i contenuti, le notizie e le opinioni in base a questo fatto. Con un giornale non vorrei doverlo fare. Soprattutto, se posso essere accettare (e considerare) il fatto che un giornale abbia una sua "linea politica", non tollero molto il fatto che possa alterare i fatti o scrivere di fatti che non siano riscontrabili. Io e milioni di altre persone possiamo scrivere tranquillamente che Windows è strabacato e Linux una copia di cose fatte da altri, ma un giornalista (quando scrive un articolo) non può permetterselo.
Al di là del giornalista, poi, c'è la responsabilità della redazione e quella dell'editore. Che in ultima analisi rispondono (entrambi) anche al lettore. E cosa succede se il lettore fa notare che qualcuno non ha seguito le regole, deludendo la fiducia del lettore che a quel punto si fida meno anche per gli argomenti che non conosce?
Beh, nel caso della mia garbata protesta via mail alla redazione de La Stampa... non è successo nulla.
Inizialmente non pensavo di rendere pubblico l'episodio, ma speravo anche in una risposta più o meno tempestiva (anche solo di cortesia, insomma).
Vedremo se qualcuno risponderà ad Alessandro.
Nel frattempo, qualcuno potrebbe iniziare a chiedersi se valga la pena di pagare un giornale (NB: visitare i giornali on-line in un certo senso è come pagarli, visto che si finanziano con la pubblicità) che non è più attendibile di un insieme di blog accessibili a livello planetario. Io credo che un valore ce l'abbia ancora, ma sicuramente c'è qualcosa da fare perché questo valore si mantenga.
Un gentilissimo lettore, Gabriele, mi ha segnalato questo stupendo articolo di knowledge base Microsoft dal titolo chilometrico: KB82369 - Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments.
Si tratta di una guida piuttosto utile per comprendere gli effetti collaterali di alcune modifiche che è possibile fare alle impostazioni di security di Windows. In realtà talvolta si chiarisce per bene il reale significato di alcuni termini (come il diritto Allow logon Locally, che è meno intuitivo di quanto il nome potrebbe far credere) con cui presto o tardi chiunque si trova ad avere a che fare.
Un brevissimo link a questo post di Frans Bouma per evidenziare un punto di vista su cui sono d'accordo: non bisogna pensare che Linq == DLinq, se Linq rimane così generico come è stato pensato chiunque può tranquillamente inventarsi il suo *Linq che fa il mapping come gli piace. Leggete però l'ultima frase:
Don't think lightly about this: DLinq from MS is a huge paradigm-shift. From service oriented, based on messages and anonymous datasets to domain oriented, with typed domain objects.
C'è del vero in questa affermazione, ma rispondendo ad alcune domande il punto di vista dei progettisti di Linq è abbastanza chiaro: Linq non attraversa gli n-Tier di una soluzione completa, il suo "mercato di riferimento" sono i componenti del Data Tier e quelle piccole applicazioni che non necessitano di questi strati e vivono serenamente la loro condizione client-server. Ce ne saranno anche in futuro, non c'è un'architettura che va bene per tutti (solito discorso, compreresti una Ferrari per andare a comprare il latte sotto casa? Magari qualcuno lo fa, ma la maggior parte no).
Riassunto dell'antefatto: a fine agosto il Ministro per l'Innovazione e le Tecnologie ha dichiarato che emanerà una direttiva per abbassare i costi dei pagamenti on-line alle pubbliche amministrazioni; della cosa riportavo notizia in un post su questo blog. La scorsa settimana, sollecitato tra l'altro dalla lettura di questo post, dopo aver ricercato novità sull'argomento su Google e sul sito del Ministero, prendevo mail e tastiera (una volta si diceva carta e penna...) e provavo a chiedere informazioni seguendo i link riportati sul sito stesso.
Oggi mi è arrivata la risposta contenente i chiarimenti e le tempistiche (provo a interpretare il burocratese: entro fine anno...) dell'emanazione della tanto attesa direttiva. Dopo aver chiesto autorizzazione per la pubblicazione sul blog, riporto il contenuto che credo sia di interesse generale. Speriamo che questa direttiva inneschi un circolo virtuoso che faccia aumentare il numero di pagamenti on-line, ormai Internet è sufficientemente diffusa da poter costituire l'auspicata "massa critica".
Una mia personale considerazione: negli ultimi due anni ho avuto via mail più risposte chiare e tempestive da enti pubblici (Istat, Ministero per l'Innovazione, Comuni vari, Agenzia delle Entrate) che non da società private (per carità, la maggior parte rispondono, ma non tutte e soprattutto alcune grosse aziende non rispondono a mail che sollevano questioni piuttosto delicate... meglio non rispondere che prendere una posizione qualsiasi?). Questo è un segnale di cambiamento che interpreto positivamente per la pubblica amministrazione, che non è come vorremmo che sia ma è un po' meglio di 10 anni fa. Lo stesso segnale è invece negativo per quelle aziende che parlano molto di customer care, presenza sul web, quote di mercato... e poi non danno risposte alle domande dei clienti effettivi o potenziali: ma per queste il mercato e il tempo sono un ottimo depuratore.
Ma ecco la mail che ho ricevuto. Un ringraziamento al dott. Francesco Leopardi Dittaiuti per averne autorizzato la divulgazione.
Gentile Signor Russo,
faccio riferimento alla sua e-mail di seguito riportata per informarLa che il Ministro per l'Innovazione e le Tecnologie, nel ringraziarLa per le Sue osservazioni, mi ha incaricato di fornirLe riscontro.
Al riguardo, Le confermo la convinzione del Ministro che i pagamenti on-line non debbano costare più di quelli tradizionali, ma che addirittura dovrebbero costare meno.
Le faccio presente che le disposizioni sui costi di intermediazione relativi ai pagamenti on line, cui Lei fa riferimento, saranno contenute nella Direttiva annuale del Ministro alle Pubbliche Amministrazioni, in corso di emanazione, e che quando sarà pubblicata sulla Gazzetta Ufficiale potrà trovare sul nostro sito all'indirizzo http://www.innovazione.gov.it/ita/normativa/index.shtml, insieme alle precedenti Direttive annuali.
Le ragioni che vengono invocate per giustificare il maggior costo dei pagamenti on line costa sono diverse, ad esempio l'intervento di intermediari tecnologici e finanziari che ovviamente chiedono una remunerazione per i loro investimenti; infatti, quando interviene una carta di credito, esiste anche un costo di finanziamento (es. rateazione). Tale costo, nel mondo commerciale, viene assorbito dal venditore, il quale ovviamente lo riversa sul costo finale del prodotto. Ora la Pubblica Amministrazione non può aumentare o diminuire una tassa in funzione del fatto che il contribuente paga on line oppure off line, per lo meno con la legislazione attuale. Inoltre, fino a quando il numero di pagamenti on line non diventerà preponderante rispetto agli altri tipi di pagamento, il costo della struttura rimarrà più o meno lo stesso e quindi i costi tali transazioni on line diventano putroppo addizionali. Per invertire questa tendenza è necessario che la massa dei pagamenti cresca. Pertanto il Ministro, oltre alle disposizioni che saranno contenute nella Direttiva annuale, ha costituito un gruppo di lavoro con il compito specifico di individuare ed eliminare gli inibitori allo sviluppo dei pagamenti on line.
Pertanto, nell'ambito dei limiti delle risorse disponibili per favorire una politica di diffusione equilibrata dei servizi agli utenti nell'ottica dell'efficienza, della semplificazione e della trasparenza, Le confermo l'attenzione e l'impegno del Ministro per l'Innovazione e le Tecnologie.
Con i migliori saluti.
dott. Francesco Leopardi Dittaiuti
Consigliere del Ministro per l'Innovazione e le Tecnologie Via Isonzo 21/b - 00198 Roma
Incuriosito da questo post trovato quasi per caso, ho letto questo articolo di knowledge base che sconsiglia di usare librerie di alto livello in alcuni processi critici del sistema operativo. Sembra uno strano consiglio, ma a pensarci bene tanto strano non è.
L'articolo è stato aggiornato a settembre 2005 ma il post è di gennaio, quindi mi viene il dubbio che nell'aggiornamento abbiano un po' cambiato il titolo e il contenuto, aggiustando meglio il tiro. Infatti se il titolo originale era Do not use .NET Framework Class Libraries or other framework libraries in core operating system processes è chiaro che sembra quasi un atto di sfiducia nei confronti del Framework .NET... In realtà è più comprensibile che il senso reale sia il fatto di minimizzare l'impronta in memorie di processi che sono sempre attivi, tanto che tra le cose sconsigliate ci sono anche MFC, ATL e addirittura COM; un'altra considerazione importante è la necessità di minimizzare la dipendenza di tali processi da librerie esterne, il sistema operativo deve partire ed essere utilizzabile anche in caso di "danneggiamenti" delle librerie esterne da parte di terzi.
In questo
post di Karen Watterson c'è un link al
primo capitolo dell'imminente libro
Data Mining with SQL Server 2005 di ZhaoHui Tang e Jamie MacLennan. Nello
stesso post ci sono altri link utili ad articoli e a un video sul Data Mining con SQL 2005.
Recentemente ho fatto alcune analisi sull'impatto reale della migrazione di cubi OLAP da Analysis Services 2000 ad Analysis Services 2005. Prima di pubblicare qualche considerazione aspetto di vedere la versione finale, alcuni dettagli potrebbero ancora cambiare (anche se la CTP di settembre è praticamente una Release Candidate, ma su questa non ho ancora fatto tutte le prove necessarie).
Nel frattempo, ho appena dato una veloce lettura a questo whitepaper sulla migrazione (si può scaricare gratuitamente dopo aver fornito i propri dati) e devo dire che anche se non scende troppo nei dettagli (e vi assicuro che bisogna farlo per migrare soluzioni complesse che usano Drillthrough, dimensioni con gerarchie multiple e membri calcolati piuttosto complessi) è comunque un testo ricco di considerazioni sensate, in particolare la sezione dove confronta la migrazione con la riprogettazione (in alcuni casi è bene considerare da subito quest'ultima).
Semplificando molto, si può dire che soluzioni che sfruttano Analysis Services in modo elementare possono essere migrate senza problemi, ma più il cubo è complesso in Analysis Services 2000 e più bisogna valutare la possibilità di riprogettare tutto. Un esempio eccellente sono le dimensioni virtuali, che si possono eliminare a vantaggio di gerarchie multiple su una stessa dimensione (se proprio si vogliono le gerarchie). Comunque usare il tool di migrazione per poi intervenire manualmente con un po' di refactoring sembra la strada praticabile nella maggioranza dei casi.
Quello che invece mi sento ormai di sconsigliare quasi per certo è la migrazione "diretta", che consiste nell'installare Analysis Services 2005 al posto di Analysis Services 2000 senza mantenere le due versioni "in parallelo": se qualcosa non va per il verso giusto è difficile avere dei riscontri, sia in termini di strutture precedenti che di risultati delle query sul modello precedente. Molto, molto meglio mettere i due sistemi in parallelo, migrare i cubi sulla nuova versione e limare un po' il tutto, mettendo poi in system test i cubi migrati e procedendo a verificare la corretteza di tutti i report (se cambiano dei nomi o delle entità sul cubo, sicuramente alcuni report vanno rivisti e corretti).
Devo ammettere che sul fronte della migrazione fino a un anno fa pensavo che sarebbe stata molto più indolore, ma se si vogliono sfruttare realmente le capacità di Analysis Services (altrimenti perché cambiare?) è opportuno prendersi il tempo necessario. Molto più semplice invece adottare da subito Analysis Services 2005 per un nuovo progetto, lì non ho dubbi e invito quasi sempre a partire da subito con la nuova versione.
Oggi ho conosciuto Google Blog Search, motore di ricerca che analizza solo i blog e non le pagine "normali". Anche se Google già indicizza i blog, questa versione lavora solo con feed relativamente recenti (non trovo pagine di post più vecchi di un paio d'anni su qualche blog che ho preso coe riferimento) e presumibilmente ha un aggiornamento più frequente: insomma un alternativa a Technorati o Feedster per cercare notizie fresche dal mondo della blogosfera.
Altra novità del giorno è Watson 2.0: si tratta di una specie di agent (scovato grazie alla segnalazione di Alessandro Perilli) che, analizzando quello che l'utente sta scrivendo e/o leggendo, decide quali sono le ricerche significative da fare e le effettua, dividendo i risultati tra Web, News, Blog e risultati delle ricerche in locale (supporta vari motori tra cui MSN Desktop e Google Desktop). Funziona anche quando state visitando una pagina con Internet Explorer. Non so se funziona con Firefox, sicuramente ha qualche problemino a capire che sto usando Maxthon (che è solo un wrapper attorno a IE, dopotutto). Direi che ci sono due tipi di problemi con questo prodotto: il primo è che talvolta i risultati non sono esattamente pertinenti, anche se ho trovato un sacco di informazioni interessanti; il secondo è il prezzo, decisamente elevato per scopi non professionali - da giornalista (partiamo da 10$ al mese e si può arrivare a 100$/anno o 240$ per la licenza senza scadenza, ma con solo un anno di upgrade).
Grazie alla segnalazione di Don Box, ho appena letto un post di Danny Thorpe (uno degli architetti di Borland Delphi) su LINQ. Anche qua ci sono vari commenti e alcune critiche, ma la conclusione è sempre la stessa: anche Delphi supporterà LINQ. A mente fredda, sembra che LINQ abbia aperto un dibattito in cui c'è discussione sui mezzi (l'implementazione, in particolare di DLinq) ma un consenso molto ampio sul fine (innalzare l'astrazione del linguaggo per manipolare i dati in modo più agevole).
Un aspetto che ancora pochi hanno considerato è che in realtà la parte realmente comune di LINQ è la libreria di generics che dà origine alla struttura di base. Le implementazioni specifiche (DLinq e XLinq, al momento) sono solo alcune tra quelle possibili, lasciando spazio a implementazioni alternative. Il supporto specifico dei linguaggi è qualcosa che varia da linguaggio a linguaggio. Quello che è un concetto piuttosto astratto (LINQ) e definito a livello di CLR con sintassi che possono far venire il mal di pancia, si può tradurre in una miriade di dialetti diversi dal punto di vista dell'utilizzatore (il programmatore che lo usa). Credo che sia molto difficile prevedere oggi cosa succederà esattamente tra due o tre anni, sia in termini di adozione di LINQ che di implementazione finale. Interessante però assistere alla "nascita" di una tecnologia ancora così lontana ma potenzialmente pervasiva.
Stimolato da questo post di Alessandro Perilli, torno rapidamente su un argomento che ho già toccato altre volte in passato. Google ha molti servizi e software che hanno accesso e/o trattano direttamente dati personali e spesso riservati. Microsoft ha la capacità di fare altrettanto da molti anni: potenzialmente Windows potrebbe tracciare tutto quello che l'utente fa e trasmetterlo a qualcuno che ne facesse richiesta. Per quanto riguarda quello che gira sul proprio PC (sistema operativo e applicazioni varie), credo che se esistessero veramente simili backdoor la notizia difficilmente potrebbe essere occultata. Diverso e più delicato il discorso per tutti quei servizi che operano con server remoti, da Google Search, MSN Search, GoogleEarth, VirtualEarth, ecc. ecc.
Pensando però a un servizio come Google Secure Access è effettivamente difficile capire come potrebbero fare a meno di usare un po' dei dati che passano per profilare gli utenti/clienti, soprattutto considerando che il servizio è gratuito. Certo, la stessa cosa la può fare qualsiasi provider. Ma quale danno potrebbe provocare un attacco a questo servizio? Siamo sicuri che l'aumento della sicurezza passi per l'introduzione di un unico proxy mondiale di tutte le reti wifi?
Non credo ci siano risposte semplici, ma l'argomento è meritevole di ulteriori ragionamenti.
Sono reduce da una cena dove si è parlato di lavoro e tecnologia. Spesso, analizzando il mercato, si ragiona su quanto in Italia siano così poco "analitiche" le valutazioni che portano all'acquisto di una soluzione piuttosto che di un'altra. Questa considerazione, largamente condivisa, porta a non considerare la qualità di un prodotto come un valore in sé ma a ridurlo a un costo che può diventare troppo elevato, enfatizzando invece altri aspetti più o meno commerciali e più o meno leciti che favoriscono la scelta finale.
Io sono realista (so come vanno le cose) ma anche ottimista: quando si pensa all'IT in futuro, secondo me bisogna ragionare secondo degli standard di servizio che vanno garantiti. Oggi qualcuno comprerebbe dei telefoni che funzionano un po' sì e un po' no? Difficile ipotizzarlo. Inoltre, se è vero che l'IT serve ad aumentare l'efficienza di un'azienda, gli errori negli investimenti in IT si dovrebbero ribaltare, nel lungo periodo, in maggiori costi uniti a minore competitività... il che significherebbe una selezione naturale applicata dal mercato. Io sono portato a pensare che questa selezione in realtà stia già avvenendo, perché è nei momenti peggiori del mercato che avviene la selezione, e non viceversa. Chi è più competitivo oggi? Chi ha creato un'infrastruttura IT che funziona bene o chi ha fatto investimenti dissennati spinto dalla moda della new-economy? Chi ha un sistema gestionale ben integrato o chi introduce i dati a mano più volte per una stessa operazione?
Tutto questo mi è venuto in mente leggendo questa segnalazione di Andrea Saltarello, che osservava come il sito di Miss Italia fosse affidato a una soluzione basata su database Access aperto via ODBC. Devo dire che da una parte sono felice di non aver letto i giornali leggendo del malfunzionamento di questo servizio (ci sarebbero cose più importanti, benché questo in Italia sia considerato tale...) ma pensate se il sito della RAI andasse a picco così durante le consultazioni elettorali o dopo una notizia-evento (un po' meno frivola di Miss Italia, intendo). Anche senza entrare del merito dei motivi tecnici di un disguido simile, ci sarebbero molte proteste...
La PDC che si è appena conclusa ha portato molte novità, ma allo stesso tempo non è stata così "stravolgente" per gli sviluppatori come la PDC del 2003 o quella del 2000 (PDC 2001 non conta...). Nel 2000 è iniziata la rivoluzione del .NET Framework, nel 2003 è iniziata la rivoluzione di Longhorn e WinFX. Quest'ultima si è però rivelata molto meno "rivoluzionaria" di quanto poteva apparire inizialmente. Oggi, avendo in mano una build "funzionante" di Windows Vista ci si rende conto che, nonostante le innumerevoli novità, si tratta pur sempre di un percorso molto graduale di migrazione da una tecnologia all'altra. Per certi aspetti è molto meglio così, anche se la parte "visionaria" che è in molti di noi vorrebbe un'accelerazione ancora maggiore.
Il codice Win32 è ancora lì, ed è lì per rimanerci: Windows Vista offre nuove API anche a livello Win32 (al contrario di quello che si poteva immaginare nel 2003, quando fu annunciato che ogni nuova API sarebbe stata managed). Il codice COM è ancora lì, anche lui con nuove classi e nuove interfacce per nuovi servizi. Ovviamente il codice managed (.NET) fa la parte del leone, ma è ancora lontano un sistema operativo 100% managed. Forse ci si arriverà, ma sarà un percorso di naturale evoluzione e non una brusca e obbligatoria forzatura.
Una discriminante che potrebbe accelerare questo processo è il codice a 64 bit: le applicazioni managed hanno un enorme vantaggio, molte funzionano a 64 bit senza dover essere ricompilate (le applicazioni che usano o referenziano codice unmanaged invece sono soggette a minimi ritocchi o per lo meno a una ricompilazione). Se l'adozione di macchine a 64 bit sarà molto veloce, assisteremo a una rapida obsolescenza dei programmi a 32 bit e per questioni di costi difficilmente saranno migrati in codice nativo a 64 bit, più facilmente avremo molti programmi managed che non fanno tanta distinzione tra le due piattaforme. Oggi però questo processo non è ancora cominciato, ci sono degli indizi ma la mancanza di driver a 64 bit per adesso frena l'esplosione del fenomeno. Chi ha una macchina a 64 bit il più delle volte monta ancora un sistema operativo a 32 bit. Però l'esplosione potrebbe avvenire già a partire dal 2007 (subito dopo l'uscita di Windows Vista) e quindi avremo una "massa critica" entro il 2010, giusto in tempo per una nuova versione di Windows. A essere pessimisti, invece, avremo sistemi operativi a 32 bit fino al 2012/2015 (attenzione, sto ragionando sui grandi numeri, sicuramente nel 2015 ci sarà ancora qualcuno con il suo bravo Windows 95...). Direi però che fare previsioni a questa distanza è totalmente impossibile e privo di significato. Dieci anni fa avevamo Windows 95, da allora sono uscite 3 nuove versioni "importanti" di Windows (NT 4.0, 2000, XP/2003) e da quando era impensabile pensare di fare foto amatoriali in digitale a un livello di qualità decente, siamo arrivati a uno stadio in cui chiunque si può montare audio e video in totale autonomia, praticamente allo stesso prezzo (come valore d'acquisto) con cui allora si prendeva un PC per lo più per lavorare in locale (pensiamo all'uso domestico) con Word ed Excel e per giocare (la maggior parte dei giochi erano ancora DOS).
Ora, a qualcuno questa convivenza può non piacere. Mantenere la tecnologia esistente e contemporaneamente adottarne una nuova rappresenta indubbiamente un costo. Ma Steve Swartz (uno degli speaker di PDC) ha espresso splendidamente quale sia uno dei punti di vista migliori per guardare la cosa. Durante una sessione su WCF/Indigo, dopo aver "parlato male" di .NET Remoting (che fondamentalmente va usato solo per far comunicare AppDomain diversi su una stessa macchina), ha risposto così a una domanda di un partecipante che chiedeva se non si potesse eliminare del tutto Remoting (così da evitare che qualcuno lo possa usare a sproposito).
"Hai dei figli?"
"Sì"
"Quanti?"
"Tre"
"Quando è nato l'ultimo hai pensato di dover ammazzare il primo?"
Trovo che questa metafora sia splendida perché chiarisce come nella vita reale non si possa buttare via e rifare tutto ogni volta che si scopre che qualcosa si poteva fare meglio. Allo stesso tempo, però, non si può neanche rimanere fermi e immobili, il cambiamento, la novità, fa parte delle nostre vite. Questa metafora si adatta alla perfezione alle tecnologie: una nuova non ne sostituisce un'altra in modo "scientifico", quello che avviene è una sorta di "selezione naturale", dettata dalle leggi del mercato (costi per il mantenimento della tecnologia esistente, opportunità e vantaggi dell'adozione di quella nuova).
Per questi motivi sono rimasto estremamente colpito da Office 12. Ho letto diversi commenti che, in modo un po' superficiale, etichettano il nuovo Office come una semplice "pennellata" all'interfaccia utente. Forse l'avrei fatto anche io se non l'avessi visto "in uso". Una fotografia istantanea di Excel 12 o Word 12 non consente di capire che l'innovazione non sta nella grafica (tra l'altro quella che abbiamo visto è molto scarna, quella reale è ancora nascosta) ma nella rapidità e intuitività d'uso. Dal punto di vista dell'utente, è veramente una nuova versione: la stragrande maggioranza delle cose che ho visto fare nell'editing di un documento Word o di un foglio Excel sono in realtà già possibili in Office 2003 (e in gran parte anche in Office XP, 2000 e 97!) ma semplicemente... molti (me compreso) non sanno nemmeno dove cercarle. A questo si uniscono poi molte novità anche funzionali (l'accesso ai dati di Excel, per esempio) e la parte di servizi lato server e di integrazione con SharePoint v3, che per il mondo aziendale sono estremamente interessanti (grazie anche, se non soprattutto, ai nuovi strumenti di workflow). Un'opinione comune che ho condiviso con alcuni colleghi è che questo nuovo Office si venderà da solo. Conosco molti utenti che continuano a usare Office 97 perché, semplicemente, non vedono il vantaggio che deriverebbe da un upgrade: a questo tipo di utenti le differenze con Office 12 saranno immediatamente visibili (se poi decideranno di non fare l'upgrade sarà per altri motivi).
Sempre a proposito di Office, sono rimasto sorpreso dal fatto che più che Windows Vista è proprio Office che detta le nuove linee guida per il disegno dell'interfaccia utente. Di queste linee guida c'è veramente bisogno, perché se da una parte WPF/Avalon concede un grado di libertà molto elevato, dall'altra avere un'interfaccia utente consistente è ugualmente importante. Aero detta le linee guida dell'interfaccia utente, ma sarà Office a dare un'impostazione di stile più marcata. Un altro aspetto che non avevo considerato fino a oggi è il modo in cui cambia anche l'architettura implementativa interna dell'interfaccia utente con l'avvento di WPF/Avalon: ho scritto un post in inglese dove riporto il pattern implementativo usato dai creatori di Sparkle (nome in codice di Microsoft Interactive Designer, in pratica l'editor di XAML destinato ai grafici), tale pattern si può adottare con successo anche con Windows Forms e credo che oggi rappresenti la strada migliore per garantire il migliore e più semplice passaggio a WPF/Avalon sfruttandone appieno tutte le caratteristiche e potenzialità e recuperando il più possibile il codice esistente.
Per quanto riguarda Windows Workflow, approfondirò meglio l'argomento in futuro, a PDC non ho avuto tempo di seguirne le sessioni più tecniche (ahimé è sempre difficile scegliere cosa sacrificare) ma l'opinione comune che ho raccolto è che si tratta di un'ottima iniziativa e anche dal punto di vista implementativo non sembrano esserci serie limitazioni (certo, c'è da scrivere codice per fare le personalizzazioni più spinte, ma come dice un famoso collega, gli sviluppatori sono pagati per scrivere codice...). Comunque c'è spazio per librerie e componenti di terze parti, l'importante è poter partire da un framework comune e standardizzato.
Infine, guardando un po' più in là (almeno 3 anni), C# 3.0 e LINQ sono un aspetto che ha acceso alcune controversie: se è quasi unanime la lode per integrare nel linguaggio dei costrutti di manipolazione dei dati in modo tipizzato (e questa è una cosa che non ha molti precedenti sul mercato), ampio dibattito lo fornisce l'implementazione di DLINQ, che consente di "collegarsi" ai dati provenienti da una fonte relazionale. DLINQ può essere visto come un O/R mapper, cioè uno strumento per collegare un modello a oggetti a un modello relazionale: da questo punto di vista, DLINQ si confronta con altri strumenti presenti sul mercato da anni e con ObjectSpaces, progetto molto più ambizioso ma ora abbandonato di cui in realtà DLINQ è l'araba fenice. I puristi del mondo "a oggetti" vorrebbero un'astrazione totale del modello relazionale in un modello a oggetti, avendo allo stesso tempo il massimo disaccoppiamento tra i due; i puristi del mondo "relazionale" vorrebbero invece che si smettesse di voler creare un modello a oggetti per ciò che vive benissimo in un modello relazionale, che è nato per trattare i dati. Tra i due estremi ci sono una miriade di posizioni diverse e trovare una posizione che possa mettere d'accordo tutti è assolutamente impossibile. Sempre per citare un aneddoto, sembrano quasi inconciliabili le posizioni di Anders Hejlsberg e Eric Meijer quando discutono della corretta posizione di SELECT in una query expression di C# 3.0 (per la cronaca, il primo la vuole alla fine dell'espressione mentre il secondo all'inizio, come in SQL), quindi figuriamoci quanto sia difficile trovare un modello O/R universale e buono per tutti. Credo che pensare all'esistenza contemporanea di diverse tecniche di accesso ai dati sia l'unica strada praticabile. Il discorso sarebbe molto lungo, ma la visione di fondo è una via alternativa a SQL (attenzione, alternativa e non sostitutiva...) di accedere ai dati.. insomma, una query che, definita semanticamente a livello di codice (C# 3.0 o VB 9) arriva direttamente al motore di SQL Server come piano di esecuzione senza dover passare da una rappresentazione testuale. Questo ucciderebbe il linguaggio SQL come lo conosciamo? Neanche per sogno, per me è solo una soluzione alternativa che potrà essere utile in alcune circostanze, senza che questo debba significare riscrivere tutte le applicazioni esistenti. Per esempio, la mia opinione è che nella reportistica il linguaggio SQL abbia un'espressività molto alta... MDX è un linguaggio che risolve meglio di SQL moltissime tipologie di analisi, ma non tutte... e non mi aspetto che un modello a oggetti possa fare di meglio in questo ambito. Per risolvere al meglio tanti problemi diversi è bene avere tanti strumenti disponibili e non uno soltanto, quindi ben venga questa evoluzione, vedremo dove potrà portare.
Da lunedì si torna ai problemi quotidiani, chiedendoci quando sarà la prossima PDC. La logica dice 2007, ma qualche vocina suggerisce che potrebbe anche essere nel 2006 o nel 2008. Indagheremo... nel frattempo torniamo a occuparci a tempo pieno della preparazione di DevCon 2005!
Il prodotto sembra mantenere le promesse ma non è stato mostrato nella sua completezza. Tra le altre cose non sono stati mostrati i grafici e altre tecniche di Data Vcome quelle isualization fornite oggi da Data Analyzer che saranno integrate in Excel.
Ho scritto un post nel blog in inglese con i miei appunti sulla sessione.
More Posts
Next page »