Extreme Enthusiasm

Quest’estate a Varese organizzeremo una Scuola Estiva sui Metodi Agili (di
cui Extreme Programming è uno dei primi e più diffusi). L’argomento è per me
appassionante: gli agilisti hanno rivoluzionato la maniera di sviluppare. O
per lo meno, hanno spiegato e sistematizzato una serie di pratiche che i
migliori programmatori almeno in parte conoscevano. Però il fatto di
sistematizzare e spiegare ed organizzare i principi, valori e le pratiche
(Beck) produce un risultato che è molto, ma molto più della somma delle parti.

Il seminario che terrò l’undici aprile introdurrà l’argomento; ma alla
scuola interverranno docenti che la sanno molto più lunga di me. Tutti i
dettagli sono su http://essap.dicom.uninsubria.it/. La pagina è in inglese, come d’altronde sarà la scuola.

Spero che ci siano iscritti dell’Insubria e da altre Università italiane ed europee; sarebbe così anche una maniera per stringere contatti e conoscenze e, speriamo, amicizie.

]]>

“Source” si pronuncia “sòrs”, come “force”

“Header” si pronuncia “heder”, come “head”

“talk” si pronuncia “tòk”: la “l” non si sente, la “o” è come in “force”.
Stesso per “walk”, che si prouncia “uòk”.

Questa presumo interessi solo gli appassionati di giochi di ruolo: “sword”
si pronuncia “sòrd”, come “force” e come “source”. La “w” non si sente.

:-)

]]>

Leggi ad personam, riforma Moratti, epurazione dei giornalisti, bavaglio alla satira, condoni edilizi e fiscali, debito pubblico al 110% del PIL, riforma elettorale, “devolution”, ponte sullo stretto, tagli alla ricerca… Credo che a pensarci non si riesca a finire di elencare i disastri. Ha ragione Sartori (Corriere di oggi); anche se Prodirutellifassino non mi convincono, vale lo stesso la pena di punire chi ha tanto sfasciato. Voterò centrosinistra.

E avranno ragione di prendermi in giro gli amici che sanno come ho votato la volta scorsa. Avevate ragione, e io avevo torto.

]]>

L’ 11 aprile alle 16:00, terrò un seminario su “Introduzione a Extreme Programming” per gli studenti dell’Università dell’Insubria.

Per chi: studenti della specialistica e della triennale. Per chiunque sia interessato.

Sommario: parleremo delle pratiche di XP, e dei principi e dei valori
da cui discendono. Introdurremo il planning game e il test-driven
development, che sono due fra le più rappresentative delle pratiche
della Programmazione Estrema; vedremo che l’efficacia delle pratiche è
maggiore quando vengono applicate insieme, perché si supportano l’una
con l’altra. Accenneremo al fatto XP non è un processo codificato
nella pietra, ma che le pratiche possono essere modificate e adattate
in risposta alle diverse situazioni; in questo ci vengono in aiuto i
principi e i valori di XP.

Webografia: www.extremeprogramming.org

]]>

Tim Case scrive:

… I’m happy to report that the I’ve moved well beyond the Rails learning curve, and into the world of Rails nirvana. I’m doing things now about a billion times faster than when I first started and it feels really, really, really good. The thing that first got me into Ruby is when programmers described it as a language that made it really fun to program in, and right now I have to say between Ruby and Rails I’m having the most fun I’ve ever had as a developer. If you’re still learning Rails and finding that things take longer than you expected while you are learning don’t worry just give it time and eventually it will come. Rails is amazing but even the amazing takes a bit of time to grasp.

Rails è divertente! Ruby è divertente! Anche se all’inizio si fa un po’ fatica ad “entrarci”.

Jim Weirich nella sua presentazione di Rails mostra una slide che dice

Rails maximizes programmer …

(pausa ad effetto; qualcuno bisbiglia ‘productivity’ )

… happiness!

Chad Fowler, autore di “My job went to India and all I got is this lousy book”, intervistato da Geoffrey Grossenbach sul Ruby On Rails podcast:

Geoffrey: One of the big things people are excited about with Rails is it’s making possible for small teams to produce really killer web sites that would have previously taken ten or twenty programmers, and… definitely in India many programmers are put on different jobs. Do you think Rails is a threat in general worldwide for programmers, because a lot fewer programmers are needed, or is this an opportunity for people to take advantage of?

Chad: I think it’s an opportunity for great programmers. Rails is not the first technology to come along to help people to be more productive; I mean, look back at the first online store, created by a programmer’s company, written in Lisp, using continuations and all kinds of advanced features. They were able to do things like change the running application on the fly … There are some ultra-productive technologies available and they have been for a long time, to develop this kind of things with small teams. But what you won’t find is the mediocre programmers, that really our industry is rampant with right now. You won’t find them developing killer web sites with small teams, whether they’re using Rails, J2EE or PHP. What you will find is the remarkable programmers, using a remarkable technology, to do remarkable things. And I don’t believe that represents a threat in terms of the job market. Because what we’re talking about is a very special, focused group of people; a very small percentage of the programmers available.

Gente, sentire queste cose fa venir voglia di fare. Let’s make a difference!

]]>

Krzysztof R. Apt ha scritto un bel necrologio per Edsger W. Dijkstra. E’ molto completo nella descrizione sia degli enormi contributi scientifici

In a one-page paper from 1965 he introduced the ‘mutual exclusion problem’ for n processes and discussed a solution to it. It was probably the first published concurrent algorithm.

che della sua personalità

In writing his elegance was unmatched. He could write about formal issues in the form of an essay, with hardly any formulas. His paper Cooperating sequential processes is perhaps the best example. Similarly, he was able to discuss (one shold rather say, derive) intricate algorithms in distributed computing in a seemingly informal way, in plain prose, with just a few simple formulas. He wrote his articles in a unique style characterised by conciseness, economy of argument and clarity of exposition. Each sentence was carefully chiselled. Each paragraph was striking.

