marzo 2004 - Posts
Dura da mandare giù, ma in questo post John Williams spiega i perché di questa scelta.
Il dibattito in realtà è ancora aperto. Personalmente preferirei una strada per "tentare" di eseguire a 64 bit un assembly compilato in .NET 1.x senza doverlo ricompilare. Il Manifest mi sembra una buona strada. Comunque il problema è più complesso di quanto non possa apparire a prima vista.
Vi segnalo in anteprima il sito della DevLeapConference 2004: http://devcon.devleap.com. Per i distratti... si tratta di un evento di due giorni dedicato a .NET, Whidbey, Yukon e Longhorn. Due repliche: Bologna 11 e 12 maggio 2004, Napoli 22 e 23 giugno 2004. Tante sessioni, livello tecnico elevato, pochi fronzoli, niente pranzo, partecipazione gratuita.
Abbiamo già messo on-line l'agenda, la descrizione dei track, la descrizione delle sessioni e un minimo di informazioni logistiche (che dovremo completare).
Fondamentalmente manca ancora il link per iscriversi, ma in settimana ci sarà anche quello. Per ora potete incominciare a valutare se venire un giorno o due e a liberare di conseguenza la vostra agenda.
Per eventuali segnalazioni o chiarimenti... scriveteci.
Chris Sells segnala che la nuova preview di Whidbey che è già disponibile agli abbonati a MSDN (Visual Studio 2005 Community Technology Preview March 2004 è il nome ufficiale) non funziona con Longhorn (o per lo meno con la versione di Longhorn che abbiamo a disposizione oggi). Siccome non funziona neanche con Yukon... bisognerà fare un'altra installazione ex-novo...
Il sito di Microsoft XNA non fornisce ancora molte informazioni (si tratta, più o meno, di un Game Developer Kit).
Ma il primo video che trovate (Crash Test, è quello in alto a destra sulla home page) è incredibile. Lo so, è solo una demo.. ma se fra due o tre anni ci saranno videogiochi con questo realismo... cosa vedremo tra sei o sette anni?
Un consiglio: fate il download (sono quasi 30Mb) perché in streaming 2Mb di banda non bastano per avere una visione fluida.
Se avete uno Smartphone come me non potete fare a meno di questa utility. L'ho trovata partendo da questo post su msmobiles.com, che rimanda al sito di Modaco, su cui trovate interessanti forum tutti dedicati allo Smartphone.
Si tratta di un programma che consente di editare il file \IPSM\Application Data\Systemmst9.udb che si trova sullo Smartphone e contiene le estensioni al dizionario T9 usato normalmente. Il dizionario non si può modificare, ma potete integrarlo con delle altre parole, cosa che lui fa in automatico (ogni volta che inserite una parola nuova senza usare il T9 lui la memorizza in questo file).
Inutile aggiungere che, se cambiate Smartphone, basta copiarsi questo file per traslocare anche il proprio dizionario. Adesso mi serve un dizionario di slang informatico per integrare quello del mio Smartphone...
In questi giorni ho letto parecchi commenti sul caso antitrust dell'Unione Europea contro Microsoft. La maggior parte dei commenti, però, si concentra su elementi che balzano all'occhio dell'immaginario collettivo (quasi 1.000 miliardi delle vecchie lire di multa, l'oppressione del diavolo-Microsoft, la sconfitta di Bill Gates, ecc. ecc.). Pochissimo si sono concentrati sull'aspetto tecnico della questione (avessi trovato qualcuno che abbia spiegato in dettaglio cosa si intende per "Microsoft deve rivelare i segreti per far dialogare i propri server col resto del mondo).
A questo punto in questo blog dovrebbe esserci una disquisizione tecnica sulle conseguenze pratiche che potrebbero derivarne. Invece, facendo un'eccezione ai contenuti ospitati tradizionalmente, ne farò una diversa.
Sì, perché nei commenti che ho letto finora non ne ho visto nessuno significativo (ma potrebbe essermi sfuggito) sulle forze politiche in gioco in questo affare. Mi viene alla mente il caso della mancata fusione GE-Honeywell: i paletti posti da Mario Monti (anche se è più giusto dire dalla commissione antitrust) erano tali che Jack Welch (allora CEO di GE) decise che non valeva la pena andare avanti. Un aspetto comune tra i due casi è che c'è coinvolta una grossa multinazionale americana, con enormi mezzi propri (mezzi finanziari, intendo). E' innegabile che, ragionando in termini di Unione Europea, quanto più si fanno crescere delle aziende "all'interno" in un mercato come quello della UE che continua a crescere (anche grazie all'allargamento dei confini), tanto più si acquisisce massa critica per contrastare le multinazionali americane (nel senso che sono multinazionali ma che hanno origine negli USA) sui mercati mondiali e non solo in quello interno.
Non è questione di giusto o sbagliato, è nella natura delle cose che ciò avvenga. Ora, il punto è che, in questo caso, manca il concorrente europeo da tutelare; o meglio, non c'è nessuno che possa contrastare Microsoft sul suo terreno (se consideriamo Windows e Office), mentre potrebbero esistere piccole e medie software house che conquistano nicchie di mercato che potrebbero essere "spazzate via" da un nuovo add-in di Windows. Ma tale difesa appare debole se confrontata allo sforzo dispiegato per contrastare un colosso come è Microsoft. Apparentemente, quindi, non ci sono reali motivazioni politico-commerciali dietro a questa decisione. Perché quindi prendersela con Microsoft quando gli unici concorrenti che possono trarre vantaggio da questa decisione sono altre multinazionali americane?
In realtà su una cosa Microsoft è diversa da alcuni suoi competitor. Microsoft concentra quasi tutti i suoi team di sviluppo a Redmond. La presenza in Europa serve unicamente a dare servizi di assistenza e a creare la rete commerciale (sempre se pensiamo a Microsoft come software house, lasciando perdere le attività collaterali). L'unica presenza significativa al di fuori di questo è il centro Microsoft Research di Cambridge.
Da un punto di vista economico è naturale: è il modo più efficiente di fare le cose. Da un punto di vista politico, però, è una debolezza. Su scala più piccola (in Italia) conosciamo fin troppo bene quale leva politica possa essere una presenza industriale in una particolare zona economica del territorio. Rispetto all'Unione Europea, Microsoft non ha granché come merce di scambio (o come potere "ricattatorio", se preferite).
Per questo non mi sorprenderebbe un rifiuto dell'appello che Microsoft ha chiesto. Per questo non mi sorprende vedere tanti altri esempi di monopoli "di fatto", in tanti settori dell'IT, che non vengono nemmeno presi in considerazione dalle varie autorità antitrust.
Sicuramente, Microsoft dimostra ancora la sua giovane età (meno di 30 anni) come azienda multinazionale quando deve cimentarsi con la politica del Vecchio Continente. Vedremo quale sarà la lobby più forte. Se a Microsoft sarà concesso l'appello, Longhorn seppellirà comunque il problema di cui si discute ora. Se la sentenza diventerà esecutiva, non credo che porterà a dei cambiamenti pratici in tempi brevi. In ogni caso, sarà solo la fine di una battaglia, ma la storia da scrivere è ancora lunga.
Ian Griffiths ha scritto un'interessante disquisizione sull'uso di Monitor.TryEnter al posto di Monitor.Enter per individuare eventuali errori di deadlock. Per ovviare all'impossibilità di usare lock di C#, propone l'uso di una classe utilizzabile in maniera semplice con using. Da notare l'uso della compilazione condizionale del distruttore: l'idea è molto intelligente.
L'unica cosa che mi lascia un po' perplesso è il costo apparente di tutta questa architettura, rispetto alla chiamata diretta delle funzioni di Monitor. Però, come al solito, le prestazioni bisogna misurarle per dire quale è il vero costo. Probabilmente in moltissime situazioni il gioco vale la candela.
Brad Wilson ha appena inaugurato DotNetDevs, raccolta di articoli su .NET, e subito devo segnalare un articolo che non è altro che una raccolta di link, ma molto utili per chi vuole sviluppare con un utente non-admin.
In realtà tutti dovrebbero farlo. Quindi si tratta di una raccolta universalmente utile...
Probabilmente è il primo (sicuramente è l'unico che conosco) sito italiano dedicato ai TabletPC: www.tabletpc.it
C'è ancora poco traffico, ma d'altra parte la versione italiana del TabletPC deve ancora uscire (ma ormai dovrebbe mancare veramente poco). Mi sembra comoda la pagina che confronta i TabletPC sul mercato. Non so se è completa (ho perso di vista le ultime novità in fatto di Tablet) ma probabilmente rispecchia quello che c'è di disponibile sul mercato italiano.
Quale monitor potrà sfruttare adeguatamente le capacità di Longhorn? Al momento ci sono due scelte:
Le caratteristiche sono simili: 22 pollici, 16:10, 9 Megapixel, risoluzione nativa 3840x2400. Per chi non fosse abituato a questi numeri.... una fotocamera da 6 Megapixel stampa tranquillamente ingrandimenti fino a 50x30 senza che vediate troppo che si tratta di una fotocamera digitale; e qua abbiamo un monitor che ha una risoluzione maggiore. Altro parametro: una stampante laser come minimo stampa a 300dpi (anche se adesso ce ne sono che arrivano molto più in là); questi monitor superano già 200dpi, il che significa che alla distanza da cui guardate normalmente un monitor probabilmente non riuscireste a cogliere la differenza di tali dettagli.
Dimenticavo il prezzo... tra i 6.000 e i 7.000 US$. Tanto. Ma se arrivassero a costare tra i 2.000 e i 3.000 US$? Non dico che sarebbero monitor per tutte le tasche, ma c'è chi ha comprato a queste cifre dei 18" LCD da 1280x1024 qualche anno fa.
Due giorni fa ho letto velocemente questo post di Miguel de Icaza, ma ho voluto rileggerlo con calma prima di commentarlo. Premessa: ho conosciuto personalmente Miguel a PDC 2003 e devo dire che oltre a essere un genio e a essere simpatico, mi aveva dato l'idea che sottostimasse il lavoro necessario per raggiungere (nel mondo open-source) le funzionalità previste da Longhorn.
Il suo ragionamento oggi è invece pienamente condivisibile. Se è difficile pensare che un giorno Microsoft sparisca dalla scena del desktop, è anche difficile pensare che continui a mantenere la quasi totalità del mercato com'è oggi. Ovvio che in MS ci provano, ci mancherebbe. Ma la cosa più ragionevole è pensare che, così come non sparirà Windows, non spariranno nemmeno Linux e Macintosh. Ovvio che quello che conta sono le percentuali, ma nessuno ha la sfera di cristallo.
Il ragionamento di Miguel sull'impatto di Longhorn per gli sviluppatori è significativo (le API in .NET renderanno "inutili" dei wrapper di compatibilità), così come il disincanto con cui (anche lui) liquida la possibilità di "write once run everywhere" - magari funziona, ma poi si vede che i programmi sono un po' "diversi" dallo standard di piattaforma su cui sono eseguiti.
Ma il suggerimento che dà a Sun è molto interessante: creare una versione di Java che compili in IL anziché in Java Byte Code. Da un punto di vista puramente razionale, sarebbe la cosa giusta da fare (per Sun). Però ogni tanto certe decisioni sono prese senza la necessaria razionalità. Notare che se Sun facesse cadere le "barriere" che detiene su Java (rendendolo uno standard ISO, per esempio), ciò sarebbe tecnicamente possibile anche per delle terze parti. E J# è lì a dimostrare che l'implementazione tecnica non è un problema.
Ne riparleremo tra qualche anno...
Oggi abbiamo avuto conferma delle date per la DevLeap Conference e abbiamo dovuto posticipare di un giorno l'evento di Napoli.
Dunque le date ufficiali dovrebbero essere:
- Bologna: martedì 11 e mercoledì 12 maggio 2004
- Napoli: martedì 22 e mercoledì 23 giugno 2004
Originariamente avevamo pensato di fare l'evento a Napoli di lunedì e martedì, dando così modo a chi lo volesse di avere una buona scusa per farsi un giro in costiera amalfitana agganciando il week-end. Non è che la cosa non sia ancora fattibile, ma la scusa per stare lì il lunedì a questo punto dovete trovarla voi...
Tra poco (giorni, forse ore) comunicheremo il link al sito ufficiale della conferenza che stiamo finendo di preparare.
Normalmente riservo questo genere di segnalazioni al week-end, ma mi tocca fare un'eccezione. Non ce l'ho fatta a resistere.
Junfeng Zhang segnala il sito del libro Dating Design Patterns. Difficile a dirsi perché l'umorismo sia ritenuto più irresistibile quando solo in pochi riescono a capirlo. E i prerequisiti per capire l'umorismo di questo libro non sono bassi(il libro che vedete sulla sx, Design Patterns, è indispensabile - ed è serissimo, ovviamente). Per 20$ direi che al primo ordine che faccio su Amazon è imperdibile...
La scorsa settimana ho ricevuto una segnalazione su dei problemi di OutputDebugString in un programma multi-thread. Sembra che ci sia un bug (come riportato anche su questa pagina da uno sviluppatore indipendente, tra l'altro contiene molte altre informazioni interessanti) per cui almeno fino a Windows 2000 tale funzione non è rientrante e se chiamata contemporaneamente da più thread può dare dei problemi; sembra che da Windows XP in poi il problema sia stato risolto.
Brutto usare il condizionale, ma purtroppo non c'è traccia di questo problema dalle fonti ufficiali e soprattutto la documentazione non riporta nessuna segnalazione rispetto alla thread-safety di tale funzione. Ora, purtroppo in questi giorni ho altro da fare... perché altrimenti sarei curioso di vedere se le rispettive funzioni .NET sono thread-safe: in particolare la System.Diagnostics.Debug usata col DefaultTraceListener, perché è dichiarata thread-safe (questa sì) nella documentazione di MSDN, ma guardando il codice di SafeNativeMethods sembra proprio che la necessaria CriticalSection per garantire la correttezza della chiamata di OutputDebugString non ci sia per nulla... (però questo è il codice di Rotor, quello nativo di .NET potrebbe essere diverso).
Prima o poi indagherò sulla cosa... Se qualcuno avesse tempo di fare delle prove comparative su Windows 2000 e Windows XP mi scriva, sono proprio curioso.
Ho appena letto velocemente un documento su MSDN relativo a Binary Delta Compression. Che dire... fa piacere sapere che dal 1998 questa tecnologia è presente in tutti i Servce Pack installati con la tecnica "Express Installation", e che dal 2003 è usata anche con gli aggiornamenti dati da Windows Update (anche se, davvero, non sembrerebbe...). Ma allora perché non documentarne anche le funzionalità in modo che lo si renda fruibile per le proprie applicazioni?
Probabilmente (o sperabilmente) questo documento è un primo passo in questa direzione. Vedremo.
More Posts
Next page »