Claudio Brotto

wowwwwwwwwwwwww

Si fa fatica oramai a trovare qualcosa da dire ......

Le immagini hanno parlato da sole, ancora una volta.

Beh, ancora non avete capito a cosa mi riferisco ?

Ma come ?

A quel fenomeno che risponde al nome di Valentino Rossi !!

Stavolta mi è toccato guadare il gran premio su Mediaset, perchè ero da un amico che non aveva il collegamento satellitare.

Preferisco la telecronaca di Eurosport con Ungaro e Lucchinelli (ma quante ne sai, Marco, ma quante ne sai ...), ma non è tanto per questo che critico Italia1.

Quello che proprio mi sta qui sono quei 92 secondi cronometrati, datemi quei due o tre decimi di tolleranza :-), di pubblicità continuativa. In pratica quasi un giro, ad Assen. Capisco gli sponsor, tutto quello che volete, ma non è un po' tantino ?

Il sorpasso finale, però, ce lo hanno fatto vedere tutto !!!!!

E chi se lo scorda ....

46 .......

Auguri Papà

Questa volta uso il mio blog per uno scopo molto personale e poco tecnico.

Oggi è il compleanno del mio papà.

Compie ....

Beh, non si dice mica ! :-))))

Visto che gli impegni di lavoro mi impediranno con ogni probabililtà di andarlo a trovare a Savona, e visto che sono 20 minuti che il telefono è occupato, approfitto dei potenti mezzi di comunicazione moderni.

Quindi ....

TANTI AUGURI A TE

TANTI AUGURI A TE

TANTI AUGURI PA PA AAAA

TANTI AUGURI A TEEEEE

ERRATA CORRIGE e 1 piccola riflessione

Buongiorno e buona domenica a tutti !

Innanzitutto, una nota importante. Un' ERRATA CORRIGE.

Nel mio precedente post mi sono lanciato in voli pindarici commentando la differenza tra l'uso di for e while per le iterazioni.

Interessante .... peccato fosse sbagliato !!!!

Marco Russo, che ringrazio ancora una volta per la prontezza della segnalazione e, già che sono qui, anche per i commenti ad alcuni dei miei post precedenti, mi ha fatto notare che (cito testualmente dalla sua mail):

for vs. while

Ieri, durante uno scambio di pareri via Messenger con un amico programmatore, il discorso è caduto sulla scelta della sintassi da utilizzare per le iterazioni.

In realtà è partito tutto da un costrutto che chissà quante volte abbiamo scritto: un ciclo infinito.

Il punto non è comunque questo.

Parlando di cicli infiniti, infatti, è iniziata una discussione su quale espressione sintattica sia da preferirsi. Entrambi programmiamo in C#, ma (almeno dal punto di vista della sintassi) lo stesso discorso vale anche per C e Java, e in modo analogo per gli altri linguaggi che, seppur con keyword differenti, esprimono lo stesso concetto.

Il mio amico sosteneva che scrivere:

for (;;) { /* ... */ }

fosse più espressivo che

while (true) { /* ... */ }

mentre io sostenevo il contrario.

Rimane, è chiaro, una questione esclusivamente soggettiva. Di abitudine, magari, ma comunque soggettiva. I sostenitori del for possono dire: "Mi sa più di forever, per sempre", i sostenitori del while possono dire: "Mi dà l'idea di finchè nessuno mi interrompe".

Ma si parla sempre di preferenze personali: alla fine, lo sappiamo, i linguaggi di programmazione "ad alto livello" cercano di mappare le istruzioni più vicine alla macchina in qualcosa che la mente umana comprende con più facilità. E magari la mente di qualcuno ha più immediatezza a leggere un espressione rispetto a quella di un altro, e viceversa.

Quindi, allargando l'orizzonte, utilizzare for o while per un ciclo è la stessa cosa ?

Beh, qualche premessina è d'obbligo. (Ok, sarà il consueto post un po' lungo, forza e coraggio).

Punto primo. Mentre quello che ho scritto prima vale per ogni linguaggio di programmazione, d'ora in poi parlo di C# e .NET.

Punto secondo. Visto che qui ci si mette di mezzo il compilatore, sarà scontato dirlo, ma ho usato csc.exe. E una macchina Pentium.

Punto terzo. Leggetelo alla fine, è scritto in fondo al post.

