dicembre 2004 - Posts
Tutti fanno una lista dei buoni propositi per il 2005,
quindi perché tirarsi indietro?
Il bello di farlo sul blog è che l'impegno diventa più "impegnativo", almeno
psicologicamente. Siccome la cosa può aiutare...
- Un nuovo linguaggio da studiare nel 2005: sono indeciso tra un ritorno al
C++ (quello di VS2005 è da reimparare, in un certo senso) e una divagazione in
terre lontane (Python, come Sam
Gentile).
- Un libro da
scrivere: mi ero ripromesso di riprenderlo entro la fine dell'anno e non
ce l'ho fatta... ma nel 2005 devo finirlo, assolutamente.
- Partecipare attivamente a un progetto "open". Promessa da
marinaio visti gli altri impegni, ma una mano cercherò di darla; anche se
avrei molte idee, devo trovare un progetto gestito da qualcun'altro, non posso
fare tutto (devo anche lavorare, no?). Si accettano candidature...
- Scrivere altri due articoli su Win32 e completare la serie (al momento c'è
solo il
primo). Questa è una promessa difficile da
mantenere...
- Decidere cosa comprare tra Qtek 9090, Motorola MPx e I-Mate SP3.
- Riuscire a stare una settimana senza leggere la posta.
Ok, arrivato al punto 6 mi sembra che se già le promesse da 1 a 5
sono difficili, questa è da fantascienza, quindi chiudiamo qui il 2004. Nel 2005
usciranno Visual Studo 2005 e SQL 2005 e già solo uno di questi basterebbe a
impegnare un anno lavorativo, siccome l'impegno sarà doppio... ci sarà da
divertirsi e non ci sarà tempo per fare tutto.
Buon 2005!
powered by IMHO
Grazie a questa segnalazione di Andrew Stopford ho letto il documento di presentazione di Fugue, parto di Microsoft Research che consente di analizzare staticamente il codice (in formato IL) per verificare il rispetto delle specifiche di utilizzo di un protocollo, come può essere un socket o addirittura alcune classi di ADO.NET. In pratica è possibile trovare errori come l'uso di una risorsa prima di averla aperta e/o la "dimenticanza" della chiusura (o Dispose) di un oggetto dopo averlo usato; il tutto senza eseguire il codice e fornendo un set di attributi che consente di decorare una qualsiasi classe in modo che definisca le regole che poi Fugue va a verificare.
Con tutti i limiti che può avere (e che sono anche ben chiariti nel documento) si tratta comunque di uno strumento interessante e promettente.
Ho appena letto questa interessante considerazione di Paul Thurrot su come Microsoft sia cresciuta al punto di avere problemi simili a IBM (almeno a quella IBM che fece fallire OS/2). L'analisi è molto lucida e, sebbene necessariamente semplificativa, offre uno spunto di riflessione che mi fa tornare alla mente alcune considerazioni sulla "centralizzazione" del reparto produttivo a Redmond. Paul fa notare come XP SP2 e MSN Search siano nati al di fuori delle "gerarchie consolidate" di Microsoft.
È vero che non siamo più all'epoca del PC costruito in garage (così nacque la Apple di Steve Jobs, secondo la leggenda), ma è evidente l'idiosincrasia della situazione: da una parte Microsoft è troppo grande per essere veloce con tanto di blog come Mini-Microsoft che spingono per un ridimensionamento, dall'altra è a corto di personale (il numero di posizioni aperte è sempre elevato) e nei blog dei vari PM è frequente trovare la considerazione che anche in MS le risorse sono limitate e non si può fare tutto quello che viene richiesto (uno su tutti: Chris Pratley, PM di OneNote).
Probabilmente la verità non sta in nessuno degli estremi e Paul Thurrot sfiora un argomento su cui ho già espresso in passato alcune considerazioni, anche se per motivi diversi: la centralizzazione dello sviluppo a Redmond (anche se non assoluta è ancora molto molto forte) ha dei vantaggi organizzativi ma ha un prezzo da pagare sotto i fronti più disparati: politici, culturali, psicologici, di competitività e probabilmente altri ancora.
Se queste tesi hanno un fondamento, la minore competitività di Microsoft provocherà qualche reazione; qualche ipotesi:
- delocalizzazione: mi sembra complementare ad altre iniziative ma di per sé non sarebbe strategica;
- drastica riorganizzazione: non dettata da esigenze di bilancio quanto di competitività; chi è in Microsoft dice che le cose in realtà cambiano anche fin troppo spesso, ma il senso sarebbe di dare una scossa a tutto il ciclo di vita del software all'interno dell'azienda;
- acquisizioni mirate: un cambiamento grosso (in termini di volumi) l'avrebbe fatto il matrimonio con SAP, ma in realtà la "flessibilità" non sarebbe aumentata, anzi...
- diversificazione in altri settori: in realtà Microsoft lo fa già, pur rimanendo ancorata al suo core-business originale, a cui tutte le altre attività fanno in qualche modo riferimento
Il tema più interessante fornito da Paul è però il fatto che ora i concorrenti hanno meno paura di Microsoft. Se la sfida si sposta dai tribunali al campo dei prodotti e al mercato "vero", non avremo che da guadagnarne. Resta però il dubbio che forse non sia tutto così semplice. L'elemento "security" è una variabile che gioca un ruolo fondamentale se applicato alle dimensioni di Microsoft. Per fare un parallelo, pensiamo a una grande casa automobilistica che mette sul mercato un nuovo modello: un problema di rumorosità dell'abitacolo può essere fastidioso ma non è irrimediabile, mentre un difetto che metta a rischio la sicurezza dei passeggeri può avere effetti devastanti: sia per le cause intentate dai clienti danneggiati (e nel software questo ancora non succede) sia per gli immensi danni di immagine (pensate solo a quanto può avere perso la Classe A dopo il famoso fallimento nel test dell'alce); per ora nel software il problema dell'immagine conta molto più della sostanza. Non dico che nessuno abbia mai perso tempo e soldi a causa di un virus o di un attacco DoS. Però non abbiamo ancora visto all'azione il vero terrorismo informatico su larga scala. Purtroppo il problema non è se ma quando (e soprattutto come). L'aumentare della dipendenza dai sistemi informatici (e dalla rete Internet in particolare) non fa che rendere l'obiettivo più appetibile e allo stesso tempo più vulnerabile (pensate a cosa succede quando il VoIP sarà diffuso, non ci vorranno molti anni). Per tornare al parallelo con l'industria automobilistica... quello che si può perdonare a un costruttore di prototipi non è tollerato a una grande casa automobilistica. Oggi nel software assistiamo allo stesso fenomeno "psicologico", ma se centinaia di milioni di utenti domani usassero Firefox qualcuno dei problemi segnalati da Peter Torr aprirebbe le porte a molti nuovi virus e simili di nuova generazione.
Chiunque si accinga ad affrontare i grandi volumi si troverà ad affrontare gli stessi identici problemi di Microsoft nel campo della sicurezza, così come per qualsiasi grande casa automobilistica lo studio della sicurezza non è un optional e ha costi (e tempi) che incidono sulla flessibilità dell'azienda di rispondere alla domanda del mercato. Comunque credo che esista del margine per fare meglio di Microsoft: sui grandi numeri non è facile, ma c'è già qualcuno che ha deciso di provarci, stuzzicando così anche la stessa Microsoft a fare di meglio...
L'ultima settimana dell'anno è tempo di bilanci: come è stato il 2004?
Prima di cominciare, ho dato uno sguardo ai miei post di un anno fa per vedere quali previsioni avrei dovuto smentire... ma per fortuna mi sono limitato dalla tentazione di fare previsioni in pubblico (potrei provarci per il 2005, vedremo).
Partiamo dal nostro piccolo: il blog, i blog e DevLeap. Il blog è vivo, riesco a scriverci assiduamente anche se con qualche pausa di tanto in tanto. Forse è diventato un po' meno tecnico di quello che vorrei, a volte mi sembra inutile ripetere notizie che già ho letto in svariati altri blog. Gli altri blogger su DevLeap viaggiano a corrente alternata, almeno come frequenza; diverse volte ho trovato spunti interessanti e il passaggio al motore di .Text che consente i commenti ha dato modo di instaurare un po' di feedback, anche se resto dell'idea che il grosso lo facciano i post e i commenti abbiano un ruolo decisamente secondario (se non per l'autore, ma quanti li leggono sui blog di altri autori a distanza di tempo?).
Per DevLeap è stato un anno importante: abbiamo fatto molti eventi, tutti gratuiti, riuscendo a far diventare realtà qualcosa come la DevLeap Conference 2004, due giorni "a sfinimento" che restano un ricordo piacevole. Questo ci ha portato a togliere tempo per il sito, in particolare non ci sono stati molti nuovi articoli. Psicologicamente uno pensa che il blog sopperisca in qualche modo a questo, ma sappiamo che non è così. Stiamo pensando a qualche novità per il 2005 ma è presto per parlarne, anche se nel frattempo l'evento DevCon OneDay SOA è già una realtà (14 gennaio 2005 a Brescia, per capire di che si tratta leggete i contenuti in dettaglio).
Per il resto (informaticamente parlando) il 2004 è stato, per uno sviluppatore che usa strumenti Microsoft, un anno relativamente tranquillo. Tante beta (e CTP, e alfa, e Technical Preview...) con cui giocare ma nessun nuovo prodotto significativo con cui mettere in discussione il passato. L'unica eccezione è Reporting Services. Nel frattempo molti sviluppatori continuano a navigare nelle acque tranquille (?) di VB6 e ASP 3.0. Sempre meno, però. In diversi eventi Microsoft (quelli DevLeap non possono fare testo....) ho visto che il numero di sviluppatori "convertiti" a .NET superavano quelli ancorati alla generazione precedente di strumenti di sviluppo. Certo, questa statistica non tiene in considerazione quelli che agli eventi proprio non ci vanno, neanche se sono gratuiti, si mangia gratis e magari regalano pure qualche gadget. Ma il mondo della statistica è bello perché i numeri possono diventare un'opinione. Quanti sono i programmatori in Italia? E chi lo sa. Prima di tutto bisognerebbe mettersi d'accordo su cosa vuol dire la domanda. Se uno chiede "quanti falegnami ci sono?" intenderà solo quelli che lo fanno come attività professionale (che fornisce il reddito principale), quelli che lo fanno come secondo lavoro (il più delle volte in nero, ma anche questo è un altro discorso) o quelli che lo fanno come hobby? E se chi lo fa per hobby poi fa anche qualche lavoretto per la zia, come si configura? Certo, tutti dovrebbero avere gli attrezzi del mestiere... ma non è detto che li comprino, magari se li fanno prestare. Ok, sto divagando, ma il punto è che ormai lo spettro di chi può usare per un qualche motivo un qualche linguaggio di programmazione è diventato immenso...
Allargando ancora un po' l'orizzonte... c'è una considerazione che mi sento di fare. Negli ultimi due anni la crisi economica in Italia ha duramente colpito anche il mercato degli investimenti in ricerca e sviluppo; la cosa ha ricadute evidenti anche nel mondo di chi sviluppa software. Un errore che ho visto fare, vedo fare e (purtroppo) vedrò fare spesso è quello di valutare il problema economico dei costi e di abbattere la scure sulle voci di costo maggiori. Ecco che alcune aziende hanno la brillante idea di sostituire figure professionali "costose" con altre "economiche", senza valutare anche l'aspetto del ritorno dell'investimento e dei costi "derivati". L'esempio semplice è il programmatore "senior" sostituito da uno o due "junior" che però arrivano al risultato nel doppio del tempo (sempre che ci arrivino). L'esempio un po' più complesso è l'apparente abbattimento dei costi a cui si associa un progressivo calo del fatturato, quest'ultimo dovuto semplicisticamente alla "contrazione del mercato", senza che ci si curi di capire se i clienti, per caso, non stanno semplicemente cambiando fornitore. Lungi da me banalizzare la cosa, non è vero che tutte le persone "con esperienza" sono meglio di un apprendista e non è nemmeno sempre vero che "chi più spende meno spende". Ma alla fine i conti si pagano e gli errori pure, anche se magari ciò avviene a distanza di tempo e chi ne paga le conseguenze magari non è nemmeno il maggiore responsabile. Ne parlavo a pranzo anche qualche giorno fa. Su una scala più grande, la realtà è che (specialmente in Italia) le aziende commettono spesso l'errore di considerare le risorse umane come un costo prima che come una vera "risorsa" (asset, in inglese, rende meglio il concetto). Per fortuna nel 2004 ho conosciuto diverse aziende che non commettono questo errore; purtroppo anche nel 2004 ho visto altre aziende commettere questo errore e pagarne le conseguenze. Il mercato, quando viene lasciato funzionare, è giudice imparziale.
Sempre meno tecnici i miei post... devo tornare a occuparmi di codice IL... nel frattempo segnalo questo articolo di Herb Sutter sulla fine della legge di Moore che, almeno per la velocità dei processori, è una dura realtà: la strada del futuro è la parallelizzazione ma per il programmatore che non ha mai oltrepassato la soglia mono-thread saranno tempi sempre più duri.
Stamattina ho disinstallato Google Desktop. I vantaggi di MSN Desktop Search sono troppi.
- Indicizza anche i PDF e i file di OneNote
- Funziona (senza fare cose strane) con utenti non amministratori
- Funziona con più utenti sullo stesso PC
- Ha un'interfaccia di presentazione delle risposte che non richiede il browser
- E' più controllabile (quando indicizzare e quando non farlo, per esempio)
Continuo a vedere alcuni svantaggi:
- Occupa più memoria (circa 130Mb sul mio PC)
- Mancanza di controllo sull'alimentazione del portatile: sarebbe utile che quando il notebook è alimentato da batterie evitasse di indicizzare, anche se non sto facendo nulla (il disco consuma) - questo Google non lo fa, ma la maggiore "aggressività" del motore di indicizzazione di MSN potrebbe essere bilanciata da un controllo simile, peraltro relativamente semplice da implementare.
Credo di aver dato pari opportunità a entrambi, magari proverò le prossime versioni di Google Desktop per vedere se recuperano terreno (il consumo di RAM non è questione da poco).
Poi si dice che certe cose succedono soltanto in Italia.
Il 16 dicembre verso le ore 15 Ian Griffiths segnala una carenza di VS 2005 che a me pareva enorme (e mi ero già ingegnato a superarla): la chiusura immediata della finestra console dopo aver avviato un'applicazione con CTRL+F5 (con VS 2003 rimane aperta fino a che non si preme un tasto ed è una cosa utilissima per fare piccoli programmi di test). Il problema è che il bug appariva al momento una feature by design.
Poco dopo Chris Sells nota la cosa ed esprime analogo disappunto sul suo blog. A 40 minuti di distanza dalla segnalazione di Chris, il bug veniva risolto (guardate l'ora del fix nella scheda).
Il 16 dicembre verso le 21 Ian Griffiths segnala che il problema è stato risolto.
Morale: ho almeno un bug o due di prodotti Microsoft che vengono spacciati come "feature by design". Evidentemente non sono abbastanza immanicato per far scalare la cosa ai giusti livelli. Qualcuno dispone di conoscenze altolocate nel team di sviluppo di Office, per caso?
Ho appena installato la nuova beta di MSN Toolbar.
Il primo ostacolo è stato quello di installarlo su Windows 2003: in teoria non è supportato, in pratica c'è già chi ha trovato come fare. Non sto a spiegarlo meglio perché se non sapete cosa state facendo smanettando con i parametri di msiexec rischiate di farvi del male.
Mentre provavo gli shortcut ho scoperto che Windows Key + S con OneNote fa uno screen clipping che è di una comodità allucinante - averlo scoperto prima!
La Deskbar (o il Deskbar? uhm...) dimostra tutta la precarietà della beta perché finora mi ha fatto esplodere un paio di volte explorer (che peraltro riparte senza tanti problemi, ma qualche tray icon si perde inesorabilmente con questi traumi).
Mentre indicizza... il paragone con Google Desktop Search è per ora nettamente a vantaggio di MSN Toolbar: indicizza anche i PDF, è meglio integrato in Windows, non apre il browser solo per far vedere i risultati della ricerca, funziona con N utenti sul PC (e indicizza solo i contenuti di ciascun utente facendoli vedere solo a lui). Anche graficamente è un'altra cosa.
MA... ma un motore di ricerca deve prima di tutto essere preciso, accurato e veloce nel rispondere alle richieste. Ci vorrà qualche giorno di prove per capire la reale qualità del prodotto. Da questo punto di vista Google Desktop, pur con tutti i suoi limiti, offre risultati buoni. Vedremo.
Ora è ufficiale: PDC 2005 sarà a Los Angeles da 13 al 16 settembre 2005, con due giorni di pre-conference l'11 e 12 settembre. In effetti i rumors che ho riportato qualche giorno fa erano fondati.
Ho già scritto un post dubbioso sul Motorola MPx. Stasera ho cercato di fare un po' il punto della situazione.
Negli USA l'uscita dell'MPX è imminente: si trova già il PDF del manuale (trovato grazie a msmobiles.com). Non si sa ancora con quanta RAM sarà disponibile e come saranno realmente le prestazioni. nubi fosche all'orizzonte.
Per non aspettare febbraio e l'incognita da early adopter ho visto un po' di alternative Qtek:
- Qtek 8080: Smartphone con Windows Mobile 2003 Second Edition: qui saliamo intorno ai 250€. Modello che ha già un anno, ma è anche il più economico.
- Qtek 8010/8020: Smartphone Windows Mobile 2003. Prezzo intermedio (intorno ai 450€ sui siti dove l'ho trovato), è il più leggero (100 grammi) e anche il più piccolo. Forse è ancora difficile da trovare.
- Qtek 9090: Si passa a un PocketPC Phone Edition. Prezzo alto, siamo a 800€ (senza accessori... facile arrivare a 900). Bello, tastiera a scomparsa, ovviamente più ingombrante ma 210 grammi non sono un dramma. Processore veloce e tanta RAM (128Mb). Quadriband, Bluetooth e Wifi. Peccato la risoluzione, solo 240x320 (perché negare un bel 480x640?).
Riassumendo: l'anima geek direbbe di prendere il 9090, la parte razionale suggerisce di cercare un 8010 senza farsi spennare troppo per poi vedere come andrà l'MPx e decidere di conseguenza, chi non vuole buttare via i soldi dovrebbe cercare un 8080 su eBay e andare avanti qualche mese per vedere che succede. Non ho ancora deciso...
PS: non ho messo link ai vari Qtek perché non c'è un sito ufficiale e avrei finito per fare link con qualche sito che lo vende, preferisco non fare pubblicità a nessuno, comunque usando Google e Kelkoo trovate tutto.
E meno male. Nel post precedente ho completamente sbagliato l'assunzione di partenza per cui un sistema in base 6 sarebbe più comodo di un sistema in base 10 per gestire ora, minuti e secondi. In poco tempo ho subito ricevuto le rettifiche del caso da parte di qualche lettore e ho provveduto a correggere un po' il post, senza peraltro eliminare del tutto le parti incriminate (per fortuna che in HTML c'è lo <strike>).
Lezioni da trarre:
- meglio non parlare di storia in un blog tecnico (anche se l'errore non era lì... forse era un'escursione troppo avventurosa!)
- quella postilla che c'è in tutti i libri "scusate per tutti gli errori che troverete nel libro" è ahimé vera e si applica a qualsiasi testo scritto, blog compreso
Non sapevo (o per lo meno non ricordavo) che i sumeri avessero un sistema numerico in base 12 anziché in base 10. Per questo motivo (anche se la spiegazione completa è più complessa) il giorno è diviso in 24 ore di 60 minuti di 60 secondi.
In un software che deve lavorare con ore-minuti-secondi è sempre "divertente" fare tutte le operazioni del caso. Per esempio in un sistema di rilevamento presenze che deve calcolare le ore lavorate c'è sempre da fare qualche acrobazia per conciliare le necessità algebriche con quelle normative (chi ha mai lavorato nel settore capirà).
UPDATE: da qui in poi ci sono alcuni errori - per correttezza lascio il post originale con le correzioni dopo, leggete anche i commenti al post END OF UPDATE
Solo oggi, leggendo su un libro (non nel link che ho riportato sopra) del sistema numerico dei sumeri, ho realizzato che sarebbe estremamente efficiente lavorare in base 6 per maneggiare ore, minuti e secondi. Si potrebbe fare in base 12, ma in base 6 è per noi più intelleggibile perché facilmente esprimibile con cifre decimali. Ne parlavo con Sergio che mi ha fatto notare le seguenti cose.
In base 6 un giorno avrebbe 40 ore di 100 minuti.
In base 6 le 5:99 + 1 minuto farebbe 6:00, bello :)
- Ma i sindacati non approverebbero perche' la gente tornerebbe a lavorare 12 ore al giorno
- Ma d'altra parte si alzerebbero tutti la mattina verso le 10
UPDATE In realtà, come giustamente ha fatto notare Mauro nei commenti, in base 6 abbiamo solo le cifre 012345, quindi per scrivere 60 (base 10) dovremmo scrivere 140 (base 6), quindi le 5:59 (base 10) corrispondono a 2435 minuti (base 6) dopo la mezzanotte. Non è molto comodo. Se invece usiamo la base 12 abbiamo le cifre 0123456789AB (un esadecimale mozzo insomma). Per scrivere 60 (base 10) possiamo scrivere 50 (base 12), le 05:59 (base 10) corrispondono a 20B (base 10) minuti dopo la mezzanotte. Anche se internamente può venire comodo, resta il problema che per rapportare tutto alla base decimale (separando ore minuti e secondi) bisogna sempre fare un po' di conversioni di troppo. Mi sa che non ne vale la pena. END OF UPDATE
Scherzi a parte, la prossima volta che dovrò gestire cose simili valuterò seriamente di creare un tipo che lavori in base 6, con cui fare tutte le operazioni del caso farò bene i conti prima di pensare ai sumeri...
Brutto modo per cominciare un venerdì. Ho appena letto questo post di Peter Rysavy che indica come fonte questo forum.
La prima notizia è che il Motorola MPx è atteso per il primo trimestre 2005. Questo lo si poteva immaginare, più volte ho letto febbraio 2005 come data prevista di uscita.
Le cattive notizie sono che in questi giorni, in una conferenza a Seattle (Mobius), alcuni partecipanti hanno provato una versione (si presuppone quasi definitiva) del Motorola MPx. I problemi sono:
- Poca RAM (solo 32Mb)
- Processore lento
- Batteria che dura poco (questa è in realtà una supposizione, nessuno l'ha ancora usato abbastanza a lungo)
Il problema della RAM è che subito dopo il boot ci sono pochissimi Mb disponibili, al punto che sembra impensabile riuscire a installarci altro software. La speranza di tutti è che la versione definitiva esca con almeno 64Mb di RAM.
Con il Natale vicino la tentazione di prendere un device più "normale" (sempre Smartphone o Phone Pocket PC) e lasciar fare l'early adopter a qualcun altro è sempre più forte.... Nel frattempo mantengo strenuamente in vita il primo Smartphone 2002 che ho da un anno e mezzo.
Notizie poco tecniche ma interessanti: MSN ha inaugurato MSN Spaces e ha rilasciato la beta pubblica di MSN Messenger 7.
MSN Spaces è, se vogliamo, l'ennesimo host di siti personali... però fatto con un occhio particolare alla semplicità e immediatezza d'uso. Ideale per chi vuol condividere musica, foto, pensieri e altro con i propri amici. Si può scegliere se fare un sito pubblico o "privato", nel senso che non viene poi indicizzato ed è accessibile solo a chi si desidera.
Messenger 7 è un reale upgrade di MSN Messenger a cui aggiunge veramente qualche funzionalità. Tra l'altro ieri sono anche riuscito a configurare ISA Server 2000 per far funzionare audio e video di MSN Messenger, se qualcuno è interessato qui trovate lo script di configurazione.
Ho appena letto un post di Brad Abrams dove viene indicata una delle nuove linee guida per la sicurezza in .NET. Non sto a riportare il codice, in pratica il problema evidenziato è che in .NET una funzione potrebbe validare un parametro per poi usarlo per farci qualcosa... mentre nel frattempo qualche altro thread potrebbe cambiare i valori subito dopo la validazione ma prima dell'esecuzione dell'operazione; nell'esempio il chiamante passa un elenco di nomi di file da cancellare, il metodo controlla che siano percorsi "autorizzati" ma subito dopo la validazione un altro thread modifica l'array e ottiene la cancellazione di un file che non doveva essere cancellato.
La soluzione è un po' costosa: fare una copia del parametro prima della validazione, così non può essere modificato dall'esterno.
Potrebbe sembrare uno scenario ai confini della realtà (nel mondo reale questa situazione è tutt'altro che facilmente riproducibile) ma la sicurezza è paranoia. Tra l'altro, il problema esposto non è nemmeno una peculiarità del Framework ma potrebbe valere anche per qualsiasi scenario unmanaged. Speriamo che non dia l'idea a qualcuno...
Il Garbage Collector è uno degli argomenti "base" del framework su cui (stranamente) non ho mai scritto nulla (né nella sezione CLR del sito né nel mio libro CLR Full Contact), nonostante sia un argomento importantissimo in corsi e seminari che tengo; in passato ho anche fatto un webcast sull'argomento che è ancora possibile rivedere.
In questo periodo non ho tempo per scrivere (a parte qualcosa di breve sul blog) per cui consiglierei a tutti di leggere il post di Rico Mariani sull'uso di GC.Collect e su quando possa avere senso richiamarlo. Mi raccomando, non fermatevi al post ma leggete i commenti: molti dimostrano di non conoscere abbastanza bene il funzionamento del Garbage Collector e l'importanza di chiamare Dispose sugli oggetti che implementano IDisposable.
Come dice Rico, sono pochissimi i casi in cui è davvero necessario ricorrere all'uso di GC.Collect. Ricordo che giusto un paio di giorni fa parlavo del CLR Profiler, tool che è molto utile anche per comprendere il funzionamento interno del Garbage Collector.
Sarebbe interessante avere dei feedback su dei problemi riscontrati nel "mondo reale" sia nell'uso da parte vostra che nell'uso che avete visto fare da altri: mi piacerebbe capire se e quanto è un problema diffuso e che ripercussioni ha sulle applicazioni che vanno in produzione. Per me è un argomento quasi scontato ma forse non è così e bisogna fare ancora formazione su questo tema. I commenti sono aperti...