Una brevissima introduzione: CouchDB è un database documentale, ogni documento (il record di una tabella in un database relazionale) è insieme di coppie chiave/valore, non esiste uno schema dei dati, ogni documento può contenere qualsiasi insieme di coppie chiave/valore, ad ogni database possono essere associati una o più view (query in un database relazione), ogni view è composta da due funzioni javascript, una funzione map che consente di trasformare ogni documento contenuto nel database in un altro insieme di coppie chiave/valore e di associarle ad una chiave, e una funzione reduce (opzionale) che prende in pasto l’output della funzione map precedente raggruppata per chiave (una sorta di group by dei database relazionali) e che può essere utilizzata per computare valori aggregati

Un piccolissimo esempio che è molto vicino al test che ho fatto. Supponiamo di avere un database (ovvero un insieme di documenti) di questo tipo

[
{
"url": "http://salute.corriere.it/news/some-news.html",
"visits": 3
},
{
"url": "http://lavoro.corriere.it/index.html",
"visits": 10
}
]

Ovvero associamo ad ogni url il numero di volte che è stata visitata. Noi vogliamo sapere il numero di visite per ogni “sezione” delle url presenti nel nostro database. Definiamo intuitivamente il significato di “sezione” dicendo che l’url “http://salute.corriere.it/news/some-news.html” appartiene a tre sezioni “corriere.it”, “salute.corriere.it” e “salute.corriere.it/news”. Supponiamo di avere a disposizione una funzione “forEachSectionOf(url,doSomething)” che prede in pasto una url e richiama la funzione doSomething per ogni sezione dell’url passandogli la sezione stessa come parametro. La nostra funzione map sarebbe una cosa del tipo

function(doc) {
forEachSectionOf(doc['url'], function(section) {
emit(section, doc['visits'])
});
}

La funzione emit viene chiamata tutte le volte che vi vuole produrre un output, il primo parametro è la chiave del risultato e il secondo è il valore (sia la chiave che il valore possono essere strutture dati complesse, non devono essere per forza valori come in questo caso, ma questa è un’altra storia). L’output prodotto dalla map applicata al database di cui sopra sarà

[
{ "corriere.it": 3 },
{ "salute.corriere.it": 3 },
{ "salute.corriere.it/news": 3 },
{ "corriere.it": 10 },
{ "lavoro.corriere.it": 10 }
]

Abbiamo detto che l’imput alla reduce è l’output della map raggruppato per chiave, quindi

[
{ "corriere.it": [ 3, 10 ] },
{ “salute.corriere.it”: [ 3 ] },
{ “salute.corriere.it/news”: [ 3 ] },
{ “lavoro.corriere.it”: [ 10 ] }
]

Ricordandoci che vogliamo calcolare il numero di visite per ogni sezione, la reduce è molto semplice

function(keys, values, rereduce) {
return sum(values)
}

Che produce il risultato atteso

[
{ "corriere.it": 13 },
{ "salute.corriere.it": 3 },
{ "salute.corriere.it/news": 3 },
{ "lavoro.corriere.it": 10 }
]

Il grosso vantaggio di CouchDB in termini di perfomance è che le view vengono calcolate in maniera incrementale, ovvero tutte le volte che interroghi una view CouchDB ricalcola solo i valori relativi ai documenti che sono cambiati o che sono stati aggiunti dall’ultima volta che la stessa view era stata calcolata (la cosa più vicina a questa nel mondo dei database relazionali sono le materialized view di Oracle). Inoltre il costo del calcolo dell’incremento dovrebbe aumentare in maniera logaritmica rispetto all’aumentare della dimensione del database.

Ho voluto toccare con mano e quindi ho fatto il seguente esperimento:

• Fetch di 10000 record da una tabella di mysql contenente 15 milioni di record
• Store di ogni record come documento in CouchDB (i documenti non sono stati salvati singolarmente, ma in modalità batch che è molto più performante)
• Query della view di CouchDB che equivale al ricalcolo della view stessa

Ho misurato ognuna delle tre fasi e l’ho ripetuto fino a consumare tutti e 15 i milioni di record, di seguito i risultati