Ok, cominciamo.

Ho scritto questo utilissimo programmino (sono due, in effetti, uno per tipo di ciclo). Nonostante la possibilità di ricavare dei soldi dalla sua vendita :-), vi scrivo il sorgente, fatto da ben, e dico ben, 1 o 2 righe (a parte la dichiarazione della classe e compagnia bella, il tutto sta dentro il Main):

Versione for:

for (i = 0; i < 1000000000; i++);

Versione while:

Int32 i = 0;

while (i++ < 1000000000);

Compilato il tutto, il mio test verte ora su due aspetti:

• Valutare quali differenze ci sono a livello di IL (e questo dipende ovviamente da cosa fa il compilatore)
• Valutare le prestazioni (velocità di esecuzione)

E i risultati sono i seguenti. Spero che conosciate un po' di IL, che comunuque qui è presente proprio con due o tre istruzioni, comunque il codice generato da csc è questo (è il codice del metodo Main, privato di signature e STAThreadAttribute). Sotto ci ho messo due righe di spiegazione, che ovviamente chi mastica quel minimo di IL può allegramente saltare (anzi no, magari un'occhiata conviene che ce la dia lo stesso perchè non vorrei aver scritto cavolate !).

Versione for:

  .maxstack  2
  .locals init ([0] int32 i)
  IL_0000:  ldc.i4.0
  IL_0001:  stloc.0
  IL_0002:  br.s       IL_0008
  IL_0004:  ldloc.0
  IL_0005:  ldc.i4.1
  IL_0006:  add
  IL_0007:  stloc.0
  IL_0008:  ldloc.0
  IL_0009:  ldc.i4     0x3b9aca00
  IL_000e:  blt.s      IL_0004
  IL_0010:  ret

... che in parole vuol dire:

1. Carico il valore costante 0 nella variabile locale di indice 0. (da IL_0000 a IL_0002). Skippo alla label IL_0008, che quindi qua segue nella descrizione.
2. Carico sull'evaluation stack il valore della variabile locale di indice 0 (che in partenza era 0).
3. Carico sullo stack il valore 0x..., cioè 1 miliardo.
4. Se il valore caricato sullo stack, che è quello contenuto nella mia variabile locale, è < di 1000000000, goto IL_0004, che viene prima ma qui segue.
5. Le istruzioni dalla IL_0004 alla IL_0007 non fanno altro che incrementare il valore della variabile locale: se la caricano sullo stack, si caricano anche la costante 1, li aggiungono e il risultato viene prelevato dallo stack e salvato nella variabile locale stessa.
6. Tutto questo, ovviamente, finchè il contatore locale, la nostra variabile, cioè, non raggiunge il ragguardevole valore di 1000000000. A quel punto il metodo esce (lo può fare senza andare incontro ad eccezioni a runtime, lo stack infatti è vuoto).

Versione while:

  .maxstack  3
  .locals init ([0] int32 i)
  IL_0000:  ldc.i4.0
  IL_0001:  stloc.0
  IL_0002:  br.s       IL_0004
  IL_0004:  ldloc.0
  IL_0005:  dup
  IL_0006:  ldc.i4.1
  IL_0007:  add
  IL_0008:  stloc.0
  IL_0009:  ldc.i4     0x3b9aca00
  IL_000e:  blt.s      IL_0004
  IL_0010:  ret

... che in parole vuol dire:

1. Carico il valore costante 0 nella variabile locale di indice 0. (da IL_0000 a IL_0002).
2. Carico sull'evaluation stack il valore della variabile locale di indice 0 (che in partenza era 0)
3. Duplico il valore al top dello stack. Ora alla cima dello stack ci sono due valori uguali, che in partenza sono entrambi 0.
4. Carico il valore costante 1 sullo stack. Lo stack ora ha 3 elementi.
5. Eseguo l'operazione add, che prende i due valori al top dello stack e li sostituisce con la somma. Ora lo stack ha 2 elementi.
6. Salvo il valore al top dello stack nella variabile locale di indice 0. Ora lo stack ha un elemento.
7. Carico la costante 0x...., cioè un miliardo, sullo stack. Ora lo stack ha 2 elementi: alla cima c'è un miliardo, sotto c'è quello che avevo caricato al punto 2, che per la prima interazione è 0.
8. Confronto l'un miliardo con quel valore. Lo stack è alla fine vuoto, e se il valore è < 1000000000, torno al punto 2, ma prima leggetevi il punto 9.
9. Quando torno su, nella variabile locale di indice 0 c'è il suo valore precedente aumentato di 1. Quindi ripeto il tutto per 1000000000 di volte finchè la condizione al punto 8 non è false. Lo stack a quel punto, come visto, è vuoto e il metodo non fa altro che uscire (ret)

