aprile 2005 - Posts
Oggi ho dovuto metter mano ad un applicazione abbastanza estesa, almeno quanto a numero di file, che ho scritto alcuni mesi orsono.
Le modifiche non hanno riguardato la struttura del codice (niente refactoring, tanto per capirsi) ma sono state prettamente estetiche: aggiornamento massiccio degli header dei file, qualche ritocco stilistico, niente di più.
Per qualcosa Resharper mi ha dato una mano (e grazie di esistere :-)), per altri cambiamenti me la sono dovuta cavare a manina.
Dopo una decina di minuti in cui ho consumato i tasti CTRL, C e V più di quanto già non lo fossero, mi sono stufato e ho buttato giù un programmino che automatizzasse l'attività: ricerca di file in un ramo di directory in base ad un certo criterio ed una serie di sostituzioni.
Credo di aver dato alla luce il software più brutto della mia carriera, se si escludono i primissimi tempi: codice procedurale con un paio di OnClick e poco altro, gestione delle eccezioni brutale, parametri zero, interfaccia grafica scadente, prestazioni ... beh ... diciamo altamente migliorabili, giusto per non buttarmi troppo fango addosso.
Fatto sta che ci ho messo 20 minuti a scriverlo, 5 a provarlo - rigorosamente su una copia di lavoro dei file e trovando l'inevitabile bachetto evidenziato da una bella MessageBox.Show(exc.ToString()) - e infine altri 5 minutini ad eseguirlo e a verificare che avesse fatto il suo compito.
Risparmiandomi un pomeriggio di lavoro alienante.
Morale della favola: ho scritto del software usa e getta. Che non potrà mai andare oltre a questo scopo, per tutte le ragioni e i difetti che ho elencato sopra. Che però ha fatto il suo in maniera decorosa.
Lo sottolineo ancora una volta: questo non vuole essere un consiglio a seguire pessime pratiche di programmazione per fare prima, anzi.
Ho fatto prima, questa volta, perchè non ho dovuto mantenere, estendere e men che meno "mettere in produzione" il mio programmino. Perchè ovviamente la mezz'ora che ho risparmiato oggi poi la si paga con interessi da strozzino al primo ritocco che bisogna fare.
Però, in fin dei conti, penso di aver fatto la scelta giusta per la mia situazione.
Probabilmente una delle novità meno enfatizzate di C# v2.0 è la possibilità di disabilitare i warning tramite direttiva del preprocessore, oltre che a livello di opzioni globali di compilazione.
Per esempio, la classe:
class Sample
{
int i;
}
che genera un warning ("Field Sample.i is never used") può essere contornata da direttive #pragma che disabilitano e riabilitano il warning specifico:
#pragma warning disable 169
class Sample
{
int i;
}
#pragma warning restore 169
Bisogna andarci cauti, ovviamente, ma è una caratteristica che può risultare molto utile, soprattutto perchè evita la necessità di agire a livello dell'intero progetto.
Questo post in effetti sta tutto nel suo titolo.
Nel senso che è una domanda che mi sto ponendo, alla quale ho difficoltà a dare risposta e che rivolgo a chi ci vuole dedicare 5 minuti. So che, tra l'altro, qualche MCT tra i miei lettori c'è, e mi farebbe piacere sentire la sua opinione di esperto in questo campo.
Una cosa che mi chiedo è se la certificazione MCT sia, più che altro, un valore aggiunto ad una professionalità già formata e riconosciuta (anche in fase di ricerca lavoro), oppure se davvero possa costruire ed identificare da sola (o quasi) una professionalità.
Sulla carta, visto che MCT sta per Microsoft Certified Trainer, un lavoro che coinvolga la formazione, in senso lato, sembra essere quello che la identifica meglio.
Ed è quello che, per inciso, mi piacerebbe veramente fare.
Almeno, mi piace l'idealizzazione che me ne sono fatto: tieni corsi, ti mantieni aggiornato sulle tecnologie, in fondo unisci ciò che ti dà da mangiare a ciò che ti (mi) piace fare, studi perchè ti piace quello che studi, ma il tuo studio va ad essere necessario per il tuo lavoro. Fantastico !
Ora, il punto è: questa mia idea della figura di trainer, per quanto astratta possa sembrare, è poi distante dalla realtà, o ci si avvicina anche un pochino ?
In altre parole, al di là degli sconti e delle facilitazioni che, almeno credo, Microsoft ti mette a disposizione, puntare ad una carriera da trainer ha un qualche senso pratico, o rimane un'idea, bella ma difficilissima da realizzare ?
Iniziano a trapelare le prime foto dell'ultima build di Longhorn (5048), che Microsoft sta rilasciando ai partecipanti della WinHEC Conference 2005.
Vi consiglio di tenere sott'occhio anche il sito di Paul Thurrot, che in questi casi è sempre un punto di riferimento.
Dopo gli esami (di qualsiasi genere) di solito mi prende la mania dell'ordine.
Questa volta ciò ha implicato una bella formattata all'hard disk del portatile, ormai logoro da mesi di installazioni, disinstallazioni e paciughi vari.
Il primo nodo da sciogliere è stato la scelta del sistema operativo.
La volta precedente avevo ripiegato su XP a causa della mancanza di driver video validi per Windows Server 2003.
Li ho trovati da lì a poco, ma a quel punto non avevo voglia di ricominciare tutto da capo.
L'occasione si è presentata ieri, e voila. Sto pazientemente reinstallando tutto in "ambiente server".
Che non è esattamente la stessa cosa.
Il primo caso di discrepanza l'ho avuto ieri sera, al momento di fare shutdown.
Ora, prima di spiegare cosa è successo, una piccola premessa.
Da alcuni mesi ho preso l'abitudine di usare un utente a bassi privilegi (LUA, per chi ama gli acronimi) nel lavoro quotidiano al PC. Le ragioni sono ovvie e già abbondantemente spiegate, quindi non mi dilungo.
Non avevo però ancora utilizzato un utente non amministratore in ambiente Windows Server.
Anche questo deriva dalle mie (pessime) abitudini di considerare le macchine virtuali (Virtual PC) diverse da una macchina fisica. L'antivirus e gli aggiornamenti li faccio regolarmente su tutte, ma la pratica di utilizzare un utente "User" non l'ho ancora adottata. Risultato: non ho (non avevo) mai avuto esperienza diretta dei privilegi concessi o negati agli utenti in Windows Server 2003.
Ritornando all'argomento del post, ieri sera, prima di andare a dormire, mi è sembrata cosa buona e giusta spegnere il portatile.
Che avevo appena configurato con un utente Administrator ed uno User.
Ok: Alt-F4 e ...
La combo mi presenta solo la possibilità di fare logout. Oh bella !
Ha perfettamente senso.
In fondo siamo (ok, dovremmo essere :-) ) su un server, e non è cosa carina consentire ad un utente a bassi privilegi di arrestare il nostro prezioso servizio di e-commerce. Diverso è su un sistema client, dove tipicamente chi utilizza la macchina è un utente interattivo che, ogni tanto, ha perfino la necessità di spegnerla.
La controprova è stata immediata.
Ho lanciato gpedit.msc (Group Policy Editor): Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.
In un sistema XP il diritto di spegnere la macchina è garantito agli utenti che appartengono ai gruppi Administrators, Power Users, Backup Operators e Users.
In un sistema Windows Server 2003, lo stesso diritto è garantito ai gruppi Administrators, Power Users e Backup Operators.
Lo soluzione è stata semplice: ho creato un gruppo (UsersEx) al quale ho garantito la possibilità di arrestare il sistema, e vi ho inserito il mio LUA.
E il gioco è fatto.
Non so se esistano soluzioni migliori, sia dal punto di vista della praticità che da quello della sicurezza.
In tal caso fatemi sapere :-)
C'è sempre molta enfasi a proposito dello stile del codice: convenzioni per i nomi, commenti e documentazione, indentazione e via dicendo.
Lo scopo è a grandi linee quello di scrivere codice facilmente leggibile e, di conseguenza, manutenibile, dagli altri o semplicemente da se stessi.
Preso da qui, e davvero molto divertente :-)
... il nostro eroe, sfidando il traffico paralizzato dallo sciopero del trasporto pubblico e dall'inizio del week-end di festa, si recò al proprio CTEC di fiducia per sostenere l'ultimo esame e conseguire, ad oltre un anno dall'inizio delle sue fatiche, la sospirata certificazione Microsoft.
Ebbene sì.
Da ieri pomeriggio, ore 16 circa, sono ufficialmente MCSD.NET !!
Manco a farlo apposta, stamattina mi sono svegliato alle 6 e mezza, causa gatto temerario e desideroso di compagnia che ha deciso di soggiornare stabilmente sul mio cuscino.
Penso che mi prenderò una giornata di totale collasso.
Ora che ho asportato la belva a forza, vediamo se mi riesce di riprendere sonno ...
Disponibile, ora, anche attraverso il sito web.
Come sempre, la versione free visualizza alcuni banner pubblicitari che vengono rimossi all'atto della registrazione, per la quale sono richiesti 39 dollari.
Cito direttamente dall' MSDN:
eLearning is a effective and efficient system of self-paced personal training, available over the Internet. Microsoft has made courses available in eLearning form to cover several of the important new technologies included in Visual Studio 2005, like Connected Systems and Smart Clients, plus Windows Server 2003, with more planned for the near future.
Rimango sempre un affezionato della carta, ma proverò a modificare il mio giudizio su questa modalità di apprendimento, magari iniziando proprio da questo corso sulla migrazione ai 64 bit.
Naaahh ... lo faccio per vincere il televisore :-)
Oltre che il diminutivo di Robert, Bob è il nome di una shell, alternativa a quella tradizionale, che Microsoft propose nel 1995: il computer era presentato come una stanza virtuale, all'interno della quale gli oggetti - o le decorazioni - erano i punti di partenza per avviare e gestire programmi e funzionalità del sistema.
Credo che non tutti siano a conoscenza di Microsoft Bob.
Il motivo è presto detto: fu un vero flop commerciale.
Un po' perchè l'approccio era a dir poco inusuale, e forse più difficile da digerire.
Un po' perchè se in termini di usabilità poteva probabilmene competere con Windows 3.1, il confronto con Windows 95, appena rilasciato, lo relegò prematuramente negli archivi storici del museo dell'informatica.
Beh, quasi.
Avete presente quel ... ehm ... simpaticissimo cagnolino che ci propone mille suggerimenti mentre utilizziamo Office o cerchiamo qualche file con Windows XP ?
Si chiama(va) Rover.
Il migliore amico di noi utenti
Quello che ci aiutava nelle nostre mansioni quotidiane.
E quello che manteneva la nostra casa sicura dalle intrusioni.
Sì, perchè Rover era anche un ottimo cane da guardia.
Con un piccolo, ininfluente difetto.
Quando un utente (l'intruso) digitava per tre volte di seguito la password errata, Rover, che era tenero di cuore, gli proponeva cortesemente di inserirne un'altra, magari più semplice da ricordare !!
Mi sa che, nel 1995, la security non era esattemente ai primi posti all'ordine del giorno ...
Se siete curiosi, trovate qualche notizia e qualche snapshot qui e qui.
A starci dietro ce n'è un po' per tutti i gusti ... e per
tutti i portafogli.
Una delle cose che mi ero ripromesso per questo periodo di pseudo-libertà da
impegni (che poi tale non è ... diciamo che ho maggiori possibilità di
gestirmi) era quello di seguire più assiduamente gli eventi tecnici che si
presentano.
Così ne riporto alcuni qui, almeno non avrò la scusa per dire: "Non ci sono
andato perchè non lo sapevo".
Iniziamo dal più vicino, nel tempo e nella distanza: 5
maggio, Milano, Visual C++ Day
.
Ora, visto che:
- il C++ è stato il mio primo amore (se così lo si può
chiamare)
- con la nuova release non ci sono più (o comunque si
sono molto ridotte) le attenuanti per giudicare il C++ scomodo da usare in
ambiente managed (vedi specifiche C++/CLI)
- abito a 150Km (1 ora e mezzo) di macchina dalla sede
dell'evento
- è gratuito
direi che spero proprio di esserci.
In ordine di tempo, il 14 maggio (sabato), a Reading
(che è a una 40ina di Km da Londra) si tiene il DeveloperDeveloperDeveloper!
Event.
Questo non l'ho visto segnalato da nessuno, se non da
Mike Pelton in questo post .
A dire il vero, ciò che mi attira, a parte i
contenuti, è l'idea di un week-end lungo a Londra. Una vacanza non proprio
vacanza, insomma. Tra l'altro, la location, a giudicare dalle foto
della zona, è sul bello spinto.
Dovrò vedere un po' se riesco a trovare qualche offerta vantaggiosa sui voli e
sugli alberghi. La conferenza è gratuita.
Andando avanti, Roberto ha segnalato
in questo post la prossima FWC a
L'Aquila.
Anche in questo caso:
- conferenza gratuita
- location niente male (non ci sono mai stato, ma le foto
parlano da sole)
- argomenti che, almeno a me, interessano parecchio
E' un po' più distante, per me, ma potrei coniugare un
giretto di un paio di giorni in una zona dell'Italia che conosco poco, per non
dire niente.
E poi ...
... e poi c'è il TechEd e la PDC .
Qui il discorso è ben diverso.
Non si discute il "peso" delle conferenze. Anche
economico, però. Si parla di cifre che sono un po' altine per chi la partecipazione se la autofinanzia.
Ho i miei dubbi che riuscirò a partecipare a qualcuna di quelle conferenze,
ma non si sa mai ... il superenalotto magari fa un salto di qua !
powered by IMHO 1.2
Sto leggendo Programming ASP.NET, scritto da Jesse
Liberty ed edito da O'Reilly.
E' un compendio, piuttosto corposo, sulle caratteritistiche di ... immaginate
un po' ... ASP.NET.
Ora, al di là della validità dei contenuti, che non mi interessa in questa
discussione, la lettura mi ha dato lo spunto per una considerazione.
Tutti (tutti !) gli esempi sono riportati in duplice veste: C# e
VB.NET.
Il che, nella prefazione, è segnalato come un pregio del volume in questione,
che consente una facile comprensione ai programmatori di entrambe le estrazioni
(a volte si farebbe meglio a parlare di "fedi", ma questo è un altro
discorso).
Personalmente, non sono d'accordo con questo approccio.
Il motivo è semplice: la prefazione stessa indica, nella
sezione Who this book is for
, che il libro si rivolge a programmatori che hanno almeno una minima dimestichezza
con uno dei due linguaggi in questione. Se questa dimestichezza manca
(per esempio se i lettori conoscono solo C++ o solo Java), l'autore
rimanda ad altri volumi specifici per il linguaggio. Ovviamente vengono
segnalati volumi nella stessa catena editoriale, e questo è assolutamente logico
e giustificato.
Beh, non ci piove: un testo che illustra ASP.NET (o
ADO.NET, o la Security nel CLR, e chi più ne ha più ne metta, limitandosi alla
piattaforma .NET che è, appunto, multilinguaggio
) non si può preoccupare di spiegare anche la
sintassi di C# o VB.NET.
Esistono volumi appositi, che inevitabilmente risultano più completi e, in
questo caso, di riferimento, tanto è vero che sono "referenziati"
nell'introduzione.
Ciò che è sufficiente per comprendere gli esempi è una
minima conoscenza delle caratteristiche di base del linguaggio: dichiarazione di tipi
e variabili, semplici costrutti condizionali, sintassi per effettuare
un cast, sintassi per la gestione delle eccezioni, ...
Una volta assodato che il lettore è in grado di comprendere queste
caratteristiche, l'attenzione si rivolge alla descrizione della piattaforma, o
della parte della piattaforma che viene presa in considerazione.
Il linguaggio è uno strumento , in questo caso. Che serve perchè, in fin dei
conti, è quello che andremo a scrivere, è il mezzo per utilizzare le
funzionalità della piattaforma (almeno in questo contesto !).
Generalmente chi studia un aspetto della
piattaforma in questione conosce già, almeno un pochino, lo strumento.
Se così non è, giustamente si rimanda ad un testo specifico. Che magari
illustri anche quelle caratteristiche che del linguaggio, strettamente
parlando, non sono (le eccezioni o il sistema dei tipi sono caratteristiche
dell'ambiente virtuale, che ovviamente vengono illustrate di pari passo con le
spiegazioni sul modo in cui il linugaggio le rende utilizzabili).
Quindi ...
Caso 1: il lettore non conosce alcun linguaggio.
Probabilmente non conosce .NET in generale. Meglio partire da un altro
volume.
Caso 2: il lettore conosce solo un linguaggio. Probabilmente conosce però,
almeno un pochettino, le caratteristiche della piattaforma. Con un capitolo
introduttivo da dieci pagine è in grado di comprendere anche un altro
linguaggio.
Caso 3: il lettore conosce entrambi i linguaggi. Che bisogno
c'è di riportare gli esempi duplicati ?
Io, per esempio, ricado nel caso 2.
Non ho quasi mai utilizzato VB prima di .NET, non ho mai utilizzato VB.NET,
ho letto qualche esempio qua e là. Conosco C#.
Non credo di essere un genio, però se leggo codice in VB.NET che mi illustra ASP.NET,
magari dopo una ripassatina fornita dal capitolo introduttivo di cui sopra,
non credo neanche di avere troppi problemi ad andare avanti.
Risultato: compro un libro da 1000 pagine che poteva essere tranquillamente
da 700.
Ora, sulla copertina è riportato, ben in evidenza: ".... with C#
and VB.NET".
Cioè: il libro si rivolge ad un pubblico di entrambe le estrazioni.
E' ovvio che si cerchi di avere il numero maggiore
possibile di lettori/acquirenti. Però un programmatore C# che deve studiare ASP.NET non
dovrebbe escludere dalla lista di potenziali
libri quelli che riportano gli esempi in VB. E vicecersa, ovviamente.
Perchè magari ne perde alcuni ben scritti e completi.
Capisco la ragione editoriale, ci mancherebbe. Non
dimentichiamoci che si parla sempre e comunque di vendite.
Però così il peso (inteso in numero di pagine) di un volume si ingigantisce.
E il prezzo, credo, un po' ne dovrebbe risentire ...
Nota di fine Post.
Esistono in commercio volumi (belli, fra l'altro) editi in due versioni
differenti, per VB e C#.
A memoria mi vengono in mente il libro di Richter (Applied Ms .NET Framework
Programming) e quello di Ingo Rammer (Advanced .NET Remoting), che sono entrambi
usciti in una prima versione con codice in C# e sono stati affiancati più tardi
dal cugino in VB.NET.
Non posseggo nessuna delle versioni VB, ma entrambe quelle in C#.
Dal mio punto di vista, ha forse più senso la prima della seconda, perchè gli
argomenti sono maggiormente sensibili alle differenze di linguaggio (overload di
operatori, indicizzatori, eccezioni con filtro, ...).
Evidentemente la tematica della scelta del linguaggio è molto sentita e,
talvolta, affrontata in maniera diversa dalle case editrici (o dagli
autori).
Che ne pensate ? I commenti sono aperti.
powered by IMHO 1.2
La tecnologia ha fatto passi da gigante negli ultimi
anni.
L'esordio di questo post è quanto di più banale possa esserci, per cui
cercherò di illustrare meglio il contesto in cui vorrei inserire questa
affermazione.
Prendiamo la "rivoluzione internet". Potenzialmente
, il risvolto sociale primario è l'apertura di nuovi
canali di comunicazione, per i quali la distanza geografica non è più un fattore
determinante.
Inutile, e troppo esteso, il paragone con il tempo in cui le notizie
viaggiavano a cavallo, e si perdevano le guerre per un ritardo del messaggero.
Ma anche limitandosi a un'epoca un po' più vicina alla nostra (praticamente ieri - o
oggi ?) non si può negare che la diffusione delle informazioni,
specialmente quelle ufficiali, sia stata decisamente rallentata dalle latenze dovute alla
distanza.
Un ente che deve inviare bollettini ufficiali ai suoi
rappresentanti è costretto a seguire un iter burocratico a volte inutilmente
complicato, fatto di firme e controfirme su documenti cartacei, il che porta senza via
di scampo alla rinuncia all'immediatezza dell'informazione.
La qual cosa risulta problematica, talvolta grave, quando la validità
dell'informazione è data dalla sua non-obsolescenza.
Questo è il contesto in cui inserico la frase
di esordio: la tecnologia ha compiuto progressi tali da consentire di annullare l'intervallo tra la spedizione e la consegna delle
notizie, e delle informazioni in generale. Solamente, bisognerebbe che questi progressi
venissero sfruttati a dovere: a volte lo sono, a volte ancora
no.
Questa riflessione mi viene dall'aver intrattenuto una conversazione, alcuni
giorni orsono, nel corso della quale la lamentela del mio interlocutore era
proprio rivolta alla latenza delle informazioni: "Non è possibile che queste
cose si vengano a sapere dal telegiornale una settimana prima di averne una
comunicazione ufficiale".
Il pensiero è andato subito alle diverse forme di comunicazione immediata che
la rivoluzione internet ha aperto, e che, come rimarcato, non vengono sempre
sfruttate.
Quanto è problematico mettere su una mailing-list ? Un sito aggiornato
quotidianamente ? Un feed RSS ?
Dal punto di vista della tecnologia, ormai praticamente nulla.
Dal punto di vista dell'utilizzatore, altrettanto (il browser e il client di posta lo abbiamo installato tutti, l'aggregator probabilmente
raggiungerà in breve la stessa diffusione, ammesso
che già non sia così).
Dal punto di vista dell'ente (termine assolutamente generico)
intervengono, però, alcuni fattori che ritardano l'adozione di queste
facilities a livello ufficiale. La sicurezza, o forse la paura di
insicurezza, credo sia l'ostacolo principale da
superare.
Perchè qui è il problema, secondo me. Rimanendo nel campo della non-ufficialità,
le risorse ci sono, e numerose, con l'unico problema di riuscire
a trovarle (e questo è il meno) e soprattutto di verificarne l'autenticità.
L'interrogativo sulla non autenticità di una notizia
rende a volte inutilizzabili, per quanto utili, le informazioni.
Così è possibile che un operatore (anche qui il termine è assolutamente
generico) si trovi a conoscere un fatto e a non poter applicare questa
conoscenza, in attesa di una circolare che tarda ad arrivare.
In quel periodo di interregno possono succedere le cose più disparate:
si va da un semplice (!!) disservizio a conseguenze ben più gravi, a seconda
dell'ambito dell'informazione.
Non sono sufficientemente dentro il settore da capire
quanto questa sia solo una percezione o, piuttosto, un'effettiva realtà. Ma la
senzazione, vista dall'esterno, è che ci sia ancora un divario piuttosto marcato
fra le potenzialità della tecnologia attuale e l'effettivo uso
che ne viene fatto.
Io ritengo di avere competenze informatiche superiori alla media (prendendo un campione di
persone che va dalla nonna 90enne al cracker che buca i sistemi di sicurezza
delle banche). Eppure quando acquisto un prodotto da un sito di e-commerce
e digito il codice della mia carta di credito non nascondo che un piccolo
senso di vuoto lo sento ancora. E tutto ciò nonostante sappia cosa vuol dire
https, cos'è un certificato digitale e via discorrendo.
Ed è così che mi viene da pensare come la tecnologia abbia fatto passi da gigante, ma così non sia
stato per la sua divulgazione.
Se mia madre (scusa, mamma, se ti uso sempre come
prototipo di utente inesperto) si trova di fronte alla necessità di acquistare su
Internet, semplicemente non è in grado di valutare autonomamente i rischi che
questa azione comporta.
Allora chiede a me.
Io non sto a spiegarle le questioni più strettamente tecniche, che non
sarebbe in grado di comprendere appieno, e le dico semplicemente di procedere
all'acquisto fornendo i dati della sua carta di credito.
Mia madre si fida, e compra.
Provate a traslare questo procedimento nel contesto di un organo ufficiale. Non
è difficile immaginare come le conseguenze di una scelta assumano
proporzioni ben maggiori, in linea con i rischi che si corrono. E questo è
un fattore determinante per il ritardo nell'adozione di un mezzo di comunicazione
nuovo.
Ed eccoci giunti al titolo di questo lungo post: "Diamo una mano alla
tecnologia".
Che, tradotto, si legge: "Cosa possiamo fare per annullare il divario fra ciò
che abbiamo a disposizione e ciò che effettivamente utilizziamo ?".
Sembra scontato dirlo, ma credo che la divulgazione sia la chiave.
E non si parla di illustrare i principi della crittografia all'utente finale.
Semplicemente perchè l'utente finale non deve nemmeno accorgersi che
dietro ad una sua richiesta su internet intervengono diversi strati che la
rendono, eventualmente, sicura.
Si parla di formare gli esperti. Di "insegnare ai docenti".
Le possibilità ci sono. Molto spesso anche di ottimo livello. Alcune le
avete sotto gli occhi, mentre state leggendo questo post (mi sembra inutile
linkare la home di DevLeap, basta fare click sul logo in alto !).
Se dobbiamo rinunciare, per forza di cose, alla capillarità della
formazione, ciò nonostante è lecito puntare alla capillarità della
divulgazione.
Sarò ottimista, ma credo che questa si possa ottenere, appunto,
incrementando il livello di preparazione ed aumentando la sensibilità degli
"esperti".
Così anche l'utente finale ha la garanzia di aver avuto un consiglio
ponderato.
E l'ente ufficiale può valutare con maggiore tranquillità il "grande salto" nel mondo
telematico.
powered by IMHO 1.2
Eh già ... finalmente sono state rese disponibili
le versioni a 64 bit di Windows
(XP e 2003 Server).
Tecnicamente parlando, il salto è enorme.
L'architettura hardware e l'instruction set consentono di lavorare in modo
nativo con valori di 8 byte: fondamentalmente, i registri sono grandi il doppio,
e vengono ovviamente implementate le istruzioni necessarie a
manipolarli.
I vantaggi, a mio giudizio, vanno in due filoni principali.
Da un lato, le capacità di elaborazione su quantità "grandi" (l'artimetica su
valori a 64 bit risulta ora infinitamente più performante).
Dall'altro la capacità di indirizzamento: puntatori il
doppio più capienti, e possibilità di indirizzare una quantità di memoria
praticamente illimitata (anche se andrei piano con queste considerazioni, visto
che un illustre personaggio
, alcuni anni orsono, sosteneva che il limite dei 640Kb
non sarebbe mai stato un ostacolo !).
Queste caratteristiche vanno ovviamente sfruttate dal software che vi è
costruito sopra.
A partire dal sistema
operativo, per arrivare al software applicativo.
In quest'ottica, credo che la scelta di adottare come target un ambiente
virtuale risulti assolutamente vincente.
Immaginate cosa vorrebbe dire ricompilare ex-novo un'applicazione
nativa.
Controllare di non aver fatto assunzioni legate alla piattaforma
(principalmente sulle dimensioni dei puntatori, allocazioni di memoria, ecc...).
Gestire due versioni dello stesso software, almeno in forma binaria, per
architetture IA32 e IA64.
Spostare tutte queste problematiche nello strato di Virtual Machine non è
cosa da poco, perchè il "lavoro sporco" lo hanno fatto altri, e probabilmente
meglio di come avremmo potuto fare noi (ricordandosi sempre, comunque, che gli
IntPtr esistono e vanno utilizzati in modo appropriato !).
Discutendo il modello di compilazione Just-In-Time, i sostenitori degli
ambienti virtuali portano spesso la maggiore adattabilità all'effettiva
architettura di esecuzione come argomento, a parziale contrappeso rispetto
ad una maggiore lentezza, dovuta ad un ulteriore livello di
indirezione.
Questa argomentazione non mi aveva mai convinto, e tuttora non riesce a
farlo, rimanendo nell'esclusivo campo delle prestazioni.
Però ha risvolti decisamente importanti quando si parla di condivisione di
componenti fra architetture differenti, in termini di uniformità di sviluppo,
manutenibilità ed astrazione.
Non credo che queste considerazioni abbiano mai avuto un peso
primario nella scelta di adottare .NET come piattaforma, almeno rispetto ad altri
fattori, rapidità di sviluppo in primis. Credo, però, che potranno iniziare ad
averlo ora che l'introduzione di hardware e sistema operativo a 64 bit è una
realtà del presente, anche in campo consumer.
powered by IMHO 1.2
Ogni volta che faccio un giro con Reflector/ILDASM scopro qualcosa di nuovo.
L'ultima, in ordine di tempo, è il percorso della chiave con la quale gli assembly del CRL/FCL (v1.1) sono stati firmati da Microsoft sulla(e) macchina(e) di build.
Ecco un breve (!!) e parziale elenco:
- mscorlib.dll --> E:\com99\bin\EcmaPublicKey.snk
- system.dll --> E:\DNA\public\tools\common\security\EcmaPublicKey.snk
- system.configuration.install.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
- system.data.dll --> E:\DNA\public\tools\common\security\EcmaPublicKey.snk
- system.data.oracleclient.dll --> E:\DNA\public\tools\common\security\EcmaPublicKey.snk
- system.design.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
- system.directoryservices.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
- system.drawing.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
- system.drawing.design.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
- system.enterpriseservices.dll --> E:\com99\bin\FinalPublicKey.snk
- system.management.dll --> FinalPublicKey.snk
- system.messaging.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
- system.remoting.dll --> E:\com99\bin\EcmaPublicKey.snk
- system.runtime.serialization.formatters.soap.dll --> E:\com99\bin\FinalPublicKey.snk
- system.security.dll --> E:\com99\bin\FinalPublicKey.snk
- system.serviceprocess.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
- system.web.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
- system.web.mobile.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
- system.web.regularexpressions.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
- system.web.services.dll --> E:\DNA\public\tools\common\security\FinalPublicKey.snk
- system.windows.forms.dll --> E:\DNA\public\tools\common\security\EcmaPublicKey.snk
- system.xml.dll --> E:\DNA\public\tools\common\security\EcmaPublicKey.snk
Vista in un altro modo, MS ha usato le seguenti copie:
- E:\com99\bin\EcmaPublicKey.snk
- E:\com99\bin\FinalPublicKey.snk
- E:\DNA\public\tools\common\security\EcmaPublicKey.snk
- E:\DNA\public\tools\common\security\FinalPublicKey.snk
- FinalPublicKey.snk (path relativo !!)
di due chiavi differenti, il cui hash (aka PublicKeyToken) riporto qui sotto:
- b77a5c561934e089 (EcmaPublicKey)
- b03f5f7f11d50a3a (FinalPublicKey)
Due cose mi hanno colpito.
La prima: date due chiavi, ciascuna è caricata da almeno due file differenti (in un caso, system.management.dll, essa addirittura risiede in un path relativo rispetto al file che contiene l'attributo AssemblyKeyFileAttribute). Il che fa presupporre (non è detto, comunque) l'utilizzo di due macchina di build distinte.
La seconda: hanno usato chiavi prelevate da file, invece che da un container (soluzione, quest'ultima, un po' più sicura ...).
Non capisco bene la ragione di queste scelte.
Cosa mi sono perso ?
Update: se non lo avete letto, il commento di Marco Russo chiarisce questo comportamento.
powered by IMHO 1.2