• Pro: la complessità del ricalcolo della view è effettivamente logaritmico
• Pro: il costo d’inserimento dei documenti in CouchDB è costante (la struttura dati utilizzata è append-only, quindi c’era da aspettarselo, ma fa comunque piacere verificarlo)
• Pro: una volta calcolata la view, i tempi di risposta sono stupefacenti, praticamente istantanei
• Pro: il tempo totale d’inserimento di 15 milioni di documenti è stato di 26 minuti
• Pro: l’occupazione di memoria durante tutto il processo non ha mai superato i 50MB
• Contro: il tempo totale di calcolo della view è stato di circa 17 ore. Bisogna tener conto che le view vengono calcolate da funzioni javascript in un processo separato e che la comunicazione fra CouchDB e l’interprete javascript è stdin/stdout, quindi a parte la velocità dell’interprete javascript (di default spidermonkey) c’è anche un costo notevole di serializzazione/deserializzazione. Scommetto che scrivendo le map/reduce direttamente in Erlang questo numero cambierebbe sensibilmente
• Contro: lo spazio occupato dal database è di 21GB contro i 7.5GB di mysql (anche se ci metterei un bel chissene visto il costo degli storage)
• Contro: lo spazio occupato dalla view è di 32GB (again chissene)
• Contro: per ogni database CouchDB usa uno ed un solo processore, quindi anche se avete 16 processori come nel mio caso, non ve ne fate niente a meno di non avere database multipli. Il modello map/reduce implementato da CouchDB potrebbe tranquillamente consentire il partizionamento dei dati su più database, ma attualmente gli sviluppatori si stanno concentrando solamente sulla replicazione, se volete dovete implementare voi il meccanismo di reduce finale

Conclusione: se vi trovate in una situazione per cui avete una grande quantità di dati e le query che fate non cambiano spesso, un database come CouchDB potrebbe essere un bel passo in avanti rispetto ad un database tradizionale

Joel ha elogiato Jamie Zawinski (uno dei programmatori intervistati da Seibel nel suo libro) per la sua capacità di scrivere velocemente codice funzionante e fruibile da un utente finale. Joel ha chiamato questo tipo di programmatore “Duct Tape Programmer”, un’etichetta che ha suscitato un bel polverone.

Insomma si parla del solito tradeoff “time, quality, money – pick two”, che poi ufficialmente si traduce sempre in “scegliamo tempo e denaro, per la qualità speriamo di farla franca”.

Cosa centra tutto questo con i kata? Quando qualcuno si lamenta del fatto che le tecniche che propongo non sono praticabili nella loro realtà perchè non c’è il tempo (la solita storia del “bello, ma da noi non si può fare”), mi ricordo quando anch’io mi lamentavo della stessa cosa, vedevo la carenza di tempo come la prima ragione di tutti i miei fallimenti, poi però ho iniziato a chiedermi: “se fino ad oggi non ho mai avuto tempo per fare le cose bene, come faccio ad essere sicuro di saperle fare? Come faccio ad essere sicuro di riuscire a scrivere codice pulito se non ho mai avuto il tempo di scriverlo?”… Interessante quesito che ci porta ai kata e alla nozione generale di esercizio

Gli esercizi di programmazione hanno due obiettivi

• Darci la possibilità di lavorare in un ambiente controllato e privo di vincoli. Il fallimento è visto in maniera positiva, venire a conoscenza dei nostri limiti è l’unico modo per poterli superare
• Visto che non avrete mai il tempo che volete, l’unica cosa che potete fare è diventare più veloci nello scrivere codice di qualità

Il secondo punto ci riporta al tema iniziale: dove sta scritto che per scrivere del buon codice serve tanto tempo? Io sono fermamente convinto che l’unica ragione per la quale intuitivamente lo pensiamo è perchè quando ci proviamo facciamo fatica, e l’unica ragione per la quale facciamo fatica è perchè non siamo abituati/allenati.

Ultimamente ho dedicato un po’ di tempo a pensare ai kata e ad esercitarmi, venerdì della settimana scorsa ho partecipato al primo javascript camp italiano organizzato da Ideato e ho presentato il kata “the game of life” in javascript, è stato molto divertente ed istruttivo

Gli ingredienti per un buon kata/esercizio sono

• Un problema sfidante per le vostre capacità e per la vostra preparazione
• Una o più persone pronte a darvi il loro feedback, fondamentale per capire come e dove migliorarsi
• Ripetere l’esercizio più e più volte finchè sentite che ormai il problema non ha più niente da insegnarvi