Che palle, direte voi !

Ma c'è bisogno di tutta sta sbrodolata di commenti ?

Alla fine cos'è che cambia ?

Beh, innanzitutto cambia il codice generato. Che magari non gliene frega niente a nessuno, ma credo sia una cosa interessante per farsi un po' di ossa con IL.

Poi cambiano le prestazioni.

Ho eseguito questi due metodi per 100 volte ciascuno, e la media, devo dire abbastanza precisa perchè la distribuzione è molto concentrata, è abbastanza diversa.

Sulla mia macchina, ho ottenuto quanto segue:

for: 661 ticks avg

while: 858 ticks avg

Quindi una differenza ... rilevabile.

Che poi non vi sia mai capitato di eseguire un ciclo per 1 miliardo di volte, non lo metto in dubbio.

Che i cicli (in genere !!!) non siano vuoti, anche questo è vero.

Che le differenze siano assorbite dall'implementazione all'interno del ciclo, vero anche qui.

Che i miei test siano poco accurati, beh, ok, lo ammetto. Ho usato metodi molto rudimentali (Environment.TickCount), niente profiler, niente perfcounters, non ho seguito le raccomandazioni per i test (leggetevi Maximizing .NET Performance). Ma credo che abbiano rilevanza lo stesso.

Non mi interessa dire, a questo punto, "il for è meglio del while", "usate for", o cose del genere. Probabilmente, in casi comuni in cui le iterazioni sono meno e il peso dell'algoritmo sta nei conti interni al ciclo, le differenze sono realmente trascurabili.

Quindi sì, usate quello che volete perchè niente è meglio che un programmatore che si riconosce nella sintassi che ha usato.

Però quello stesso programmatore deve sapere che, almeno in questo caso, non è una pura questione sintattica.

Siamo quasi alla fine !!! Evviva, ce l'avete fatta anche questa volta.

Mi rimane solo il punto 3, che vi avevo detto avrei discusso alla fine.

Quindi ciao, arrivederci alla prossima e leggete il punto 3 qua sotto.

Punto 3.

Mi sarebbe piaciuto fare considerazioni sull'output finale dell'esecuzione, cioè sul codice x86 generato dal Jitter. Alla fine il codice IL è differente, lo è sicuramente anche quello x86 (se no, dato che non contano in questo caso tempi di compilazione del metodo perchè questo avviene prima dell'esecuzione dei conti, non ci sarebbero ste differenze). Ma, nota dolente, non ci capisco una beneamata di assembler (a parte quelle due cosette tipo mov, inc, pop ... mi fermo qui, capite bene che è un po' poco !).

Quindi, se qualche lettore molto volenteroso ha voglia di esaminare l'x86 generato, e capisce le differenze, sarei curioso di sapere qualcosa.

Scrivetemi !

Grazie e a ri ciao !

UPDATE: Ah, dimenticavo. Le sintassi while e for per un ciclo infinito (che poi non è altro che un ciclo senza statement di controllo) producono proprio esattamente lo stesso IL. Ma proprio lo stesso, non cambia una virgola. Quindi lì sì che è una questione di gusti e solo di quelli ....

HINSTANCE e HMODULE

Questa volta un post breve, una semplice segnalazione.

In questo post, Raymond Chen spiega la differenza tra HINSTANCE e HMODULE.

Credevo fosse solo una delle varie duplicazioni di nomi nella API Win32. In effetti rappresentano, almeno nel mondo preemptive di Windows post 3.1, la stessa cosa.

Raymond, però, spiega chiaramente perchè non sono ESATTAMENTE la stessa cosa, anche se alla fine ora come ora coincidono.

Andatevelo a leggere, che ne vale la pena.

senza parole

La descrizione della gara andatevela a leggere sul sito della gazzetta o su rossifumi.it.

Non ce la faccio neanche a stare in piedi.

Bravo Sete, molto bravo.

