Astrazione

Oggi piacevolissima passeggiata in montagna. La costiera in tutta la sua insostituibile e materiale bellezza.

Nel discorrere con gli amici si è toccata la medioevale disputa sugli universali.
A pensarci bene tutte le volte che pensiamo alle architetture, al design,... dobbiamo fare i conti con l'astrazione. Al di là di ogni precisa definizione che si può leggere, volendo porre una definizione radicale che colga tutti gli aspetti, trovo molto soddisfacente definire l'astrazione come quella facoltà originaria della mente che permette di ricavare dalle cose materiali conosciute attraverso i sensi (e che di per sé sono tutte individuali) gli aspetti universali che sono alla base del funzionamento della ragione.

Immediatamente ho coniugato questo a buona parte del mio lavoro e con molta soddisfazione!

Pubblicazioni

Sto iniziando a convertire in formato PDF gli articoli e le review che ho scritto (poche cose... ma non ho gettato la spugna!)
Per ora sono presenti qui. A fianco trovate anche il reference con rispettiva icona.
Ho riletto con divertimento "Controllo semantico sui metodi". Praticamente non ha più nessun valore. La soluzione proposta non funziona più! (nella description del file ho inserito il perché).

Restano ancora da caricarne altri tre, pubblicati su Computer Programming:

• Dependency Inversion Principle, n. 138, 2004
• Oggetti Immutabili, n.139, 2004
• Resource Sharing, n.141, 2004

Please rate them!

Brooks on Design!

Ho ascoltato con vivo interesse un intervento di Fred Brooks all'università del North Carolina.
Non tutto condivisibile ma prezioso e divertente.
Potete scaricare il file da qui.

Ho notato con piacere che Fred Brooks attribuisce al designer (al great designer) un ruolo attivo e non un mero scrivano (vedi precedente post)
Il designer deve saper cogliere cosa costruire (dando per scontato che poi sappia anche il come) e quindi aiutare il cliente a capire ciò di cui necessita.

Buon ascolto.

Framework

Due mesi spesi insieme al team a lavorare ad un progetto vincolato tecnologicamente (e commercialmente) ad un framework roboante, farraginoso e pretestuoso. Non intendo rivelarne il nome anche perché i suoi limiti sono comuni a quelli di molti altri framework (ma se non provvederanno a riscriverlo ne sentirete presto parlare come di un clamoroso flop).
I limiti dunque. Lasciando da parte le scelte architetturali (comprese tra l'altro molto tempo dopo) e concentriamoci sulla documentazione. Questa per un buon 80% è fatta a "libreria", ovvero in maniera descrittiva sono riportati tutti i metodi con relativa short description. Serve a ben poco perché ad istinto i developer provavano a piegare le funzionalità del framework dentro al loro framework mentale, quello cioè a cui sono abituati a lavorare. Nessuna indicazione sulle scelte architetturali, di come affrontare problemi ricorrenti che il framework dovrebbe risolvere in maniera più semplice (altrimenti a che serve). Niente. Nada.
Solo una accozzaglia di metodi da richiamare con una serie di dipendenze non documentate e fonte di frustrazioni per l'intero team.
Per il caso particolare, da buoni informatici ci auguriamo l'estinzione (o una buona ristrutturazione, ma da mani diverse...:-)) perché non è solo una questione documentale ma questa quando è fatta con i piedi è indice che sotto sotto c'è qualcos'altro, e infatti...
Non è una ripicca, ne vale il tempo di altri colleghi.