Il mio consiglio è di provare e di mettervi in gioco, per quanto mi riguarda le prossime mosse saranno: pubblicare gli screencast dei miei kata ed organizzare dei gruppi di esercizio/studio, se siete interessati contattatemi o iscrivetevi milano-codingdojo (non preoccupatevi se non siete di Milano, stiamo organizzandoci per fare qualcosa di distribuito ;-))

L’argomentazione utilizzata per minimizzare l’utilità dei test è la semplicità dell’esercizio, al che ho pensato a come l’avrei risolto in Erlang, mi sono detto che “effettivamente la soluzione è semplice”, ho iniziato a scriverla provandola nella shell del linguaggio e subito ho provato un senso di fastidio

Continuavo a scrivere e riscrivere (va bhe, la shell ti da la possibilità di richiamare i comandi passati, ma il discorso non cambia) le stesse invocazioni verificando ad occhio il risultato, al che ho capito il senso di fastidio: che differenza c’è fra quello che stavo facendo e scrivere dei test unitari? Nessuna, tranne che i primi sono effimeri e non ti possono venire in aiuto quando sarai chiamato a fare refactoring. Quindi, amici dei linguaggi funzionali, perchè non vedete i test unitari come delle sessioni di interazione con la shell permanenti e automatiche?

Vi dirò di più, la soluzione che avevo inizialmente pensato era sbagliata :-) Dopo aver passato tutti i test che Martin aveva fatto nella presentazione di cui sopra, mi sono chiesto se potevo rompere il codice in qualche modo, ho visto che non erano coperti dei corner case, per esempio c’è la partita peggiore (tutti 0), ma non c’è la partita migliore (tutti strike), scrivo un test… e non passa :-)

Come vedete qui sotto, utilizzo una variabile per tenere il conto dei frame elaborati, inizialmente non lo facevo e nel caso di uno strike nell’ultimo frame, i due tiri di bonus successivi metchavano con la terza clausola e venivano considerati dei frame normali, quindi il “perfect game” che dovrebbe avere uno score di 300 aveva score 320

Alla fine ho guardato il codice e quella variabile arbitraria per contare il numero dei frame proprio non mi andava giù e senza cambiare i test sono arrivato a questa seconda soluzione

Che non mi piace perchè anche se rende più esplicito (forse anche più imperativo?) il conto dei frame, secondo me si capisce di meno, sopratutto non mi piace score_frame perchè si occupa sia di calcolare lo score di un frame (e fin qui), sia di selezionare i tiri rimanenti eliminando quelli del frame corrente

Cosa ne dite? Quale vi piace di più?

I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone. [...] Consistency and predictability are still desirable, but they haven’t ever been the most important things. For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business. [...] Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been.

Estratto da l’ultimo articolo di Tom DeMarco. Consideriamo anche che DeMarco non è proprio uno di quei “giovani rivoluzionari delle metodologie Agili che non hanno ancora capito niente e che vogliono reinventare la ruota”, è uno dei padri fondatori che si è sparato un po’ tutte le ere geologiche dell’informatica. Il problema è che di solito passa qualche lustro prima che il pensiero degli illuminati diventi di comune dominio… speriamo di esserci quando avverrà :-)

Durante la giornata ho incontrato dei ragazzi di Trieste che mi hanno chiesto qualche consiglio su come iniziare ad introdurre le metodologie Agili nella propria azienda, per le due chiacchiere che abbiamo fatto posso dire che sono sulla strada buona, il fatto stesso che economicamente se la stanno passando bene, che non soffrono più di tanto (la sofferenza è uno dei motori principali del cambiamento) e che nonostante questo abbiano tanta voglia di migliorare, gli fa veramente onore, in bocca al lupo ragazzi!

Nota mentale: Milano capitale dell’IT in Italia… io direi più Milano capitale della consulenza in Italia, incontro sempre più persone che sviluppano prodotti, anche leader di mercato (come i ragazzi di Trieste), che non hanno niente a che fare con Milano

Il giudizio generale sulla conferenza è molto buono sopratutto se consideriamo che: è al suo primo anno e che è stata organizzata gratuitamente dalle community locali in collaborazione con l’università. Nonostante il classico antipattern delle conferenze gratuite (generalmente si presentano molte meno persone rispetto a quelle che si iscrivono), il numerico presente era buono (un centinaio?), gli interventi erano tutti di ottimo livello, unica nota negativa della giornata è stata l’assenza di studenti in una conferenza universitaria… no comment…