Bravissimo Marco (Melandri). Primo podio, non sarà l'ultimo.

Ma di extraterrestri ce n'è uno solo.

E' lui.

E' Vale.

Alè Vale

Tecnologia e Moda

Oggi mi sono svegliato presto, ma talmente presto, ma proprio talmente tanto presto ... che finalmente riesco a trovare il tempo di scrivere un bel post chilometrico.

Vi metto alla prova, cari lettori, per vedere se anche questa volta riuscite a resistere alla tentazione di saltare oltre e continuate a leggere sino al punto finale. Se avete seguito almeno un po' il mio neonato blog, sapete chi è Pino. Per chi non lo sa, una breve presentazione.

Pino è un personaggio che non esiste, neanche nel mondo dell'invenzione. Pino è la rappresentazione dei guai, degli sbagli, dei problemi e delle assurdità che gravitano intorno al programmatore moderno. A volte commette errori per inesperienza e superficialità, altre li subisce per mancanza di polso e di ruolo.

A volte Pino è un navigato programmatore, talmente legato alle abitudini da non riuscire a vedere le cose da angoli differenti.

Altre è un giovane, entusiasta e ancora troppo inesperto per capire che non sempre, anzi quasi mai, le scelte vengono fatte per ragioni tecniche. L'ignoto non lo spaventa, anzi lo stimola ad imparare. L'aggiornamento continuo è il succo delle sue capacità. Come in questo caso. Leggete ...

"Pino, stopomeriggio riunione con quelli di là. C'è da risolvere quella questione di ieri."

La questione, per inciso, riguardava l'architettura di alcuni componenti del middle-tier.

Il prodotto, ormai in produzione da alcuni anni, aveva sofferto di una progettazione carente, ed alcune problematiche stavano venendo a galla alle prime necessità di scalare. E di cosa ci si stupisce ? Non è che ci voglia tanto ad implementare un application server che soddisfa 100 richieste all'ora. La scelta di una tecnologia rispetto ad un altra non mostra quasi mai i propri limiti in situazioni di basso carico. I problemi, quindi, sorgono di solito ben dopo il rilascio dell'applicativo, quando il cliente inizia ad accorgersi (noi non abbiamo mica fatto stress test, figuriamoci) che le cose funzionano un po' lentine.

Insomma, il software che era stato sviluppato non reggeva. Non era lento, magari fosse stato solo lento, ma proprio non reggeva. Macchina in hang e via dicendo.

Pino era entrato nel progetto da alcuni mesi, e a dire la verità stava seguendo altri aspetti (customizzazione di interfacce grafiche, quelle sì che sono fondamentali !). Ma le riunioni coinvolgevano tutti. E quindi coinvolgevano anche Pino.

Il commerciale, seduto in fondo al tavolo, presentò in breve le problematiche sollevate dal cliente. E chiese lumi.

Il PM, che già conosceva la questione, era visibilmente preoccupato, e a ragione. L'architettura, così com'era, non poteva essere espansa. andava riprogettata. E non era cosa da due settimane, potete ben immaginare.

Fatto sta che andava fatto. E iniziò ad esporre le problematiche sollevate da un punto di vista più tecnico. Insomma, era chiaro, e tutti se ne rendevano conto: rasare via, ricostruire, ritestare, sostituire, e incrociamo le dita.

Ma come farlo ? In quanto tempo ? Per l'application server attualmente in produzione erano stati impiegati 4 anni uomo tra analisi, sviluppo e test. Il cliente, giustamente, premeva, e il budget (quindi il tempo) a disposizione era a dir tanto di 6 mesi uomo. E visto che 6 mesi uomo non vuol dire 1 mese con 6 uomini, si ipotizzò un periodo di 3 mesi, con 3 persone dedicate a tempo pieno. 3 x 3 fa nove, ma dentro c'erano imprevisti e così via. Si andava in perdita, ma si manteneva il cliente.

Impossibile stare nei tempi.

Lo so che ve lo state chiedendo, e vi rispondo subito. Il middle tier era un aggregato mostruoso di componenti COM. Sviluppati in C++ con ATL, e piuttosto complessi.

