marzo 2007 - Posts
Per chi ama una forma di training alternativa, c'è una bella class online con Krzystzof Cwalina, argomento API Design Guidelines.
Dura più o meno come un episodio della saga del Signore degli Anelli (versione integrale :-)) ma vale la pena.
P.S. Ovviamente, per chi non lo ha acquistato, segnalo anche il libro che Krzystzof ha scritto con Brad Abrams, davvero un must.
Non so quanti di voi abbiano mai partecipato a (o tenuto) un MOC. Per chi non sa cos'è un MOC, la sigla sta per Microsoft Official Curriculum e categorizza una serie piuttosto nutrita di corsi di formazione prodotti da Microsoft (o, almeno, usciti sotto quel nome) relativi a diversi prodotti/tecnologie/ecc... Si spazia dalla programmazione all'attività sistemistica alle business solutions e via dicendo.
Il discorso che sto per fare non si limita ai MOC, anzi, semplicemente prendo come punto di partenza quel breve :-) modulo di feedback che si chiede di compilare ai partecipanti del corso al termine dello stesso.
[Nota: vi prego ... doveste seguire un corso ... compilate il feedback !!]
Ieri, di rientro da Bologna, stavo riflettendo su quanti siano realmente i fattori che determinano la validità di un corso di formazione. Che non sono necessariamente specifici dei corsi di informatica, anche se ovviamente alcuni punti in questi casi si applicano più facilmente.
Ecco quindi che ne penso io.
L'aula
L'aula è importante da due punti di vista, a mio parere.
Da un lato, in quanto insieme di attrezzature, è quella che consente in fin dei conti di erogare il corso stesso. Attrezzatura comprende i computer (fare esercizi su un 486 è poco stimolante e a volte rischia di diventare un deterrente), i monitor (mai sottovalutare i monitor, a maggior ragione quando vengono usati come visualizzatore del computer del docente), la connettività della sala e via discorrendo.
Dall'altra parte, in quanto ambiente, l'aula diventa indirettamente un punto chiave per la riuscita del corso. E' un po' come dire che quando torni a casa e trovi un ambiente confortevole ti rilassi e ti godi le cose. Stessa identica cosa qui: in fin dei conti ci si sta 7/8 ore al giorno e l'effetto sulle persone può determinare, almeno in parte, la predisposizione ad apprendere.
Il contenuto e il programma
Beh ... si può valutare un corso di formazione prescindendo dai contenuti che questo propone ?
Mmhhh ... di sicuro non si può negare però che il programma (inteso come disposizione temporale dei contenuti nell'arco delle giornate) sia cruciale.
Questo è un punto che potrà sembrare ovvio, ma che ha le sue particolarità.
Vi faccio un esempio. Se una persona partecipa ad un corso su argomenti di cui non ha conoscenza pregressa, non gli sarà tanto semplice capire se la scelta dei contenuti è stata corretta, nè se il flusso del corso è stato valido. A volte si rischia di scambiare ciò che è un "buon contenuto" da ciò che è un "contenuto appreso". Non è sempre semplice parlare in maniera diffusa di una tecnologia, con un filo logico che guida gli argomenti. Un programma incompleto e dai contenuti poveri a volte può essere giudicato soddisfacente, e viceversa.
Il materiale didattico
Anche in questo caso serve un distinguo.
Materiale didattico comprende libri di testo (se ci sono), slide (queste ci sono quasi sempre), esercitazioni, laboratori.
Sono tutti punti molto importanti, la cui applicabilità è estremamente variabile in base alla tipologia di corso.
Ci sono corsi "hands-on" che privilegiano la pratica, e chiaramente la qualità (completezza, correttezza, applicabilità) degli esercizi è fondamentale. La cosa si rovescia nei "seminari", nei quali la parte teorica ha la precedenza.
Per inciso, produrre delle buone slide è un'arte, secondo me. Al di là degli effetti speciali e delle animazioni strane.
Il docente
C'è chi dice che, dato un pacchetto corso, il docente assume una rilevanza bassa.
Mi chiedo se chi afferma una cosa del genere ha idea di cosa vuol dire tenere un corso in aula.
Credo che le qualità del docente siano *fondamentali*.
Le competenze, certo.
La capacità di esposizione dei contenuti.
La capacità di integrazione con gli input dell'aula.
Questo è un discorso valido in generale nel campo della formazione: se vi parlano dell'arte bizantina, ci sarà differenza fra uno che vi legge il libro di testo e uno che cerca di trasmettervi quell'argomento. O no ?
I partecipanti
Ecco, infine, gli "alunni".
Chi è che rende una classe attiva e partecipe ?
Da dove il docente prende gli spunti per tarare il corso in via di svolgimento ?
Chi si può porre le domande più concrete, semplicemente perchè provenienti dal proprio contesto ?
I partecipanti danno "vita" al corso che seguono.
E ignorare questo elemento semplicemente uccide il corso, rendendolo anonimo e in fin dei conti inutile: allora bastava andarsi a comprare un libro, no :-)
... e io c'ero ;-)
A dire il vero volevo esserci alla prima edizione, alla seconda ero iscritto e ho dovuto rimandare (mannaggia), alla fine ce l'ho fatta alla terza. Che poi, se vale la regoletta di Microsoft, è anche la versione buona !!
Scherzi a parte, inizio con i meritati complimenti ad Igor Macori.
Per tante cose. Fra tutte, una di quelle magari meno immediate da rilevare per chi non ci pensa (o non fa questo lavoro): la capacità di gestione di una classe numerosa, molto attiva e molto avida (in senso buono) di conoscenza e di risposte a un trilione di domande.
Sono state tre belle giornate che ho ritagliato con vero piacere nel mio calendario.
Di cosa si è parlato ... beh ... a parte che si dovrebbe dedurre dal titolo, sicuramente faccio prima a linkare questo.
Caspita, ogni volta che ci metto mano su mi rendo sempre di più delle potenzialità dello strumento. Che a mio modo di vedere ha un punto di forza gigantesco nella flessibilità e nelle capacità di integrazione che sta man mano raggiungendo.
Non è una considerazione che si può relegare ad una frase da fine post, però la faccio lo stesso, anche perchè è una tematica sulla quale mi è capitato di avere un paio di accese discussioni in passato.
Ed è questa: fra uno strumento esclusivamente "custom-made" che fa potenzialmente di tutto (il software che implementa anche l'algoritmo di reverse delle stringhe, e perchè no magari in assembler) ed uno strumento esclusivamente "no-code" che fa il suo, solo il suo (non cambi manco i colori) ma il suo lo fa molto molto bene, credo che la scelta di una piattaforma di integrazione, che può però avvicinarsi ad entrambi i lati del "parlamento", sia davvero *fondamentale*.
Ma dove mai li prenderò mai questi titoli ;-)
Blogging = .
Train = (1) sono in treno attaccato al pc e a un lavoro da finire e (2) train come training
Train+Blogging = TrainBlogging ~= Trainspotting = il mio stato comatoso attuale
SharePoint = Vedi post successivo ;-)
Chi ha paura degli eventi ? Perchè, in fondo, cos'hanno fatto di male ?
D'altra parte si sa che spesso si ha paura di qualcosa se non la si conosce !
E dopo essere entrato negli annali per questa frase "leggermente" scontata, passiamo alla parte tecnica del tutto: cosa sono in realtà gli "eventi" in .NET ?
A dire il vero le domande sono state, molto più spesso: "A cosa servono ?", oppure, visto che in fondo qualche evento le classi di sistema lo espongono, "Ma li devo usare anch'io ?".
Iniziamo subito col dire che nulla si "deve usare". Una buona idea però sarebbe quella di comprendere gli strumenti che si hanno a disposizione, in modo tale che essi si "possano usare", valutandono preventivamente i benefici e le opportunità di utillizzo.
Ovviamente gli eventi non sfuggono a questa regola.
Una cosa che, per la mia esperienza almeno, li ha sempre resi ostici da capire (e da spiegare) è il meccanismo che i rende possibili: cosa che è resa ancora più difficile dalle differenze di background tecnico delle persone.
Mi spiego: quante volte un articolo/capitolo/contenuto sui delegati (poi vedremo come i delegati sono correlati agli eventi) li introduce come "puntatori a funzione type-safe" ? Non critico la correttezza o meno di questa definizione, solamente il fatto che per dedurne qualcosa di utile da aprendere bisognerebbe avere una buona conoscenza di:
- Puntatori
- Funzioni
- Type-Safe
Non è così banale come sembra.
E comunque, per farla breve, diverse volte mi sono trovato a spiegare i meccanismo di eventi del .NET Framework, ma non sempre i concetti di base erano così ben chiari.
Scopo del post (di questo e dei prossimi correlati): provare a descrivere il meccanismo degli eventi partendo dal giurassico ... niente paura comunque, l'assembler ce lo teniamo per un'altra volta :-)
Ready, set, go.
Ci siamo noi, programmatori, che scriviamo il nostro codice nel nostro linguaggio di programmazione preferito (rimaniamo nell'ambito dei linguaggi "classici", per dirla in modo corretto "imperativi", per dirla in modo semplice: C, C++, Pascal, Java, VB, VB.NET, C# eccetera).
Tipicamente avremo suddiviso il codice di cui sopra in "funzioni". A questo livello di discussione i metodi delle classi rientrano nella categoria "funzioni".
Compiliamo e produciamo un file di output (dll, exe, ...).
All'interno del file (binario) ci sono zone che contengono il "codice" della funzione: una sequenza ordinata di istruzioni che ne rappresentano il flusso di esecuzione.
Queste istruzioni possono essere la rappresentazione binaria dell'instruction set del linguaggio macchina (x86, ad esempio). Questo avviene se compiliamo un'applicazione nativa (in C, ad esempio) con un compilatore che produce codice macchina.
In alternativa queste istruzioni possono essere la rappresentazione binaria delle istruzioni IL (Intermediate Language, il linguaggio della macchina virtuale .NET). Usando un compilatore C# (VB.NET, eccetera) questo è quello che si ottiene.
In termini più generali, il compilatore traduce il nostro codice sorgente in codice eseguibile da un qualche sistema di esecuzione: il CLR, la JVM, la CPU, ...
Il fatto che, poi, il codice eseguibile da una macchina virtuale come il CLR debba essere tradotto in codice eseguibile da un processore ... beh ... non c'è forse un altro compilatore di mezzo (il Just In Time compiler del CLR) ? In questi termini il codice IL diventa il "sorgente" per il Jitter, che infine produce x86 (o qualunque altro tipo di codice eseguibile sulla macchina target).
Benissimo.
In ogni caso questo "codice eseguibile" è ovviamente una cosa solo in potenza, finchè qualcuno non lo esegue !
Lanciamo l'applicazione. Se ci limitiamo al mondo Windows, l'OS crea un processo (un'area di memoria e un bel po' di informazioni sullo stesso) e copia all'interno dell'area di memoria relativa il contenuto dell'eseguibile che abbiamo prodotto.
Di fatto, la nostra funzione "Somma" ora è costituita, sì, da una serie ordinata di istruzioni, che in fase di esecuzione risiedono però in memoria ad un certo indirizzo, essendovi state "mappate" a partire dal file fisico (il .exe, .dll, ...).
Un puntatore a funzione contiene questo indirizzo.
Ora, immaginate il caso in cui una funzione (A) richiami un'altra funzione (B).
"Richiamare" significa, in fin dei conti, che A manda in esecuzione il codice di B. Di fatto, chi mantiene un riferimento al codice in esecuzione al momento (nelle architetture x86 è un registro) vede che il proprio valore cambia: dentro ci andiamo a mettere l'indirizzo della funzione B.
La cosa non è del tutto corretta e ci sono eccezioni, ma teniamocela per buona.
Una domanda, ora.
Chi sa qual è l'indirizzo della funzione B ?
In altri termini, se nel codice sorgente che abbiamo scritto è stata effettuata una classica chiamata di funzione, ci possiamo immaginare che il compilatore sia stato in grado di indicare l'indirizzo giusto nel momento in cui ha "emesso" l'istruzione di chiamata (la CALL x86, la call-callvirt in IL).
I problema nasce quando questo indirizzo non è noto a priori.
Ma quando mai ??
Beh, per esempio se A si aspetta che qualcuno, dall'esterno e durante l'esecuzione, gli indichi la funzione da chiamare.
Pensatela in questi termini.
A è un algoritmo molto complicato che lavora su dati di diverso tipo (la versione .NET della cosa è che lavora con delle interfacce, se volete, o con delle classi abstract). Ad un certo punto, A ha la necessità di fare un confronto fra due dati.
Poichè A è generico (lavora su dati diversi, potenzialmente anche non noti nel momento in cui A stato scritto), A non ha la minima idea di come poter fare il confronto !!
B è invece una funzione che fa, appunto, il confronto fra due dati di tipo X.
Quando A viene utilizzato per elaborare dati di tipo X è buona cosa che chiami la funzione B, che è deputata proprio a questo.
E come fa A a sapere che deve invocare la funzione B ? Ma non avevamo detto che ...
Infatti, A non lo sa, e qualcuno glielo deve dire.
Così come passiamo ad A dei dati di input di tipo X, allo stesso modo passiamo ad A un "puntatore alla funzione B".
La chiamata (A-->B) avverrà lo stesso, ma in via assolutamente dinamica !
Mi rendo conto di come questa descrizione sia piuttosto semplicistica, però spero riesca a porre un minimo di basi per comprendere meglio come, nel .NET Framework, questi concetti sono implementati.
Enter the world of delegates :-)
(... to be continued ...)
Causa peripezie varie (leggasi: furto di portatile e successiva doccia di acqua corrente al qtek) mi sono trovato a dover comprare nuovamente buona parte della mia scorta hardware.
Ovviamente il tutto di fretta e i tutto in veste di "soluzione temporanea" perchè, si sa, c'è gusto anche nella scelta, no ?
Fatto sta che mi ritrovo a postare dopo un po' di tempo di buio internet serale (sorry, ma nella borsa del portatile di cui sopra era inclusa ovviamente anche la connect card di Vodafone).
Inauguro quindi il pc nuovo (pavilion dv6000), la connect card nuova (formato Express, giacchè oramai i portatili nuovi la PCMCIA non la montano più ... e finalmente Vodafone si è svegliata) e ... udite udite ... ho un Vista che gira qui sotto !
La news, almeno per me, sta nel fatto che sino a poco fa i driver del GlobeTrotter su Vista non giravano, anzi no, giravano, però no, sui pavillion no, anzi forse ...
Come si dice da me ... speremmu ;-)
Un dubbio esistenziale, che presto risolverò calcolatrice alla mano.
Il download della CTP di marzo di Orcas, che sta procedendo ad una velocità *massima* di 8Kbps , finirà prima del rilascio della CTP di Maggio ?
:-(
Martedì. Da un cliente, durante una pausa, io che smanetto dietro allo SharePoint di turno.
Mi ha colpito una frase, sulla quale rifletto ora con il solito delay dovuto all'intasamento dei miei bus di memoria (ma parla come mangi !!!): "Ma tu come mai hai scelto Microsoft ?".
Sembrerà banale, peraltro credo sia la risposta più gettonata: "per caso, ho iniziato a lavorare con tecnologia MS, ci ho fatto esperienza su, ..."
La realtà è che non ho mai scelto. Con coscienza, per lo meno.
La prima volta che ho messo mano su una tastiera avevo di fronte il prompt del DOS (credo fosse MS-DOS 3puntoqualcosa), giocavo a xunix, perfino scrivevo qualche riga di BASIC, di sicuro non mi sono mai messo a riflettere sul fatto che ci fosse qualcosa al di fuori di quello che vedevo ed utilizzavo. Vabbè, dai, avevo pure 10 o 11 anni, non si può mica pretendere.
Il primo codice "semi-serio" che ho scritto era C con TurboC++ della Borland. Sempre DOS. E intanto un amico mi aveva prestato 7 floppy con Windows 3.1. Bello ! Mica sapevo che esisteva un tale Mac ... Vabbè dai, avevo 13 anni, non si può mica pretendere più di tanto.
Il primo utilizzo "per lavoro" è stato alle superiori, liceo con specializzazione informatica. 2 ore alla settimana di Pascal. DOS (i pc della scuola erano un po' indietro rispetto a quello di casa, niente hard disc e doppio floppy da 5 pollici, sempre lì a cambiare disco). Anni 14-15, altro a cui pensare, certo non che proprio in quell'epoca qualcuno stesse realizzando Linux. Ma non si può mica pretendere, l'età difficile ...
Da grande ... lavoro vero. Quella cosa per cui vai in un posto e ti pagano (che bella definizione utopica di lavoro). Programmazione Windows. C++. MFC. ADO. Poco dopo COM. ATL. DCOM. Stranamente in quel periodo mi stavo appassionando di sistemi Open. Difficile imparare bene, a livello di studio personale e di investimento professionale, entrambe le tecnologie. Ciò che non è Microsoft è stato sempre relegato a hobby. Più nolente che volente. Ma non si può mica pretendere, dopo 10 ore a sputar sangue su una CWnd ...
Da grande++: .NET :)
Punto.
Ecco, questo sì. Qui veramente un hobby è coinciso con un'attività professionale. Così è tuttora e mi ritengo *estremamente* fortunato per questo. Ora si potrebbe pretendere, ma chi me lo fa fare, se ho tempo approfondisco la conoscenza di una piattaforma che mi ha letteralmente entusiasmato. Le ore sono 24, nonostante molti provino a farti credere il contrario :-)
Oggi. Beh. Sui prodotti Microsoft ho costruito la mia carriera fino a questo punto. Anni ne ho 28. Dirsi "senior" ... forse sì, forse no. Di certo c'è una cosa. Attualmente non mi sento di affrontare con coscienza una scelta che non ho mai fatto.
Sono stato "educato" Microsoft. Ne prendo atto.
Ora che sono abbastanza grande per valutare la correttezza della mia educazione, alla fine credo di non avere le competenze necessarie per mettere al vaglio la "concorrenza" in maniera sufficientemente profonda. E pragmaticamente accetto la mia "estrazione informatica".
Accettazione come presa di coscienza. Tutto qui. *Non* come rinuncia alla critica ;-)))))