Come risuona questa eco nel ricordo delle poche occasioni in cui l’ho visto. Come apprezzo e ammiro questa concisione e precisione, per usare le parole di Roland Backhouse.

La concisione è potere, dice Richard Gabriel riferendosi alla programmazione. Non posso che essere d’accordo. Il momento più bello è quando l’astrazione giusta fa “click” nella tua mente, e puoi cancellare pagine e pagine di codice: David Heinemeier Hansson. Due citazioni di due hacker. Dijkstra disprezzava sommamente gli hacker. Eppure alla fine l’estetica spartana e cristallina di Ruby on Rails ha qualcosa degli articoli brevi ed icastici di Dijkstra.

Fra le molte citazioni gettonate di Dijkstra c’è Program testing can be used to show the presence of bugs, but never to show their absence! Dijkstra non usava mai i computer. Disprezzava l’idea di “testare” i programmi. Eppure … sono convinto che la disciplina del Test-driven development ha qualche cosa della discipline of programming di Dijkstra. I programmi che si ottengono hanno la stessa qualità di essere super-concisi ed essenziali. Quella stessa qualità che ammiravo nei programmi ottenuti per derivazione dalle specifiche.

Aneddoto: in un qualche momento degli anni novanta c’era un lungo dibattito su comp.lang.c.moderated su come risolvere il seguente problema: dato un array di interi, trovare la sottosequenza la cui somma è massima. La soluzione “forza bruta” è ovvia e richiede tempo quadratico; si voleva una soluzione più efficiente. Pagine e pagine di codice e ragionamenti confusi volavano nel newsgroup, fino a quando non intervenni io. Il problema in questione è uno degli esercizi standard che si usano nella program derivation. La soluzione lineare si calcola facilmente, e consiste in tre righe di codice. Il mio post è stato l’ultimo del thread :)

]]>

L’articolo
è del ’94. La tesi, in breve, è che non è praticamente possibile rendere
trasparente (invisibile) la differenza fra oggetti locali e remoti, in un
sistema di programmazione ad oggetti. La qual cosa, detta così, può anche
apparire ovvia; ma in quegli anni si faceva un gran parlare di DCOM, Corba,
RMI, EJB e altri sistemi che promettevano al programmatore di “sviluppare
un’applicazione ad oggetti, e preoccuparsi dopo di come distribuire gli
oggetti su diverse macchine.”

Il tono dell’articolo è accademico-scassapalle. Ciononostante hanno ragione. Alcune degli argomenti che citano sono abbastanza banali; altri un po’ meno, soprattutto quello che dicono dei fallimenti parziali.

Quali sono, dunque, i motivi per cui un oggetto remoto non può essere trattato come un’oggetto locale?

1. Latenza. L’invocazione di un metodo locale costa pochissimo, invocare un metodo remoto no. Finchè si tratta di invocarlo una volta è un conto, ma in pratica un sistema distribuito deve essere progettato per minimizzare il numero di network round-trip (chiamate remote). Questo dovrebbe essere abbastanza ovvio.
2. Modello della memoria. Chiamare un metodo significa passare parametri, e magari ricevere dei risultati. Se questi dati sono value objects (semplici strutture dati autocontenute) non c’è nessun problema. Ma se contengono risorse a strutture date esterne, tipo connessioni a database o a file aperti, questi oggetti non si possono serializzare. Così come sono problematiche strutture dati che contengono puntatori ad altre zone di memoria. Anche questo mi pare abbastanza ovvio.
3. Fallimenti parziali. Quando una chiamata remota fallisce, non è dato sapere se il fallimento è totale o parziale. Per esempio: supponiamo di avere una chiamata remota il cui effetto è aggiungere un record ad un database. Se invoco questo metodo, e dopo un po’ di tempo non ho avuto risposta, i casi sono due: o la chiamata è andata persa, e il record non è stato aggiunto; oppure la risposta è andata persa, e il record è stato aggiunto. Il mio problema è che non posso sapere in quale dei due casi mi trovo.

Quest’ultimo caso è il più difficile e interessante. Così su due piedi, l’unica cosa che posso fare è attendere fino a un certo tempo e poi arrendermi. Ma non so se il record è stato aggiunto o no. Tutto quello che posso fare è aspettare un po’ e provare ad aggiungerlo di nuovo, correndo il rischio di aggiungere il record due volte!

La soluzione è semplice, mi dirai. Basta interrogare il server per sapere se il record è stato aggiunto. Oppure aggiungere un identificatore alla mia richiesta; ad esempio, se ho ricevuto una timeout sulla richiesta n. 456, riprovo a mandare la richiesta 456. Il server può così distinguere il caso di una richiesta che ha già visto, nel qual caso la ignora.

Aha! Ma in entrambi i casi, abbiamo modificato l’interfaccia remota per tenere conto del fatto che l’invocazione è, appunto remota.
Nel caso di una invocazione locale non abbiamo i fallimenti parziali: se la mia richiesta di aggiungere un record fallisce, lo so e basta.

Qui sta il succo dell’articolo: per progettare un interfaccia da usare in remoto, occorrono accorgimenti specifici per il caso remoto. Il che può apparire ovvio, detto così! Ma quando ci si prova, è difficile tenere conto dei fallimenti parziali che possiamo avere in un sistema distribuito.

Tutto sommato, è valsa la pena di leggerlo.

PS. Jim Waldo, uno degli autori di “A Note” e in seguito inventore di Jini, tiene un corso ad Harvard la cui pagina è una bella bibliografia di articoli sui sistemi distribuiti

]]>