Pino non lavorava ancora lì, ma gli avevano raccontato, con un senso di soddisfazione per aver domato un mostro a 12 teste, che dopo settimane di nebbia erano riusciti a capire e implementare un'infrastruttura DCOM a prova di bomba. "A prova di bomba mica tanto", pensava Pino fra sè e sè, "dato che al primo minimo aumento di carico stava andando tutto a catafascio". Tienitele per te queste considerazioni, caro il mio Pino, che sei l'ultimo arrivato. E così fece.

Fatto sta che questa roba si doveva ristrutturare, e pesantemente anche.

Iniziarono le prime proposte.

E, potete bene immaginarvelo, una parola su due era "COM", "DCOM", "COM", "DCOM", "COM", "Componente COM" (giusto per variare un po' sul tema). I più all'avanguardia iniziavano a snocciolare le direttive dell' architettura DNA, tanto che tra un "COM" e l'altro entrò pallidamente anche qualche "MTS" e, guarda un po', un "COM+" buttato lì quasi per caso.

Pino seguiva con attenzione. "Caspita come siamo avanti !".

Ah, tra parentesi, è il 2004, cioè oggi. "Chissà se sanno che qualche hanno fa hanno rilasciato quella strana roba che risponde al nome di .NET ?", si chiedeva Pino.

E mentre qualche collega dalla pluriennale esperienza illustrava con aria da Dio in terra le potenzialità di COM per un'architettura veramente distribuita e scalabile, i pensieri di Pino iniziavano a vagare.

"In base alle ultime esperienze con DCOM", sentiva in sottofondo, "e grazie al modello ADO, possiamo implementare un data access layer bla bla bla ...", e intanto Pino pensava ad ADO.NET.

"... che parla tramite protocollo RPC con un singleton contenuto nel middle tier bla bla bla ....", e intanto Pino pensava a Remoting.

"Inoltre, data l'esperienza massacrante con MFC, un'infrastruttura COM ci permette di sviluppare interfacce grafiche con Visual Basic, così parallelizziamo il lavoro perche quelli di là ....", e intanto Pino pensava a WindowsForms.

"Direi inoltre che conviene rinunicare alla funzionalità di MSMQ, perchè sono scomode da implentare e in fin dei conti ne possiamo anche fare a meno ....", e intanto Pino pensava a quella volta che, dopo aver letto un articolo sul sito dell'MSDN, aveva fatto una provetta con MSMQ.NET, e in un'ora era riuscito a completare un sistema di messaggistica essenziale ma carino.

"E' chiaro che le risorse a disposizione sono troppo poche per un progetto di questa complessità. Serviranno due esperti di questo, due di quest'altro, tre di quest'altro ancora, tutti con una solida conoscenza di COM e programmazione multithreading, poi due o tre sviluppatori per le interfacce grafiche, il gruppo di test ...."

Pino era meditabondo. Alla fine era lì in riunione senza la possibilità, o la convenienza, mettetela come volete, di dire la sua e proporre qualcosa di ... migliore. Gli sembrava che nessuno avessa tenuto in conto l'idea di utilizzare altre tecnologie che non quelle, per così, dire, vecchie e consolidate. Che ci fossero ragioni di competenze non lo metteva in dubbio, e anche i tempi stretti facevano la loro parte. Ma almeno pensarci si poteva, o no ?

Insomma, gli sembrava che più che una ristrutturazione fosse un reimpasto, un'occasione per spostare due componenti da una parte all'altra e nel mentre correggere qualche baco vagante e mai ben identificato. E chiamala ristrutturazione, quella.

Così dalla bocca di Pino uscirono, a sua insaputa e nel bel mezzo di un discorso del PM, tre parole lapidarie: "Perchè non .NET ?".

Pino ebbe appena il tempo di accorgersi di aver fatto la sua cavolata quotidiana che il PM smise di parlare, ei girò verso di lui e lo fulminò con uno sguardo. Tutti zitti. Non si sapeva se aspettavano che Pino continuasse un discorso che in realtà non avrebbe voluto iniziare, o che il PM gli tirasse un posacenere dritto fra gli occhi.

In realtà non successe nè l'una nè l'altra cosa. Prese, invece, parola un altro programmatore "anziano", il guru del C. Chiamiamolo Guru (nome proprio) per capirci.

Insomma, Guru interruppe sia Pino (e Pino tirò un sospiro di sollievo) che il PM (chiamiamolo PM, nome proprio) e disse:

"Qua se non siamo alla moda non siamo contenti, vero ?"

Silenzio.

"A me già sto COM non convince, si poteva fare un bel socket server che si faceva prima. Comunque va bene, e COM sia. Ma .NET, eh no, non diciamo assurdità !".

Silenzio.

Alcuni avevano la faccia di chi non capiva una mazza e pensava che .NET fosse solo un dominio di primo livello.

Altri erano chiaramente d'accordo con Guru e scuotevano la testa guardando il povero Pino, diventato ormai microscopicamente stretto nelle sue spallucce.

".NET fa schifo, è una moda passeggera. Cos'ha in più ? Moda, solo una moda. O un modo di vendere qualcosa di cui non c'è bisogno".

Qualche rumorino, qualche brusio. Facce consenzienti, sguardi di fuoco per il povero Pino, che stava lentamente sparendo sotto il tavolo.

"Qui se non siamo alla moda non siamo contenti, non è vero ? Andiamo sempre a cercare le soluzioni all'ultimo grido, così ci possiamo riempire la bocca con i paroloni. Web Services, ma che roba è ?! Figurati se li userà mai qualcuno. .NET Framework, ma che bel nome ! Ma va là, non perdiamo tempo con ste s*******e, che qui si deve lavorare, mica giocare."

Ci mancava che partisse un applauso e Pino si sarebbe ridotto a dimensioni molecolari.

Invece ci si mise anche il commerciale, che non conosceva la differenza tra una stringa C e una stringa delle scarpe, ma al sentir dire che bisogna lavorare, e non giocare, colse la palla al balzo.

"Ha ragione Guru, dannazione. Mettiamoci in testa che sta roba la dobbiamo vendere e far funzionare, mica ci dobbiamo fare i fiocchettini e firmarla D&G !"

"Poi tu cosa parli, Pino, che tanto più che i test non potrai fare ?"

Allora Pino, praticamente in catalessi, si lasciò scappare la seconda infelice uscita della riunione: "Ma magari si riescono anche a ridurre i tempi ..."

Guru non lo lasciò finire.

"Ma tu sei abelinato veramente !" (nda: abelinato è genovese, significa scemo, idiota, cretino, imbecille, stupido, giusto per rimanere in un ambito relativamente poco volgare).

"Ma se abbiamo migliaia di righe di codice da copiare, e funzionano ! In due giorni facciamo un componente che ascolta su una porta TCP e risponde, ci manca solo il protocollo, ma tutto il plumbing è già fatto. Te lo incolli nel codice, e hai fatto. Ma a te ti paga la Microsoft per dire ste cose ? Non mi vorrai mica dire che ci si mette di meno, dai. Eh, ragazzo mio ....", concluse Guru, dall'alto della sua pluriennale esperienza di programmatore in C, " ... ne hai ancora di cose da imparare."

Vero.

Ne aveva di cose da imparare, il nostro sconsolato giovane programmatore.

Primo. Che le scelte spesso non si basano su considerazioni tecniche, ma solo su questioni di opportunità: competenze del team di lavoro, riciclo di roba esistente, tempi, tempi e soprattutto tempi.

Secondo. Che cambiare e imparare qualcosa di nuovo piace a chi è entusiasta del proprio lavoro, ma è un incubo da ricacciare indietro per chi del proprio lavoro ha fatto routine.

Terzo. Che le tecnologie più recenti sono, prima di tutto, una moda. Non importa se poi l'abito è comodo, resistente, elegante, duraturo. Se è di moda è negativo. Perchè noi siamo programmatori, e la moda non la seguiamo mica.

Quarto, ed ultimo. Che prima di parlare ci si deve pensare dieci volte. Perchè le prime nove si valutano le conseguenze della propria frase come se l'avessimo ascoltata noi, e solo la decima ci si rende conto che la cosa più sacrosanta del mondo può essere confutata (a torto, ovviamente), e che chi ci critica può avere l'appoggio di tutti, anche di chi decide.

Triste, ma vero.

Ghessemmu

Ghessemmu.

Cioè .. ci siamo, in dialetto. Non so se si scrive proprio così, ma pronunciatelo come lo leggete, con forte accento genovese.

Cinque giorni di assenza dal blog. Sgrunt ! 

E un po' di novità. Andiamo con ordine.

Ho un nuovo portatile sotto le dita proprio in questo momento. Ho cercato un compromesso tra le prestazioni e ... beh, lo sapete, il prezzo !

I Dell sono ancora un po' troppo cari per le mie tasche, almeno i Dell che mi interessano (ho visto un 9100 stramegagalattico, ma superava di un pezzo i 2000 euro ... la qualità costa, c'è poco da dire).