Racconto brevemente la storia della presentazione qui sotto: un paio di mesi fa Marco Abis mi chiama e mi chiede se voglio parlare ad una coferenza rappresentando l’Italian Agile Movement, io: “certo perchè no”, vado a vedere di cosa tratta la conferenza… RIA (Ritch Internet Applications), bene, io e Federico stiamo sviluppando proprio quello, chiedo a Federico di scrivere la descrizione (scrive meglio di me), la pubblichiamo, al che però Marco sottolinea il fatto che, come rappresentanza delle metodologie Agili dobbiamo trattare quei temi… ooops, la descrizione era già stata scritta…

Pensandoci sopra poi ho capito che in realtà le tecnologie che abbiamo scelto io e Federico (tecnologie che erano l’oggetto della presentazione che volevamo fare) servivano per sostenere il processo produttivo che avevamo in mente, un processo produttivo fortemente iterativo, incrementale ed adattivo, capace di sopravvivere in un contesto di estrema incertezza come quello di una startup. La conclusione è che non è vero che le tecnologie che scegliamo prescindono dalla metodologia di sviluppo, e non vero che la metodologia che scegliamo prescinde dall’ambiente dal progetto e dal suo ambiente. L’unico modo per ottenere il Total Flow, ovvero l’eliminazione di tutti gli sprechi, è necessario considerare tutti questi aspetti nella loro globalità

I talk m’interessano relativamente, è raro assistere ad un talk che parla di un’argomento di mio interesse all’interno del quale si dicano cose che non ho già letto e/o sentito, chiaramente questo non dipende dalla preparazione dell’oratore ma dal fatto che non può dar per scontato che tutti i presenti conoscano già determinati argomenti. Alcuni tipi di talk però fanno eccezione, per esempio gli experience report mi piacciono molto

Giovedì 07/05/2009, la giornata inizia subito bene, parto con il treno delle 6:30 da Milano con l’iphone pieno di conferenze (quale cosa migliore di andare ad una conferenza guardandosi altre conferenze), direzione: Firenze, scopo: partecipare a bettersoftware. Arrivati a Firenze sto per scendere dal treno e becco Simone Genini, grazie al suo aiuto riesco a raggiungere appena in tempo l’albergo della conferenza (io ho una capacità di perdermi incredibile, talmente incredibile che neanche iphone + google maps mi salvano)

Primo talk (mannaggia a chi ha deciso di far iniziare la conferenza così presto) è stato quello di Antonio Cangiano sul mondo delle startup, lui stesso ne sta facendo partire una e ha condiviso con la platea i suoi pensieri. Sabato (durante pycon3) ho avuto modo di parlare con Antonio, è una persona molto simpatica e socievole, mi ha spiegato le idee che stanno alla base di thinkcode (la sua startup) e devo dire che sarò sicuramente uno dei loro primi clienti (se siete appassionati di programmazione vi consiglio di iscrivervi alla loro ml, se non siete appassionati di programmazione avete sbagliato blog :-))

La giornata è proseguita con i talk di Matteo Vaccari, Francesco Cirillo e Simone Casciaroli (Simone perchè non hai un blog?), tre experience report degni di nota.

Scena madre della giornata: Francesco Cirillo sale sul palco e attacca con la campagna anti-if, dice che ha delle magliette da regalare, ma le regalerà solo a chi dirà qualcosa in grado di colpirlo, al che Jacopo Romei che era seduto di fianco a me si alza e urla “Sei Bellissimoooo!!!”, scoppiano tutti a ridere e lui si becca la maglietta, grande Jacopo, uno ottimo esempio di pensiero creativo :-)

Mi piacerebbe raccontare di più su questo fantastico linguaggio/ambiente, è che mi manca proprio il tempo…

Come al solito gli argomenti sono un po’ borderline, speriamo bene :-)

legenda

• * significa comprato e letto (in tutto 58)
• + significa comprato e da leggere (in tutto 6)
• - significa non comprato e non letto (in tutto 36)

