dicembre 2007 - Posts
C'erano una volta una macchinetta del caffè, l'ottundimento-misto-caffeina delle 9 e due chiacchiere senza pretesa su argomenti semi-tecnici.
Ed ecco che come per magia una persona ci ha raccontato il suo "rapporto" con .NET.
Dicendo, più o meno, questo:
"Quando è uscito .NET mi è tornato il gusto di programmare"
E fu così che la giornata iniziò davvero sotto i migliori auspici.
Thnx :-)
Complice pure il solito malanno di stagione, sto dedicando qualche serata all'aggiornamento di un po' (!!) di materiale didattico a Visual Studio 2008, in ordine neanche troppo sparso, per una volta !
Segno qui alcune note relative ai progetti SharePoint, HTH.
Il porting della parte di codice è decisamente indolore. Almeno per ora (e me le tiro da solo).
Un po' più variegato il discorso dell'organizzazione dell'ambiente di sviluppo.
Di fatto, allo stato attuale delle cose le VS Extensions non sono utilizzabili. La maggior parte dei progetti semplicemente non si riescono a tirar dentro a meno di martellate (se avete aggiornamenti o smentite ben vengano !!).
Ci sono richieste in tal senso, si parla di fine anno almeno per qualche roadmap, probabilmente le cose cambieranno in un futuro non troppo lontano (ricordiamoci che cmq VS2008 non è ancora stato rilasciato ufficialmente).
Peraltro (ma questa è un'opinione del tutto personale) non sono un grande fan delle VSExtensions per SharePoint, almeno fino alla release 1.0 (quella ufficiale).
La versione 1.1 (che è ancora in CTP) ha un paio di aspetti estremamente interessanti (uno su tutti, la WSP View Window che consente di esplorare ed in parte modificare il contenuto delle Solution che vengono generate). Però al di là di quello mi sono sempre trovato meglio con un po' di plumbing su MSBuild, snippet, batch file e personalizzazioni dell'ambiente più mirate e soprattutto più controllabili.
Il fatto è che, in particolar modo per quanto riguarda gli aspetti di packaging e deploy in SharePoint, diversi meccanismi sono piuttosto noiosi, ripetitivi e di conseguenza per buona parte automatizzabili (se avete presente i file DDF ...). In rete, tra codeplex, documentazione, tutorial e via discorrendo, si trova un sacco di supporto, cosa che è fantastica anche se a volte l'abbondanza distrae e complica.
Una "suite" che mi sento di consigliare è quella che Scot Hillier (SharePoint MVP e autore, peraltro, di uno dei più bei libri "intro" che ho letto su SharePoint) mantiene aggiornata su CodePlex.
Il consiglio è dato dal fatto che, oltre ad essere ben strutturata e piena di valide extensioni, è disponibile nella versione per VS2005 e per VS2008 (entrambe contenute nella release del progetto).
Altra menzione per gli SmartTemplate by Jan Tielens (SharePoint MVP nonchè Mr SmartPart), li trovate sempre su CodePlex, qui. Si basano su WSPBuilder e SharePoint Solution Installer e, come potete vedere dal video (e provare sulle vostre VM !!), VS2008 è pienamente supportato :-)
E un'altra segnalazione per il porting di un PL su piattaforma CLR+DLR.
Questa volta si tratta di LUA, su cui Joel Pobar sta portando avanti il progetto NUA (qui su codeplex).
Ho letto un po' di post di Joel stasera perchè sul pc nuovo avevo caricato una lista OPML non proprio aggiornata ... tipo un anno vecchia ... mmhhh :-(
Vi consiglio ovviamente di sottoscrivervi al feed. E di dare una letta alle sue "Most Excellent Software Adventures".
Ho terminato da qualche ora un corso (.NET e dintorni) che mi ha lasciato un po' di spunti su cui riflettere. Iin realtà è così per la maggior parte dei corsi, solo che stavolta sfrutto l'immediatezza e butto giù due random notes.
Le scrivo come mi vengono in mente.
Le domande, quante domande.
Brutta bestia da domare, le domande. D'altra parte, sono un componente fondamentale dell'interazione con le persone e un contributo non indifferente alla didattica, giacchè aiutano a tarare il programma in via di svolgimento (sempre che questo non sia o non debba essere marchiato a fuoco). Penso che una delle cose più difficili del lavoro del docente sia "discernere" (appunto !!) e mantenere la linea conduttrice senza rigidità nè escursioni eccessive. Facile a dirsi ...
Il percorso didattico vs "Come lo uso per il mio programma".
Vedi sopra, come sopra. Qui il contesto assume un ruolo non marginale, dal momento che un corso "in aula" non ha le stesse premesse di un corso "on site" ... almeno non necessariamente. C'è una frase che ho sempre odiato e odio tuttora, che recita "in medio stat virtus". Qui l'ago della bilancia tira un po' da tutte e due le parti, anche perchè (1) un corso viene richiesto e pagato, di conseguenza è giusto vederlo come un servizio e la flessibilità è un valore aggiunto, però (2) un corso viene acquistato sulla base di una certa proposta ed ogni divergenza è, appunto, un di più non previsto.
Se ne imparano sempre di nuove
Questo mi piace un sacco, tutte le volte. Il bello dei corsi di formazione (uno degli aspetti che mi piacciono di più, per lo meno) è la possibilità di incontrare realtà diverse, che hanno esigenze diverse e, ovviamente, competenze diverse, magari verticali, magari su prodotti che conosci solo per confronto. Java alla fine lo sto imparando così ! Questi giorni in alcuni momenti è stata la volta di Apache ... il mondo è bello perchè è vario :-)
Embè ?
Tiro una linea e faccio la somma. Il mio pensiero di oggi è: W il training on the job, ma senza scordarsi della parte "training" della locuzione. Insomma, un training on the job che non penda da nessuna delle due parti, organizzato per benino: training iniziale slegato dal lavoro + applicazione pratica con spiegazioni mirate + raccolta quesiti dall'impiego delle nozioni + sessione di riassunto teorico finale + ...
... + qualsiasi cosa, di fatto, perchè si può anche stare a discutere della forma (l'ho appena fatto) ma il fatto di discuterne vuol dire che formazione si sta facendo.
Il che (purtroppo) non è scontato per nulla.
Perdonate l'uso del tutto personale e privato di questo post, ma non posso non fare gli auguri al mio fratellino che compie oggi 27 anni.
Z, ma quanto sei vecchio !!! (me la godo finchè dura giacchè l'anno prossimo per me sono 30 e so che mi romperai le scatole almeno fino ai 31).
Intanto mi sto prendendo 1 ora di pausa prima di pranzo.
Tempo di configurare un paio di impostazioni sul portatile nuovo.
Una ad esempio: la posta.
Sto scaricando in locale circa 1 anno di email. Outlook mi dice che sono 6779 messaggi per un totale di 216 Mb.
La cosa curiosa è che sono qui come un pesce a guardare la Inbox che si riempie lentamente e ad osservare, di conseguenza, quello che mi è successo raccontato da ciascuno di quei seimilasettecentosettantanove messaggi.
Scambi di posta elettronica con persone con le quali, per una via o per l'altra, i contatti sono stati tagliati (uso l'impersonale che è più conservativo).
Clienti con cui si sono conclusi i lavori e di conseguenza la stretta corrispondenza.
Opportunità mai sfociate nel concreto.
Molte attività attuali nate magari solo da una email di "richiesta info".
Qualche email a cui non ho risposto e la trovo lì a mesi di distanza: avrà senso ora scrivere a qualcuno che chiede "come mai mi si verifica questa exception" dicendo "scusa il ritardo" ??
Uso la posta elettronica principalmente come strumento di lavoro, ma non vuol dire che manchino le email personali ... e la inbox si riempie impietosamente anche di quelle, con frasi o punti di vista che sono stati ma magari non sono più i miei.
Beh insomma ... una curiosa retrospettiva sul mio ultimo anno :-P
Marco segnala in questo post l'apertura di uno spazio sul portale MSDN dedicato al parallel computing.
Leggendo al volo la home mi ha colpito un termine: ManyCore Shift.
Che di per sè non ha nulla di particolare come nome, se non la somiglianza con Manticore. Con la T in mezzo.
Le cose, come vedremo, si riuniscono in un punto comune (l'argomento, che è gestione della concorrenza) divergendo però in partenza in maniera netta, a partire proprio dall'etimologia del nome.
Manycore: Many = Molti, Core = ... core :-)
Manticore ha invece un'origine ben più antica: il manticore è una creatura dal corpo di leone e dalla testa d'uomo, ferocissima e leggendariamente abitante le foreste dell'Asia (al solito, WikiPedia). Eccone una rappresentazione:
Cosa c'entra con il parallel computing ?
Nulla, al di là del fatto che Manticore è il nome scelto per un progetto (portato avanti dall'università di Chicago) volto alla definizione di un linguaggio di programmazione.
Nuovo membro della numerosa famiglia discendente da ML, Manticore propone la concorrenza come requisito chiave per lo sviluppo di sistemi in grado di sfruttare le nuove architetture hardware.
Non è questa la sua pecualirità (giacchè l'obiettivo sembra condiviso da più parti), quanto il fatto che il supporto alla concorrenza sia fornito a diversi livelli di astrazione.
Si va da un supporto "gratuito" da parte del runtime (che genera codice intrinsecamente eseguibile-eseguito su thread differenti) all'esposizione di keyword e costrutti sintattici capaci di influenzare questi comportamenti (compiler hints).
Di più, viene fornito un meccanismo di gestione esplicita dei thread basato su message passing.
[Message Passing. Merita discorso a parte. In 2 parole, la comunicazione di dati fra thread avviene senza condivisione di stato (shared data) al fine di eliminare la necessità di lock mantenendo, tuttavia, l'integrità delle informazioni (n.b.: lock = il peggior nemico della scalabilità sui multicore)]
Alcuni punti di contatto con ParallelFX, di fatto, emergono.
Partendo dagli "hint" al compilatore ed al runtime (Parallel.For, AsParallel di PLINQ...).
Ed arrivando alla gestione esplicita dei thread con un approccio più funzionale possibile. Cosa evidentemente naturale in linguaggi ML-based, e direzione attuale nell'evoluzione di un linguaggio imperativo come C#.
Insomma, il fermento è parecchio.
Da un lato i linguaggi e le piattaforme "mainstream" devono evolversi per non avere di fronte un limite di scalabilità insormontabile.
Però dall'altra parte linguaggi ed approcci "di nicchia" devono trovare il modo per offrire il supporto e l'utilizzabilità che, di fatto, credo ancora non abbiano.
Interessante è, però, notare come proveniendo da lati diametralmente opposti si giunga a punti di incontro.
Rimanendo nel mondo .NET, secondo me un punto chiave sarà l'influenza che F# potrà avere sull'architettura interna del runtime. In altri termini, staremo a vedere che succede quando (e se) quelle che sono, attualmente, feature del linguaggio saranno integrate a livello di VM.