Così ho optato per un Amilo D 8140.

Caratteristiche seguenti: P4 3.06 Ghz HT (e finalmente !), 1 Gb DDR, ATI Radeon Mobility 9600 128 MB, HD 40 Gb, widescreen, WI-FI (e finalmente 2 !), DVD+R/RW e per il resto le solite cose.

Fondamentalmente la scelta è dovuta alla RAM e al processore hyper-threading. L'Acer Aspire che avevo prima, per di più, non aveva la scheda wireless lan e aveva la scheda video integrata. Insomma, tante belle cosette in più!

Lo sto usando da un paio di giorni, e inizio ad apprezzare pregi e difetti.

Pregi: è veloce, almeno rispetto a come ero abituato. Virtual PC va che è un piacere e sono riuscito a creare un mini dominio con un Server 2003 (384 MB RAM), un client XP (192) e un client 2000 (128), giusto per fare due prove. La mia su VirtualPC ve la dirò alla prossima occasione, ma intanto, per chi ogni tanto si compra qualche giornale, sull'ultimo PC Professionale c'è una articolo di comparazione tra VPC e VmWare Workstation. La mia scelta per ora era ricaduta sul primo, vuoi per una maggiore leggerezza, vuoi perchè Longhorn su VmWare non ero riuscito a installarlo. Ma ora è uscito VmWare 4.5, con supporto (Experimental, ovviamente, e ci mancherebbe ancora) a Longhorn. Sembra andare (provare per credere). Quindi mi riservo la possibilità di modificare le mie preferenze ....