* Steve McConnell Code Complete: A Practical Handbook of Software Construction (2nd Edition)
+ Elisabeth Freeman, etc. Head First Design Patterns
* Steve McConnell Rapid Development
* Erich Gamma Design Patterns: Elements of Reusable Object-Oriented Software
- Bruce Schneier Applied Cryptography: Protocols, Algorithms, and Source Code (2nd Edition)
* Robert C. Martin Agile Software Development: Principles, Patterns and Practices
* Joel Spolsky Joel on Software
* Tom DeMarco, Timothy Lister Peopleware: Productive Projects and Teams (2nd Edition)
* Frederick P. Brooks The Mythical Man-Month, Anniversary Edition (2nd Edition)
* Martin Fowler Refactoring: Improving the Design of Existing Code
* Mike Cohn Agile Estimating and Planning
* Alistair Cockburn Writing Effective Use Cases
* Bertrand Meyer Object-Oriented Software Construction (2nd Edition)
+ Steve McConnell Software Estimation: Demystifying the Black Art
* Mike Cohn User Stories Applied: For Agile Software Development
- Donald E. Knuth The Art of Computer Programming, Volumes 1-3 Boxed Set (2nd Edition)
* Martin Fowler Patterns of Enterprise Application Architecture
* Jeffrey Friedl Mastering Regular Expressions
* Andrew Hunt, David Thomas The Pragmatic Programmer: From Journeyman to Master
- Karl E. Wiegers Software Requirements (2nd Edition)
* Craig Larman Applying UML and Patterns (3rd Edition)
* Alistair Cockburn Agile Software Development: The Cooperative Game (2nd Edition)
- Gary McGraw Software Security: Building Security In
* Gregor Hohpe, Bobby Woolf Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
* Tom DeMarco The Deadline: A Novel About Project Management
* Craig Larman Agile and Iterative Development: A Manager’s Guide
- Eric A. Marks, Michael Bell Service-Oriented Architecture: A Planning and Implementation Guide for Business and Technology
* Thomas H. Cormen, etc. Introduction to Algorithms, Second Edition
- Thomas Erl Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services
* Martin Fowler UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition)
* Kent Beck Extreme Programming Explained: Embrace Change (2nd Edition)
+ Alan Shalloway, James Trott Design Patterns Explained: A New Perspective on Object-Oriented Design (2nd Edition)
+ Grady Booch, etc. Object-Oriented Analysis and Design with Applications (3rd Edition)
* Jim Highsmith Agile Project Management: Creating Innovative Products
* Scott Berkun Making Things Happen: Mastering Project Management
* Jon Bentley Programming Pearls (2nd Edition)
* Paul Duvall, etc. Continuous Integration: Improving Software Quality and Reducing Risk
- Andrew Stellman, Jennifer Greene Applied Software Project Management
- Clemens Szyperski Component Software: Beyond Object-Oriented Programming
- Arthur J. Riel Object-Oriented Design Heuristics
- Thomas Erl SOA Principles of Service Design
* Mary Poppendieck, Tom Poppendieck Lean Software Development: An Agile Toolkit
* Ken Schwaber Agile Project Management with Scrum
* Ken Schwaber, Mike Beedle Agile Software Development with Scrum
* Joshua Kerievsky Refactoring to Patterns
* Alistair Cockburn Crystal Clear: A Human-Powered Methodology for Small Teams
- Steve McConnell Software Project Survival Guide
* Tom DeMarco, Timothy Lister Waltzing With Bears: Managing Risk on Software Projects
* Venkat Subramaniam, Andy Hunt Practices of an Agile Developer: Working in the Real World
- Kathy Schwalbe Information Technology Project Management
- Randall Hyde Write Great Code: Volume 1: Understanding the Machine
* Scott Rosenberg Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
* Cem Kaner, etc. Lessons Learned in Software Testing
* Andy Oram, Greg Wilson Beautiful Code: Leading Programmers Explain How They Think
- Luke Hohmann Beyond Software Architecture: Creating and Sustaining Winning Solutions
- Grady Booch Unified Modeling Language User Guide, The (2nd Edition)
* Karl Fogel Producing Open Source Software: How to Run a Successful Free Software Project
* Michael Feathers Working Effectively with Legacy Code
* Kent Beck Test Driven Development: By Example
- Per Kroll, Philippe Kruchten The Rational Unified Process Made Easy: A Practitioner’s Guide to the RUP
- Thomas Erl Service-Oriented Architecture: Concepts, Technology, and Design
* Cem Kaner, etc. Testing Computer Software (2nd Edition)
- Frank Buschmann, etc. Pattern-Oriented Software Architecture Volume 1: A System of Patterns
* Harold Abelson, Gerald Jay Sussman Structure and Interpretation of Computer Programs – 2nd Edition
- Dan Pilone UML 2.0 in a Nutshell
- Brett D. McLaughlin, etc. Head First Object-Oriented Analysis and Design
* Johanna Rothman Manage It!: Your Guide to Modern, Pragmatic Project Management
* James Shore, Shane Warden The Art of Agile Development
- Brian W. Kernighan, Rob Pike The Practice of Programming
* Ron Jeffries, etc. Extreme Programming Installed
* Scott W. Ambler, Pramodkumar J. Sadalage Refactoring Databases: Evolutionary Database Design
* Jared Richardson, William Gwaltney Ship it! A Practical Guide to Successful Software Projects
- Greg Hoglund, Gary McGraw Exploiting Software: How to Break Code
* Michael Nygard Release It!: Design and Deploy Production-Ready Software
* Edward Yourdon Death March (2nd Edition)
* Stephen P. Berczuk, etc. Software Configuration Management Patterns: Effective Teamwork, Practical Integration
- Elfriede Dustin, etc. Automated Software Testing: Introduction, Management, and Performance
- Donald C. Gause, Gerald M. Weinberg Exploring Requirements: Quality Before Design
- Tom Gilb Competitive Engineering
- David J. Agans Debugging
- Eldad Eilam Reversing: Secrets of Reverse Engineering
* Robert L. Glass Facts and Fallacies of Software Engineering
- Martin Fowler Analysis Patterns: Reusable Object Models
+ Matt Weisfeld The Object-Oriented Thought Process (2nd Edition)
* John M. Vlissides Pattern Hatching: Design Patterns Applied
* Johanna Rothman Behind Closed Doors: Secrets of Great Management
- Robert K. Wysocki Effective Project Management: Traditional, Adaptive, Extreme
+ Ellen Gottesdiener Requirements by Collaboration: Workshops for Defining Needs
* Eric Evans Domain-Driven Design: Tackling Complexity in the Heart of Software
- Nick Rozanski, Eóin Woods Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives
- Peter Rob, Carlos Coronel Database Systems: Design, Implementation, and Management (8th Edition)
- Robert Orfali, etc. Client/Server Survival Guide (3rd Edition)
- Douglas Schmidt, etc. Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects
- Michael Lopp Managing Humans: Biting and Humorous Tales of a Software Engineering Manager
* Paul Graham Hackers and Painters: Big Ideas from the Computer Age
- Philippe Kruchten The Rational Unified Process: An Introduction (3rd Edition)
* Joel Spolsky The Best Software Writing I: Selected and Introduced by Joel Spolsky
* James O. Coplien, Neil B. Harrison Organizational Patterns of Agile Software Development
* Esther Derby, etc. Agile Retrospectives: Making Good Teams Great
- Henry S. Warren Hacker’s Delight

