2005: i buoni propositi

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…



  1. 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
    ).
  2. 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.
  3. 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…
  4. Scrivere altri due articoli su Win32 e completare la serie (al momento c’è
    solo il
    primo
    ). Questa è una promessa difficile da
    mantenere…
  5. Decidere cosa comprare tra Qtek 9090, Motorola MPx e I-Mate SP3.

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

Fugue Protocol Checker

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.

Microsoft come IBM?

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…

Bilancio 2004

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.

Google Desktop vs. MSN Dekstop Search

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

Bug, segnalatori e conoscenze: tutto il mondo è paese

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?

MSN Toolbar/Deskbar: è proprio una beta, ma promette bene

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.

Meglio un Qtek oggi o un MPx domani?

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 240×320 (perché negare un bel 480×640?).

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.

Anche i blogger sbagliano!

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