Difetti: il disco, un po' piccolino. E un alimentatore che pesa quasi più del portatile.

Incertezze: lo schermo. Non è per niente male, sia chiaro, ma sto facendo un po' fatica ad abituarmi alle dimensioni inusuali. Sto usando 1280x800, che è la massima risoluzione supportata, ed è sicuramente valido. Ma faccio ancora un po' fatica.

Complessivamente, sono contento della scelta.

Mi ha incuriosito l'atteggiamento del rivenditore. Dopo avermi chiesto che uso ne avrei fatto, più o meno mi ha detto: "Ma cosa se ne fa di 1 GB di RAM ? Mica ci gioca ?!".

Ora, che le super prestazioni i giochi di ultima generazione le richiedano, non c'è ombra di dubbio. Probabilmente sono le applicazioni che ne traggono maggior beneficio. Ma non sono le uniche, perbaccolina. Non mi direte che riuscite a far girare due macchine virtuali (più il sistema host) con mezzo giga di ram e senza decadimenti ?! Magari ce la si fa anche, però dai, non ditemi a questo punto che la ram serve solo per i giochi.

Discorso simile, anche se ancora un po' prematuro, per la scheda grafica. Sfruttata ora principalmente dai giochi o da applicazioni di disegno evolute. Però si sa che con Longhorn la musica sta per cambiare. Eccome !

Longhorn ??!?!!! Ma prima che esca !

Vabbè, dai, lasciatemi il divertimento di giocare con ALT-TAB e stupire i colleghi con effetti speciali.

A parte gli scherzi, pensavo a quello che (almeno così si vocifera) hanno detto sui system requirements di Longhorn. Giga e Giga di RAM, Gigahertz e Gigahertz di CPU, schede video che da sole ciucciano tutta la potenza di un alimentatore di oggi ... fantascienza !

Già. Fantascienza oggi, però fra 3 anni saranno le caratteristiche di un comune pc domestico. E se vogliamo anticipare il futuro e giocare con le beta (quando arriveranno !) dobbiamo premunirci.

Figliuoli carissimi, ora me ne vado a fare la ninna che domani si lavora.

Sino alle 13 e 50, quando non deve volare una mosca.

Ci sono 46 ottime ragioni per prendersi una pausa domani a quell'ora. Ma non ve le elenco perchè mi sembra che il numero parli da sè.

E forza Vale, naturalmente !

Peccato

Ho aspettato fino all'ultimo minuto, in attesa di un miracolo che alla fine non si è avverato.