In retrospettiva

• Non esiste la categoria non acquistati ma letti, il che fa trasparire il mio feticismo nei confronti dei libri
• Compro più libri di quanti non ne riesca effettivamente a leggere, male, dovrei limitarmi, subisco uno strano effetto: il solo atto di comprare libri mi fa sentire meno ignorante, un po’ come quando vai ad iscriverti in palestra e fai subito l’abbonamento di 6 mesi perchè tanto questa volta fai sul serio ;-P
• “Structure and Interpretation of Computer Programs” 64° è un delito, probabilmente nella mia classifica personale, ora come ora, occupa il primo posto
• Mi dispiaccio un po’ per non aver letto “The Practice of Programming” (fa parte della storia dell’informatica), “Exploring Requirements: Quality Before Design” (tutto cio che ha scritto Gerald M. Weinberg dovrebbe essere letto) e “Analysis Patterns: Reusable Object Models” (non so, non l’ho comprato all’epoca, poi ho sempre sentito Fowler stesso dichiararlo come “datato”, ciò non toglie che a pelle mi sa che mi sono perso qualcosa)
• Un po’ di roba l’ho letta, qualcosa me la ricordo anche, come mai mi sento sempre così ignorante?

Per finire, ecco le prove, per lo meno del possesso ;-)

P.S. Non avevo notato la preoccupante imbarcatura della libreria che tra l’altro sta sopra la mia testa in questo momento… 8-O

If people come for money, they will leave for money

We don’t pay you to work here, we pay you so you can work here