maggio 2004 - Posts
Nel week-end non ho fatto post poco-tecnici e così recupero il lunedì (in realtà ce n'era uno in anticipo di venerdì... ma fa lo stesso).
Voglio fare qualche segnalazione per dei blogger ospitati sul nostro sito. La prima è per Francesco Quarantino, che ha conseguito la certificazione di MCDBA: ho ricevuto tanti feedback a un mio precedente post sulle certificazioni e fa piacere vedere qualcuno che raggiunge dei risultati. A chi me l'ha fatto notare, assicuro che il feedback sui costi degli esami di certificazione è arrivato in Microsoft. Non so se potrà avere un qualche effetto, ma una grattatina al muro l'abbiamo data...
Seconda segnalazione per Claudio Brotto: ha aperto il suo blog su DevLeap da una settimana e oltre a postare tutti i giorni (almeno finora!) si caratterizza per la lunghezza dei suoi post (potrebbe quasi battere il sottoscritto), in cui ci sono spesso interessanti spunti di riflessione.
Ora, che c'entra 42? Ci arriviamo. Claudio ha segnalato in un suo post un linguaggio per .NET chiamato Nemerle. Ho dato un'occhiata al confronto sintattico con C# e non ho potuto fare a meno di notare che in un paio di esempi si usa il numero 42.
Normalmente è qualcosa cui non faccio più caso, ma meno di una settimana fa mi è capitata questa cosa: stavo tenendo un breve seminario (o dovrei dire lezione?) all'università di Milano (su Win32) quando, non ricordo bene la circostanza, ho fatto un'allusione al significato di 42 per un informatico. Un rapido sguardo alla platea mi ha fatto comprendere che nessuno aveva capito il senso della mia frase, tranne il professore. Ricordo altrettanto bene che qualche anno fa, in una circostanza diversa, era capitata la cosa opposta (le persone più adulte non capivano il senso, al contrario di quelle meno adulte).
Ora, se non avete capito di che cosa sto parlando, seguitemi attentamente: aprite qualche libro di informatica dove ci siano degli esempi di codice (il linguaggio è irrilevante) e cercate dei punti in cui nell'esempio serva un numero più o meno casuale. Ripetete l'esperimento più volte e con libri diversi.
Noterete una frequenza assolutamente anomala di occorrenze del numero. Potete provare anche a guardare sulla documentazione di MSDN, ma anche con testi che spiegano Java, Oracle e probabilmente anche la programmazione di sistema di Linux. I risultati non dovrebbero cambiare di molto.
Noterete anche che la frequenza di 42 è ancora più alta se il numero è il valore restituito da una funzione (gli scrittori più estrosi usano questo numero come valore ottenuto da un calcolo numerico, senza scriverlo in maniera esplicita nel codice: il lettore deve fare i conti per vederlo).
Avete provato? Non l'avete fatto ma andate sulla fiducia? Bene.
Ora, SENZA USARE GOOGLE (né altro motore di ricerca) provate a indovinare il motivo per cui si usa sempre 42 (se lo sapete non vale, tanto vi becco). Oppure, semplicemente, scrivetemi per dirmi che non lo sapete (e non abbiate paura, avete degli ottimi motivi per non saperlo!).
Prometto che alla quinta richiesta pubblicherò un post di spiegazione. Se non arriviamo a cinque richieste risponderò solo via mail.
Altrimenti usate Google, ma allora perché avete letto fino alla fine??
Uno dice: abbiamo .NET, non dobbiamo più preoccuparci delle differenze architetturali dell'hardware, nemmeno di quelle tra 32 e 64 bit...
La realtà è un po' diversa, ma a volte per motivi che è difficile immaginare. I processori come Itanium hanno delle caratteristiche che inducono i compilatori (nonché l'unità di esecuzione della CPU) a "riordinare" il codice se, dal punto di vista del thread in esecuzione, non esistono interdipendenze tra le istruzioni. Chiaramente questa cosa, in un contesto multi-thread, può portare ad avere dei problemi.
Non vorrei stare a tradurre tutto il discorso, questo vecchio messaggio di Vance Morrison spiega abbastanza chiaramente quale è il problema. Lo spunto per andare a rileggere questo messaggio me l'ha dato uno dei commenti a un (non più tanto) recente post di Brad Abrams, che affronta le differenze tra volatile e System.Threading.Thread.MemoryBarrier(). Devo confessare che l'argomento merita di essere approfondito perché mantengo qualche piccolo dubbio su quale sia l'utilizzo corretto di volatile, MemoryBarrier e WriteMemoryBarrier (quest'ultima citata nel post di Vance Morrison ma non documentata e non presente in .NET 1.1). Mi devo procurare una macchina a 64 bit multiprocessore, ma soprattutto un po' di tempo (risorsa molto più difficile da trovare).
La questione è molto meno accademica di quanto sembra: immaginate un programma (con operazioni asincrone di qualsiasi tipo) che funziona perfettamente oggi ma che domani, eseguito su una macchina con almeno due Itanium a bordo (non so ancora dire se AMD-64 presenta caratteristiche simili, ma è possibile), presentasse sporadici malfunzionamenti. E' esattamente il rischio che si corre se non si seguono le giuste precauzioni, anche se per fortuna il codice "a rischio" dovrebbe essere in punti limitati e la problematica diventa tanto più complessa quanto più vogliamo "spingere" la scalabilità del codice (che implica ridurre i lock al minimo indispensabile).
Già mi immagino la "pezza" che qualcuno metterà trovandosi di fronte a un problema più o meno sconosciuto: esecuzione di un processo su singolo processore e tanti saluti alla scalabilità. Aspettiamo ancora qualche anno e vediamo se questa previsione nefasta si avvererà.
UPDATE: leggendo meglio alcuni commenti al post di Brad Abrams ne ho visto uno di Vance Morrison che anticipa l'adozione di un "default" per .NET che consentirà di simulare, anche su processori con un "weak memory model", lo stesso modello di x86 che non è soggetto a problemi di memory-barrier (neanche con sistemi multi-processore). Ovviamente la cosa ha un costo molto significativo in termini di scalabilità, ma per lo meno non obbligherà chi non ne ha bisogno a rivedere tutta la gestione della concorrenza nel proprio codice.
Questa Web Part consente di pubblicare un report di Reporting Services in HTML all'interno di un sito in SharePoint. Una di quelle cose che chiudono il cerchio.
Anche se Visual Studio 2005 Team System avrà un nuovo "source control system", Visual Source Safe continua la sua vita: la versione 2005 avrà molte novità, anche se sembra di capire che il suo utilizzo sarà confinato alle versioni meno "complete" di Visual Studio (quelle dove lavorano pochi sviluppatori) oltre che garantire presumibilimente la continuità col passato.
Se volete capire cosa c'è in Visual Studio 2005 Team System, oltre a questa
overview vi consiglio di leggere direttamente
questo documento: se anche non vi interessa tutto il resto, la sola integrazione di FxCop e le funzionalità di profiling valgono l'onere dell'installazione.
In prossimità del week-end, un intervento un po' meno tecnico del solito (anche se sempre di tecnologia si tratta): da un po' di tempo ero sempre più "piegato" dalla rigidità di Outlook nell'organizzare le mail (e dalla lentezza delle sue funzioni di ricerca).
Quasi due anni fa avevo provato NEO (Nelson Mail Organizer) ma dopo qualche giorno l'avevo disinstallato: consumava troppa RAM e rallentava troppo il PC in generale. Ora, però, ho un notebook con più CPU e tanta più RAM, inoltre nel frattempo NEO è maturato un po' (quindi occupa meno RAM e meno disco e meno CPU, nonostante abbia tante funzioni in più)...
Non capisco come ho fatto ad aspettare tanto. Le funzionalità chiave (per me) sono:
- Organizzazione dei messaggi per interlocutore (con messaggi ricevuti e inviati nella stessa cartella)
- Ricerca dei thread di messaggi (per subject, con messaggi ricevuti e inviati nella stessa cartella)
- Ricerca full-text nel contenuto dei messaggi
Prima che qualcuno mi risponda dicendo che Outlook 2003 fa già tutte queste cose, valutate che i tempi di risposta sono immediati (indici bitmap... eheheheh) e che le prestazioni, per questo genere di cose, sono tutto. Per 40$ (70$ la versione PRO, che ha poche funzionalità in più ma importanti se avete Gb di archivi) mi sembra quasi regalato.
Ora, giusto per dire qualcosa di tecnico... NEO è scritto in Delphi. Ho visto un sacco di buon software scritto in Delphi e qua la domanda che uno si pone è: Delphi lo usa chi sa scrivere bene il software o il software scritto in Delphi viene meglio anche se uno non è tanto bravo? Meno male che .NET assomiglia così tanto a Delphi (le classi Windows Forms sono praticamente uguali alle VCL, controlli windoless a parte), altrimenti non so se sarei riuscito a staccarmi da Borland così facilmente...
Abbiamo appena aggiornato la pagina logistica relativa alla DevLeap Conference di Napoli, aggiungendo le informazioni sui mezzi pubblici disponibili per raggiungere l'hotel Holiday Inn arrivando alla stazione ferroviaria di Piazza Garibaldi.
Riporto di seguito le informazioni aggiunte, ringraziando Francesco Quarantino che ha investigato sulla cosa e ci ha segnalato queste informazioni.
MEZZI DI TRASPORTO PUBBLICI A NAPOLI
Per l'edizione di Napoli l'hotel dove siamo (Holiday Inn) è relativamente vicino alla stazione ferroviaria (Piazza Garibaldi), ma se volete usare i mezzi pubblici per arrivarci (dalla stazione ferroviaria) ecco le informazioni che abbiamo ricevuto dalla ANM - Azienda Napoletana Mobilità www.anm.it.
Per raggiungere l'hotel Holiday Inn da piazza Garibaldi, bisogna prendere l'autolinea C40 alla fermata antistanta l'entrata della stazione ferroviaria altezza Mac Donalds; oppure la linea C30 presso il nostra stazionamento sito al lato opposto.
Se non avete le idee chiare sul Data Mining o se volete capire meglio come implementare una soluzione basata su algoritmi di Data Mining, questo PDF di oltre 100 pagine vi fornisce un'introduzione e una serie di esempi pratici realizzati con dati reali. Tutto con tecnologia "attuale" (SQL 2000, Analysis Services 2000 e VB6).
Molte funzioni "rifatte in VB6" saranno disponibili in SQL Server 2005 (Yukon), ma per capire come funzionano queste cose potete partire già adesso. E Analysis Services 2000 può dare già qualche soddisfazione (è vero, scrivendo un po' di codice, ma sarà così anche in SQL Server 2005).
Ho corretto un mio post precedente segnalando il link corretto per il download delle slide di WinHEC2004.
Nel futuro prossimo avremo un maggiore supporto per Bluetooth in Windows XP SP2. In un futuro più lontano, è interessante vedere come evolverà Windows per garantire maggiore sicurezza e affidabilità, anche rispetto (e a dispetto) di hardware problematici. Consultando le slide della sessione Windows Core Platform Reliability Innovations è possibile scoprire notizie curiose, come i problemi dati dalla memoria difettosa (di tipo non ECC, tanto che si consiglia l'adozione di memorie ECC su tutti i client - ma non saranno solo problemi di overclock o di chip troppo economici?) e la crescente complessità di un sistema che, non potendo cambiare l'architettura di base (quella del kernel di NT, che poi non è così male dopo tutto) deve arricchirsi di servizi collaterali per la diagnostica post-mortem dei problemi bloccanti (driver e hardware sono messi ormai sullo stesso piano).
Altrattanto "inquietante" l'idea di avere megabyte di memoria NVRAM (RAM non volatile, che non si cancella spegnendo la macchina, insomma) solo per salvare dei log (non è detto che dopo un crash si riesca ancora a scrivere qualcosa sul disco, no?). Vero che RAM che tra qualche anno supererà il muro del Gb su macchine "entry-level" (diciamo 2008/2009?) l'idea di una manciata di Mb equivale a una memoria tamponata di qualche byte per salvare le impostazioni del BIOS sui PC che avevano 640Kb di RAM (era la situazione ordinaria a fine anni '80).
Non vorrei dire un'eresia, ma un mainframe di venti anni fa era meno complesso di quello che sta diventando un PC. E il mio Smartphone ha più RAM di minicomputer che ospitavano decine di utenti e facevano girare intere aziende. Divertente questa cosa.
Clemens Vasters segnala Regulator, un utile tool per la costruzione di Regular Expression. Non l'ho ancora provato, ma dagli screenshot sembra veramente notevole.
Qualcuno avrà notato che da qualche giorno sono un po' "in ritardo" sulle notizie... capita di restare indietro anche solo con la lettura dei blog... Per questo non riesco a commentare "notizie fresche" ma questa è piuttosto importante.
L'annuncio è che ObjectSpaces sarà rilasciato con Longhorn e sarà integrato con WinFS. Come giustamente fa notare Frans Bouma, l'effetto domino prosegue su Microsoft Business Framework (se non sapete cos'è e scrivete software che normalmente viene chiamato "gestionale"... beh, datevi una mossa, cominciate a usare Google e cercate di essere preparati, lo dico per il vostro bene).
Le reazioni sono le più diverse, per lo più negative, anche se è giusto notare che esistono già package alternativi. Non devo prendere le difese di Luca Bolognese, PM di ObjectSpaces, ma è giusto notare che l'introduzione di questa tecnologia può avere risvolti importanti e un rilascio di release successive incompatibili tra loro sarebbe davvero controproducente. Come ho detto, se qualcuno oggi vuole una soluzione "limitata" al problema del mapping di un modello a oggetti su un db relazionale, le alternative ci sono. Quella di Microsoft, però, diventerebbe *il* riferimento, e non sarebbe semplice spiegare che la versione 1.X non è compatibile con la 2.X.
Questo, almeno, credo sia uno dei problemi più grossi che si devono affrontare. Oltre a quello di raggiungere determinate prestazioni, determinati standard di affidabilità, ecc. ecc. - e ObjectSpaces, va ricordato, è un team relativamente piccolo rispetto ad altri, in Microsoft. Risorse limitate, interdipendenza dei moduli, forse mancanza di pressione da parte della concorrenza... Microsoft (da un punto di vista strategico) si sta veramente giocando tutto su Longhorn, non può permettersi di sbagliare. Ormai non credo più al 2006 come data di rilascio, penso già al 2007. Altri 3 anni di Windows XP, che diventerà la versione di Windows più longeva della storia.
Oggi ho risposto a una richiesta di chiarimenti sull'uso di SyncRoot. Immagino che l'argomento sia di interesse generale (relativamente a chi sviluppa con .NET, ovvio), quindi eccola qua.
1) Le classi collection espongono SyncRoot per consentire una sincronia coerente anche se usano internamente degli oggetti incapsulati che potrebbero essere condivisi da altre parti del codice.
Immagina questa situazione:
class Queue {
void Clear() {
// ....
}
}
class Service {
public Queue Operations;
void CancelOperations() {
Operations.Clear();
}
}
Se usi Service con il lock sull'istanza dell'oggetto potresti incorrere in questo problema:
class Test {
private Service _service;
void MyThreadSafeOperation() {
lock( _service ) {
_service.CancelOperations();
}
}
void MyConcurrentThreadSafeOperation() {
lock( _service.Operations ) {
_service.Operations.Clear();
}
}
}
Le due funzioni MyTreadSafeOperation e MyConcurrentThreadSafeOperation non si bloccano a vicenda, perché usano riferimenti diversi.
Per evitare questi problemi avresti due soluzioni.
La prima è modificare Service.CancelOperations() aggiungendogli un lock( Operations ) prima di chiamare Operations.Clear - ma così fai dei lock inutili (e ripetuti) anche su un programma single-thread.
La seconda è fare sì che tutti i lock avvengano sullo stesso oggetto di riferimento.
class Queue {
public virtual object SyncRoot {
get { return this; }
}
void Clear() {
// ....
}
}
class Service {
public Queue Operations;
void CancelOperations() {
Operations.Clear();
}
public virtual object SyncRoot {
get { return Operations.SyncRoot; }
}
}
Questo va bene in casi di incapsulamento. Come vedi la proprietà è virtuale per gestire i casi di derivazione:
class Queue {
public virtual object SyncRoot {
get { return this; }
}
void Clear() {
// ....
}
}
class SynchronizedQueue : Queue {
public override object SyncRoot {
get { return base.SyncRoot; }
}
void Clear() {
lock( SyncRoot ) {
// ....
}
}
}
In questo caso la derivazione di SyncRoot è superflua, ma il pattern da seguire è sempre questo, casomani in una classe derivata dovessi istanziare oggetti Collection di altri tipi da tenere tutti sincronizzati assieme.
2) Se il tuo codice fa una lock, devi fare:
MessageQueue queue = new MessageQueue();
lock(queue.SyncRoot)
{
queue.Enqueue(message);
}
lock(queue.SyncRoot)
{
queue.Dequeue(message);
}
La regola è: se una classe ha SyncRoot, usa sempre SyncRoot!! (se devi usare l'istanza in contesto multi-thread - se fai un'applicazione che usa un'istanza sempre e solo nello stesso thread, non hai problemi). Anche se l'hai disassemblata con Reflector. TASSATIVO!! Non ci sono eccezioni, perché il giorno che cambiano implementazione o il tuo codice inizia a usare una versione derivata con implementazioni diverse, sei fregato e la tua ottimizzazione rende il codice non più thread-safe.
Ieri sera ho rivisto alcuni software per fare connessioni remote al desktop di un PC. Un software indubbiamente valido è Ultr@VNC, che consente di far collegare più client remoti allo stesso server.
A cosa serve? Per esempio a fare delle presentazioni in tempo reale senza usare un proiettore, a patto che il pubblico abbia un PC in rete, ovvio... Grande controllo sul consumo di banda (un pensiero per chi è collegato in remoto) e progetto open-source, con viewer disponibili per diversi sistemi operativi. Un buon prodotto, insomma. Ne avevo già parlato ma l'ultima versione è molto migliorata rispetto a quella che avevo provato circa sei mesi fa.
Entro giugno dovrebbe uscire un add-in per Excel che fornisce nuove funzionalità di interrogazione per i cubi OLAP.
Non ho altre informazioni per ora, ma valeva la pena di segnalare la cosa. Spero di avere altri dettagli al più presto.
Ho pensato molto prima di scrivere questo post, perché non vorrei che sembrasse un post di autocompiacimento, però credo ci siano ragioni che sopravanzano questo timore, come spiegherò tra poco.
Abbiamo ricevuto (e stiamo ancora ricevendo) un numero impressionante di feedback per la DevLeap Conference di Bologna, soprattutto se consideriamo il rapporto rispetto al numero di partecipanti. Speriamo di essere riusciti a rispondere a tutti, anche soltanto dicendo grazie.
La maggior parte dei commenti esprime soddisfazione, per fortuna c'è anche qualche critica, sempre molto costruttiva, e tanti suggerimenti per il futuro. C'è chi ha speso molti minuti del suo tempo (temo qualcuno abbia sforato la mezz'ora, per lo meno...) per dirci cosa ha seguito, cosa ha capito, cosa ha perso, cosa gli è piaciuto, cosa avrebbe voluto vedere, e così via. Qualcuno ha anche velatamente lasciato intendere che certe sessioni potevano essere anche più approfondite. Elettrizzante. Sapere di aver catturato il pubblico "giusto" è una grande soddisfazione.
L'imbarazzo di cui accennavo nel titolo deriva proprio dal ritorno inaspettato che abbiamo avuto. Non è la prima conferenza in cui siamo presenti come speaker, ma è stata la "prima" conferenza DevLeap. Che dire... grazie ancora e continuate a mandare feedback: forse qualche spunto più critico ci aiuterebbe a tenere i piedi per terra :-)
A questo punto, provo a fare un piccolo appello. Il 22 e 23 giugno replichiamo a Napoli tutta la conferenza. Non è nostra intenzione fare pubblicità "massiva" a questo evento, un po' perché non abbiamo i mezzi per farlo e un po' perché vogliamo raggiungere il pubblico adatto a questo genere di eventi. Purtroppo le iscrizioni finora sono leggermente al di sotto delle aspettative. Effettivamente manca ancora più di un mese, ma Napoli è una tappa importante perché si tratta di una scommessa per vedere i ritorni che questo genere di eventi possono avere anche al Sud. Un buon successo di pubblico (ovviamente interessato) potrebbe essere un segnale per stimolare nuove iniziative, magari anche in altre città.
Siccome forse il problema è anche nella comunicazione (chi ci segue magari ci ha incontrato in un evento spesso a Milano e dintorni), provo a chiedere questo piccolo piacere: se conoscete qualcuno che potrebbe essere interessato a questa conferenza, segnalategliela. Specialmente se potrebbe trovare più comodo andare a Napoli piuttosto che a Milano (città dove è più facile trovare eventi simili). Da cosa nasce cosa e il passaparola è uno strumento di marketing molto più efficace. Probabilmente gli fate un piacere e ne fate uno anche a noi.
Grazie!
More Posts
Next page »