Niente da fare: ho dovuto annullare la registrazione per la conferenza di L'Aquila.

Motivi: scadenza e distanza. Che poi sono legati. Purtroppo da Genova a L'Aquila sono 600 Kilometri, e a meno di non viaggiare di notte questo comporta due giorni per i trasferimenti ed uno per la conferenza. E tre giorni, accidentaccio, in questo momento sono oro.

Spero che si siano occasioni simili in futuro, magari un pochetto più vicine.

Mi spiace di avere tenuto occupato un posto sino all'ultimo. Quindi se avete provato a registrarvi e non avete trovato spazio, beh ... FATELO ORA ! Mi raccomando.

E per quel che mi riguarda, alla prossima !

senza parole

46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46  (contateli ....)

46

In un post di qualche giorno fa, Marco Russo parlava del significato del numero 42.

Beh, parlando di numeri non si può non citare il 46.

Niente a che fare con l'informatica, ma tanto a che fare con la storia.

Forza Valeeeeeeeeee !

XAML XAML XAML

Mi sono imbattuto solo ora in questo post di Chris Sells.

Credevo che, ad oggi, Xamlon fosse l'unico framework disponibile per sviluppare con WindowsForms applicazioni grafiche in modo dichiarativo ... e invece no, guardate qui e qui.

Sull'utilità di utilizzare oggi queste soluzioni c'è da discutere.

In assenza di editor grafici per XAML (se non vado errato anche in Whidbey non l'hanno ancora reso disponibile) gli strumenti consueti rimangono secondo me la via preferenziale. Ripeto: oggi, per lo meno. E per inciso anche domani (beh, dai, facciamo dopodomani !) con Longhorn nessuno vieta di descrivere il layout delle interfacce da codice, un po' come si fa ora con WindowsForms.

Quindi, almeno per la maggioranza del codice di produzione, questi sono progetti ben poco (se non per niente) utilizzati.

Credo che l'interesse stia, invece, nell'aver modo di sperimentare un altro approccio alla programmazione di interfacce utente. Concetti come code-behind, se sono necessariamente stranoti ai programmatori ASP.NET, sono spesso sconosciuti ai programmatori WinForms, che bene o male se li ritroveranno a valanga in un prossimo futuro.

Perchè i vantaggi di un approccio dichiarativo ci sono, eccome.

Primo fra tutti, secondo me, la possibilità di delegare il disegno delle interfacce a chi fa il grafico di professione.

Pensate all'ultimo colloquio che avete fatto (parlo ai programmatori !): magari vi hanno chiesto vita morte e miracoli di COM o di VB, cose che forse nemmeno in Microsoft sanno di avere scritto ... però non vi hanno chiesto cosa sono textures o alpha blending (se vi hanno chiesto anche quello, cavolo, ma dove siete andati a finire ?!)

Insomma, gli sviluppatori sono (dovrebbero essere, almeno) bravi a progettare e implementare applicazioni, fare i designer non è il loro lavoro primario, e non è garantito che lo sappiano fare ad un livello, quanto meno, decente.

E' chiaro che disegnare il layout di un form non è proprio la stessa cosa che disegnare una teiera 3d con Autocad, però, diciamocelo, che invidia per quei grafici che con due tocchi di mouse ti delineano una forma che tu avresti messo ore a disegnare, e con effetti infinitamente migliori dei tuoi !

IL IDE

Solo un link della buonanotte.

Ci sono prodotti più validi e molto più completi, però questo è free (se usate Kazaa non conta come free !).

A quando un IL editor integrato in Visual Studio ?

Mi sembra che anche in Whidbey non se ne sia parlato. Se mi sbaglio (e vorrei sbagliarmi) fatemi sapere !

Tecnici e commerciali 2

Ho appena scritto il solito post chilometrico.

Aggiungo qui due note prima che mi arrivino mail di protesta di commerciali incavolati.

Esistono commerciali in gamba e corretti nel proprio lavoro, così come tecnici poco validi. Come sempre non esiste una verità assoluta nelle cose.

Però quello che la storiella di Pino vuole comunicare e che certe situazioni ESISTONO. Garantisco io per Pino. E a volte queste situazioni portano veramente qualche valido programmatore a rassegnare le dimissioni perchè si trova di fronte ad un muro.

E non è giusto, proprio per niente.