Qualche segnalazione e 42

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??

Programmazione multi-thread su processori a 64 bit

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.

Visual Source Safe 2005

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.

Organizzare le mail

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…

Logistica DevLeap Conference Napoli

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.


 

Libro gratuito su Data Mining (da Microsoft)

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).

Uno sguardo al futuro da WinHEC 2004

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.