settembre 2003 - Posts
C'è un sito per i blog su Longhorn:
http://longhornblogs.com/scobleizer/
Mi pare di capire che per ora ci sia solo
Robert Scoble... che già produce abbastanza traffico da solo :-)
Probabilmente dopo PDC sarà un sito molto trafficato.
Don Box illustra la sua personale
storia di PDC. Niente di tecnico, ma per chi lavora da anni con tecnologie Microsoft è un buon ripasso...
Diatriba sull'uso delle eccezioni tra
Miguel de Icaza e
Brad Abrams. Ovviamente (basta leggere i miei articoli!) sono a favore delle eccezioni. Alle considerazioni di Brad aggiungo che Miguel sbaglia a considerare la gestione delle eccezioni così costosa. Prima di tutto, è sbagliato vedere un programma pieno di try/catch (mentre dovremmo trovare tante try/finally); inoltre, anche se è vero che usare le eccezioni ha un costo rispetto a non usarle, non è detto che il costo del non-uso delle eccezioni sia migliore: ogni controllo (preventivo sui parametri o successivo sui codici di ritorno) ha un costo, e le eccezioni consentono di ridurre il numero di controlli con un rapporto superiore di 1:1. Attenzione, non voglio dire che l'osservazione di Miguel sia sbagliata: in linea teorica può avere ragione (in particolare quando ragioniamo su API a basso livello), ma se poi qualcuno applica il suo ragionamento a occhi chiusi, senza fare delle considerazioni sul programma specifico che sta realizzando, i risultati sono senz'altro pessimi.
Ingo Rammer, famoso per essere il guru di Remoting, ha scritto
un articolo per MSDN. La notizia è che l'articolo non è su Remoting ma su WSE 2.0. Dunque, dobbiamo pensare che Remoting sia già sul viale del tramonto? Io e
Paolo siamo d'accordo sul fatto che il futuro sia dei Web Service, con le dovute eccezioni (e in quei casi, comunque, non è sempre detto che Remoting sia una soluzione migliore).
Attenzione, non ho detto che Remoting non serve...
Diatriba sull'uso delle eccezioni tra
Miguel de Icaza e
Brad Abrams. Ovviamente (basta leggere i miei articoli!) sono a favore delle eccezioni. Alle considerazioni di Brad aggiungo che Miguel sbaglia a considerare la gestione delle eccezioni così costosa. Prima di tutto, è sbagliato vedere un programma pieno di try/catch (mentre dovremmo trovare tante try/finally); inoltre, anche se è vero che usare le eccezioni ha un costo rispetto a non usarle, non è detto che il costo del non-uso delle eccezioni sia migliore: ogni controllo (preventivo sui parametri o successivo sui codici di ritorno) ha un costo, e le eccezioni consentono di ridurre il numero di controlli con un rapporto superiore di 1:1. Attenzione, non voglio dire che l'osservazione di Miguel sia sbagliata: in linea teorica può avere ragione (in particolare quando ragioniamo su API a basso livello), ma se poi qualcuno applica il suo ragionamento a occhi chiusi, senza fare delle considerazioni sul programma specifico che sta realizzando, i risultati sono senz'altro pessimi.
Sempre
su segnalazione di Brad Abrams, pare che una sessione da non perdere a PDC sia quella di Jan Gray (che ancora non compare sul sito). Purtroppo so già che a PDC sarò depresso per tutte le sessioni che dovrò perdere (ce ne saranno sempre almeno 3 o 4 "da vedere" alla stessa ora), comunque segnamo anche questa nota...
Una sessione di PDC che non avevo ancora notato (magari è stata inserita da poco) è la
CLI327 (System.Search: Natural Language Access to Data). In breve, sembra di capire che in Longhorn ci sia un API managed per l'accesso a un motore che interpreta (ed esegue?) query in linguaggio naturale. Purtroppo la descrizione non dice molto di più e in particolare sarebbe interessante capire se si tratta di un'evoluzione di English Query (che supporta solo l'inglese) o se il passo in avanti è più deciso e sono supportate lingue diverse.
Mi pare ovvio che WinFS (il nuovo storage di Longhorn) sia strettamente correlato a queste classi.
L'attesa per PDC comincia ad aumentare, ho sempre più domande a cui trovare risposta.
Brad Abrams
fa alcune considerazioni nel suo blog rispetto all'uso di GetHashCode. A parte le avvertenze (c'è qualcuno che confonde l'uso di GetHashCode con un ID univoco dell'oggetto... non è così, basta leggere la documentazione), la parte interessante è la considerazione relativa alle prestazioni.
Il valore restituito da questa GetHashCode è il puntatore al SyncBlock dell'oggetto. Questo oggetto (unmanaged) è creato solo se necessario: normalmente ciò avviene per la prima chiamata di Monitor.Enter (lock in C# e SyncLock in VB.NET), ma la stessa necessità è presente chiamando GetHashCode.
Nella versione 1.0 e 1.1 di .NET questa è l'implementazione di GetHashCode, che cambierà nelle versioni successive. Nel frattempo, se qualcuno ha bisogno di migliorare le prestazioni di un programma che usa tale metodo, può ridefinire GetHashCode per le sue classi, magari generando un numero random nel costruttore che viene poi memorizzato in un campo privato (più o meno quello che dovrebbe fare la prossima versione di .NET).
Con qualche giorno di anticipo è disponibile su
MSDN downloads l'intera suite di Office System 2003: finalmente possiamo recuperare i nostri appunti su OneNote!
Brad Abrams
ha segnalato la presenza di
Chris Brumme in
questo panel.
Assolutamente da non perdere. Seguirà reportage fotografico (chi non è curioso di vedere l'aspetto di certi nomi "famosi" nel mondo dei blog?).
Clemens Vasters
ha scritto un interessante post sull'emergente acronimo SOA (Service Oriented Architecture).
Anticipo, per chi vorrà leggerselo, che i concetti esposti non sono immediatamente condivisibili: per dirla in modo provocatorio, si inneggia un po' al ritorno al passato, ai dati separati dal codice, in netta antitesi ai concetti "object-oriented everywhere". Come al solito, la verità sta sempre un po' nel mezzo. Personalmente ritengo che la modellazione interna di un programma non può che trarre vantaggi dalla modellazione a oggetti; allo stesso tempo, l'interazione tra servizi diversi, su piattaforme eterogenee, non può che essere complicata dalla necessità di implementare dei meccanismi di comunicazione che mischiano standardizzazione dei dati e dei meccanismi di chiamata.
Il concetto di "design-by-contract" applicato a SOA è la parte che mi affascina di più, anche se poi non risolve tutte le situazioni (per esempio tutte quelle in cui si definiscono vincoli dinamici e non solo statici).
L'importante è che questi concetti, pienamente condivisibii, non siano poi adottati come l'unico paradigma di programmazione per qualsiasi tipo di sistema e a qualsiasii livello. Le considerazioni da cui nasce SOA definiscono dei problemi reali esistenti nel mondo "a oggetti" applicato alla programmazione distribuita e a questo dominio andrebbero applicate, per poi valutare pro e contro, nel mondo reale, di questo approccio.
Chi sopravvive (in internet) a un blackout? Per fortuna è capitato durante un sabato notte e non un lunedì mattina... Tutta colpa di un temporale in Francia, dicono. Sarà vero? Beh, queste non sono considerazioni che riguardano questo blog, mentre vedere chi, alle 10.30 del mattino, fa ancora informazione su Internet, questo è interessante.
Il servizio più attivo è
RaiNews 24: presumibilmente il servizio pubblico è ancora considerato tale e quindi dotato di appositi gruppi elettrogeni. Non va tanto bene invece a
Il Nuovo (non raggiungibile, ma
Google News l'ha indicizzato, quindi sembra un problema di routing) e a
Repubblica, che informa in home page che a causa del blackout non possono aggiornare le pagine.
Corriere della sera e
La Stampa, invece, sono raggiungibili (ma al Nord il blackout è già finito) ma non aggiornati, se non per un riquadro alimentato da notizie di agenzia.
Complessivamente, quando mi sono collegato mi aspettavo uno scenario peggiore anche solo in termini di connettività.
Leggo un interessante spunto di discussione in un
blog di Carlo Cardella, blogger ospite di DevLeap.
Carlo si chiede come mai persone sostenitrici di Java e Linux, entusiasti dell'Open Source, si preoccupino della facilità con cui si può fare reverse engineering in .NET. Non è la prima volta che mi capita di sentire un ragionamento simile: "il software che scrivo io è prezioso e deve essere ultra-protetto, quello che scrivono gli altri deve essere gratuito e liberamente disponibile".
Questo schema mentale lo ritrovo spesso anche in persone che lavorano (e a volte possiedono) delle software house: se trovano delle librerie o dei tool shareware, li usano senza preoccuparsi del pagamento della registrazione (di solito poche decine di euro), magari sfruttando qualche crack reperibile sulla rete. Il software che producono, poi, è protetto con chiavi hardware.
Personalmente faccio uso di componenti e tool shareware. In particolare, chi mi conosce sa che ogni tanto ho detto "se devo mettere una libreria in un mio prodotto, voglio avere i sorgenti". Questo non implica che il tutto debba essere gratis, ma è semplicemente legato a un'esperienza che ho fatto nel passato. Utilizzando una libreria (senza sorgenti) in un prodotto commerciale, è capitato che un bug fosse imputabile alla libreria e non al codice del nostro software. L'azienda non produceva più la libreria (non era shareware ma un normale prodotto commerciale). Risultato: dovemmo cambiare libreria, ma questa volta ne scegliemmo una coi sorgenti, in modo da avere la possibilità di capire come effettuare eventuali work-around in piena autonomia, anche a distanza di anni.
Il ragionamento di fondo è: avere accesso ai sorgenti
non implica che quel codice sia gratuito. Per me è una garanzia di manutenbilità del codice e di maggiore documentazione (quante volte per capire meglio il funzionamento di una classe del Framework ho usato
Reflector o
Anakrino).
Appena uscito
InfoPath 2003 SDK: non ho tempo di vederlo in questo periodo, ma sicuramente è da prendere.
Ok magari non sono tutti belli, ma almeno sono tutti bravi :-)
Sul sito di
MSDN.
Link:
http://www.msdn.microsoft.com/events/pdc/buzz.aspx
More Posts
Next page »